что такое опен код
Открытый код и интеллектуальная собственность
Автор: Илья Стечкин
Мы обратили внимание на то, что едва ли не самой популярной публикацией в нашем блоге стал материал, посвященный патентным войнам (4800 просмотров), а вот подробный рассказ о том, как писать плагины для Fuel, к нашему удивлению, вызвал существенно меньший интерес (1000 просмотров первая часть и чуть больше 2000 — вторая).
На всякий случай информируем вас о том, что с этого месяца Fuel официально стал средством развертывания всея OpenStack.
Но раз юридические вопросы существования открытого кода занимают вас больше, чем сам код, то мы пошли на встречу пожеланиям трудящихся и решили рассказать вам о том, как уживаются авторское и патентное право с open source.
Действительно, как удается избегать прямой конкуренции и делать одно общее дело не только отдельным контрибуторам, но и целым корпорациям, вовлеченным в процесс разработки open source? Ответ следует искать в тех “правилах игры”, которыми руководствуются все без исключения участники сообщества. Эти “правила” описываются не только внутренними политиками того или иного проекта, но и лицензией, под которой выходит итоговый продукт. По понятным причинам в данной статье мы подробно остановимся на вопросах, имеющих прямое отношение к OpenStack. Например, OpenStack (в том числе и Mirantis OpenStack) выходит под лицензией Apache 2.0. Что это значит? Почему выбрали именно эту лицензию? Как с этим жить?
Интеллектуальная собственность: что это такое?
Интеллектуальной собственностью называют результат творческого труда: будь то художественная книга, репортаж или программа.
Говоря про интеллектуальную собственность, необходимо рассматривать три модели правового регулирования: авторское право, патентное право и ноу-хау. Почему недостаточно одного только авторского права? Потому что оно регулирует только возможности владения, распространения и внесения изменений в сам код (и сопутствующие ему документы, такие как техническое задание, мануалы и т.п.) — исходный или объектный.
Но ведь идея, которая реализована средствами конкретного языка программирования, может быть важнее, чем ее воплощение. Как защитить, например, алгоритм, который лежит в основе программы? Для этого существует право патентное.
Есть еще такая штука — “ноу-хау”, но с открытым кодом она уживается плохо, так что подробно останавливаться на этом режиме защиты интеллектуальной собственности не будем. Уточним только, что “ноу-хау” имеет ценность до тех пор, пока о нем не знают “третьи лица”. Более того, юридическая защита “ноу-хау” возможна только в том случае, если владелец интеллектуальной собственности предпринял все возможные меры (в том числе ввел в компании режим коммерческой тайны по отношению к соответствующим объектам интеллектуальной собственности) для предотвращения “утечки”. Но даже в этом случае отечественная правоприменительная практика не гарантирует успеха при попытке решить в суде спор с сотрудником, нарушившим соответствующий режим.
Авторское право
Авторское право возникает само по себе. Вам не нужно предпринимать каких-либо шагов для защиты результата творческой работы. Как только вы что-то написали, авторское право вступило в силу. Даже подписываться не обязательно. Правда, без подписи доказать ваше авторство будет сложнее — могут потребоваться различные экспертизы. На них уйдут деньги и время, а результат не гарантирован. Между тем, авторство — единственное, что безусловно принадлежит именно вам, создателю произведения. По крайней мере в России. В США, например, авторское право может принадлежать корпорации, в которой вы работаете. В России работодатель, при надлежащим образом оформленном контракте, получает только набор так называемых “смежных” прав, таких, как право на копирование, распространение, переработку и т.п. Иными словами, работодатель получает все, что позволяет зарабатывать деньги на результатах вашего творчества (а инженерную деятельность мы, безусловно, считаем творческой). Но “право первородства”, право поставить свое имя под произведением остается у вас. В основе авторского права лежит Бернская конвенция, декларирующая основные принципы его действия. Европейское законодательство (в частности Директива 2009/24/EC Европейского Парламента и Совета от 23 апреля 2009 года о правовой охране компьютерных программ) заботится о том, чтобы технический прогресс продолжался, а потому, например, “лицо, обладающее правом использования компьютерной программы, не может быть ограничено в проведении необходимых изучений, исследований и испытаний функционирования программы, при условии, что такие действия не нарушают авторских прав на программу”. В Российском законодательстве аналогичные нормы вводятся статьей 1280 Гражданского кодекса.
Для культуры open source авторское право является важнейшим понятием. Культура инженерного “общежития” строится на уважении к “праву на имя”: не важно, принадлежит ли оно компании или конкретному человеку — контрибутору кода. Мы еще вернемся к этому вопросу ниже, когда будем говорить о лицензиях.
Патентное право
Как вы уже знаете (из той самой статьи, которая подвигла нас на этот опус), патенты могут быть использованы как инструмент давления производителей проприетарного ПО на сообщества разработчиков открытого кода. Дело в том, что патентами защищаются алгоритмы, интерфейсы и устройства. Применительно к ПО, в соответствии с российским законодательством, могут быть задействованы механизмы защиты изобретений (в этом случае в качестве изобретения может рассматриваться алгоритм или программно-аппаратный комплекс) и промышленных образцов (интерфейс, допустим, может выступать в качестве промышленного образца “внешнего вида” программы).
В отличие от авторского права, патентное право возникает только после того, как пройдена сложная и недешевая процедура регистрации изобретения или промышленного образца. Именно поэтому большие компании инвестируют время и большие деньги в получение патентов. Например, у Apple, по данным US Patent Collection (запрос к БД: AN/apple) более 11 тысяч (!) патентов. Маленькие компании не имеют таких возможностей. А потому им остается полагаться только на защиту лицензий и здравый смысл.
Лицензии
Лицензии бывают исключительными и неисключительными. Все “свободные лицензии” являются неисключительными. Также лицензии могут быть возмездными и безвозмездными. Все “свободные лицензии” — безвозмездные. Еще один вариант классификации лицензий: разрешительные, слабо ограничительные и сильно ограничительные.
Лицензия Apache 2.0, с которой мы начали разговор, относится к первому типу. В рамках данной лицензии пользователю разрешено использовать ПО без каких-либо ограничений, воспроизводить его, создавать собственные программные продукты на основе кода, лицензированного таким образом, распространять как исходный код, так и производное ПО. Разрешено коммерческое использование лицензированного продукта — это в принципе делает возможным бизнес, связанный с OpenStack.
Что еще важно для бизнеса, это разрешение предоставлять собственные дополнительные гарантии в отношении программы при дальнейшем распространении. Именно этот пункт позволяет создавать “добавленную стоимость” нашему дистрибутиву Mirantis OpenStack (убирать баги, которые обнаруживаются в “ванильном” релизе, повышать безопасность, стабильность, масштабируемость), а также создает правовую базу для работы нашей службы поддержки.
При этом пользователю запрещается требовать от лицензиара гарантий и использовать товарные знаки лицензиара (лицензиаром называется компания, предоставляющая продукт по лицензии). Иными словами, если вы взяли продукт и используете его для решения поставленных перед вами задач, то делаете это на свой страх и риск. Это обстоятельство позволяет продавать те самые гарантии, которые нельзя требовать по лицензии.
OpenStack — технология бесплатная, но требующая определенных компетенций для эффективной работы с нею. У предприятий есть выбор: тренировать собственных ИТ-специалистов или же обратиться в компанию, обладающую экспертизой в OpenStack. В первом случае ответственность за корректное функционирование решения, созданного на базе OpenStack, остается внутри компании, во втором — передается подрядчику. Подрядчик, в свою очередь, может обеспечить включение разработок, созданных для заказчика, в экосистему OpenStack. Этот процесс принято называть contribution to upstream. Решение, созданное на базе OpenStack, но не добавленное в апстрим, у нас в компании принято называть “франкенстеком”, подчеркивая его ненадежность и даже опасность. Именно об опасностях таких решений мы говорили в прошлом посте.
Выводы
Итак, OpenStack комфортно уживается с авторским правом, поскольку лицензия Apache 2.0 дает возможность каждому из участников процесса создания ПО заявить о себе и, при этом, защищает репутацию каждого контрибутора.
Патенты, в принципе, не вредят OpenStack. Более того, если кто-то из компаний-контрибуторов хочет привнести в проект запатентованную технологию, в действие вступает патентная лицензия: положение о предоставлении вкладчиком простой неисключительной лицензии на имеющиеся у него запатентованные алгоритмы и технологии, включаемые им в проект. На пракике это означает, что если вкладчик вносит в программу свои запатентованные алгоритмы, он автоматически предоставляет всем другим участникам проекта и последующим участникам простую неисключительную лицензию на данные запатентованные алгоритмы. Патентная лицензия предоставляется в рамках лицензии Apache 2.0.
Лицензия Apache 2.0, под которой осуществляются разработки, связанные с OpenStack, является свободной и предоставляет множество уникальных возможностей для бизнеса.
Почему и зачем писать open-source код?
Под катом интересный опрос
Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.
Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.
Open-Source проект живет своей жизнью — жизнью сообщества, которое образуется вокруг проекта. Идеи, отзывы, bug репорты, обсуждение и благодарности от других членов сообщества влияют на Вас и проект напрямую, и стимулируют написание кода — понятного, документированного и покрытого тестами.
Про опыт:
Однажды, выложив свой код на GitHub, я уже не смог остановится. Первым моим публичным репозиторием был PHP-код, предназначенный для интернализации на основе MySQL таблицы. Этот репозиторий не собрал звезд и сомнительно, что был кем-то замечен. Не в звездах дело, дело в том что Ваш код доступен всем. Ваш код не скрыт на сервере, не минифицирован/аглифицирован в браузере и не скомпилирован на жестком диске пользователя — он выставлен всем на показ. Осознание данного факта просто обязует Вас писать код в общепринятой манере (в соответствии с тем языком на котором Вы пишите), соблюдать отступы, добавлять описание к методам и классам (как минимум к публичным), адекватно именовать переменные, классы, методы и функции, соблюдать правило do-not-repeat-yourself.
Я уверен, что публикуемый мною код полезен другим разработчикам ровно на столько же, как и мне самому. Публикуя код, я не только делюсь своим опытом с миром, но и самоорганизуюсь ровно на столько же, как и организуется мой код.
Писать общедоступный код — это как посещать светские мероприятия. Вы выглядите, разговариваете и соответствуете высшим стандартам IT-индустрии, или как минимум стремитесь к ним. Писать общедоступный код — это как обсуждать функционал IT-коллективом равным по масштабу всему IT-сообществу планеты. Любой из членов open-source сообщества может предложить изменения, сообщить о bug’е и вынести на обсуждение дальнейшее развитие проекта.
Приятное в open-source проектах — это эмоции и ощущения, испытываемые от понимания, что твой проект полезен. Когда количество скачиваний растет вверх, когда вы получаете отзывы, когда к проекту присоединяются люди со всего света и Вы вместе делаете проект лучше — это то, ради чего стоит писать код. В этот момент простое написание кода для решения поставленных задач перерастает во вклад в IT-сообщество.
Про опасения Студий и Компаний:
Ваша компания пишет код? Вы считаете, что написанный код принадлежит только Вам и Вашим клиентам, которые за него заплатили? Если Ваш ответ — ”да”, подойдите к Вашим разработчикам и попросите посчитать, сколько строк кода написано за стенами Вашей компании третьей стороной, скачено с SourceForge, GitHub, установлено через NPM, apt-get, aptitude, и других источников дистрибуции кода.
Когда речь идет об open-source, многие руководители (не все, но такие есть) считают что на GitHub лежат целые проекты, готовые к использованию и зарабатыванию денег. Когда Ваши сотрудники предлагают опубликоваться на GitHub, они собираются “слить” весь код, за который разработчики получили зарплату, а кто-то другой (нехороший) соберет клон Вашего продукта и будет зарабатывать деньги. Или хуже того, обнаружит эксплойт и будет его тайно использовать. Это абсолютно не так. Во-первых, никому не нужен Ваш проект целиком кроме Вас и Вашего клиента, во вторых, — не нужно выкладывать проекты целиком. Маленькие кусочки, классы, методы, адаптеры и т.п., из которых Ваш проект состоит, могут оказаться полезными не только Вам. На Ваш вклад IT-сообщество ответит поиском и исправлением ошибок и уязвимостей, дополнением функционала и улучшением производительности. Возможно, Вы найдете нового сотрудника в лице активного контрибьютора.
Open-source проект это:
Во вселенной, где люди не научились работать в open-source сообществе, нет возможности использовать предыдущий накопленный опыт IT-индустрии и аккумулировать его. В свою очередь, IT-компании выделяют большую часть бюджета на платный софт. И в целях экономии на покупке и подписках на софт — пишут свои решения, что вызывает рост штата разработчиков в десятки раз, готовый выполнять задачи от написания ОС и фреймворков до текстовых редакторов, в которых этот код пишется. Хорошо что в нашей вселенной open-source сообщество активно развивается и нам это не грозит.
Выкладывайте Ваш код. Выкладывайте код, написанный в стенах компании (с соглашения всех руководителей). Сделайте вклад в развитие IT-индустрии. Читайте чужой код. Улучшайте чужой код. Всегда пишите bug репорты. Задавайте вопросы владельцам проектов и не забывайте отвечать на вопросы, заданные Вам. Спасибо.
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
Открытый исходный код
Открытое программное обеспечение (англ. open source software ) — это программное обеспечение с открытым исходным кодом. Исходный код создаваемых программ открыт, то есть доступен для просмотра и изменения. Это позволяет использовать уже созданный код для создания новых версий программ, для исправления ошибок и, возможно, помочь в доработке открытой программы.
«Открытая» лицензия не требует, чтобы открытое ПО предоставлялось бесплатно. Многие из наиболее успешных проектов открытого ПО, тем не менее, бесплатны. Открытое программное обеспечение имеет большие перспективы в России в связи с принятием правительством и президентом РФ решений по обеспечению национальной безопасности в сфере ИТ на основе внедрения открытого и свободного ПО в государственные и бюджетные организации.
Содержание
Открытое и свободное ПО
Термин open source (англ. Открытое программное обеспечение) был создан вместе с определением в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (Свободное программное обеспечение) в английском языке неоднозначен и отпугивает коммерческих предпринимателей. [1]
Подавляющее большинство открытых программ является одновременно свободными. Определения открытого и свободного ПО не полностью совпадают друг с другом, но близки, и большинство лицензий соответствуют обоим.
Отличие между движениями открытого ПО и свободного ПО заключается в основном в приоритетах. Сторонники термина «open source» делают упор на эффективность открытых исходников как метода разработки, модернизации и сопровождения программ. Сторонники термина «free software» считают, что именно права на свободное распространение, модификацию и изучение программ являются главным достоинством свободного открытого ПО.
Существуют программы, попадающие по мнению некоторых [кто?] под определение открытых, но не являющиеся свободными, например, UnRAR, распаковщик [2]
По мнению Ричарда Столлмана, разрекламированность «Open Source» несколько вредит свободному ПО, так как некоторые разработчики и пользователи открытого ПО совсем не против собственнического ПО, и люди останавливаются на Open Source, не доходя до понятий о свободе. [3]
По словам Брюса Перенса открытое ПО всегда было лишь способом объяснить предпринимателям идею свободного ПО, и это ему удалось. [4]
Враждебные к свободному ПО компании — например, Microsoft — используют только выражение open source.
Определение открытого программного обеспечения Open Source Initiative
Open Source является торговой маркой организации Open Source Initiative. Существует специальный комитет, решающий, может ли лицензия носить имя Open Source. Определение, которым он при этом руководствуется, приведено в The Open Source Definition. [7]
Вынесенное OSI определение признается за руководство многими другими организациями — например, порталом Debian Free Software Guidelines.
Лицензии
Исходные коды открытых программ выпускаются либо как общественное достояние, либо на условиях «свободных» лицензий — как, например, GNU General Public License или BSD License. Свободная лицензия позволяет использовать исходный код программы для своих нужд с минимальными ограничениями, не противоречащими определению OpenSource.org. Таким ограничением может быть требование ссылаться на предыдущих создателей или требование сохранять свойство открытости при дальнейшем распространении той же самой или модифицированной открытой программы (копилефт). В некоторых случаях (например, FreeBSD) эти ограничения очень малы, в других (например, GNU General Public License) достаточно распространять ПО вместе с исходным кодом и текстом лицензии, не изменяя её.
Открытое программное обеспечение в России
В настоящее время открытое программное обеспечение не получило широкого распространения в России, среди причин чему называют широкое нелегальное распространение собственнического программного обеспечения.
Однако, решениями правительства и президента РФ Дмитрия Анатольевича Медведева, отечественное открытое программное обеспечение в 2008 году внедрено во всех школах Российской Федерации и будет установлено во всех государственных и бюджетных организациях для обеспечения национальной безопасности в сфере ИТ.
Открытое программное обеспечение может свободно устанавливаться и использоваться во всех школах, офисах, вузах и на всех личных компьютерах и во всех государственных, бюджетных и коммерческих организациях и учреждениях России и в странах СНГ согласно Генеральной публичной лицензии (GPL).
Открытое программное обеспечение в школах
Решением правительства Российской Федерации в марте 2008 года, все средние школы России получили базовые пакеты лицензионного собственнического и открытого программного обеспечения для обучения компьютерной грамотности, основам информатики и новым информационным технологиям с операционными системами Windows и Linux.
В трёх регионах России в 2008 году развёрнуты эксперименты по внедрению и использованию в средних школах базовых пакетов программ для кабинетов информатики и вычислительной техники и начата подготовка учителей и преподавателей информатики технологии работы с открытым программным обеспечением в среде Windows и Linux.
В 2007 году выпущены первые учебники информатики для вузов и школ для обучения информатике в соответствии с государственными стандартами образования со свободным и проприетарным программным обеспечением в среде Windows и Linux.
Российские разработчики открытого программного обеспечения
Российские разработчики в основном помогают развитию англоязычных проектов или выпускают локализованные редакции международных проектов (например, OpenOffice Pro на базе
Также, существует незначительное количество российских репозиториев открытого ПО (таких, как репозитарий Сизиф).
Примечания
См. также
Ссылки
Полезное
Смотреть что такое «Открытый исходный код» в других словарях:
Открытый Каталог — Open Directory Project Открытый Каталог (ODP) http://www.dmoz.org/ Коммерческий: Нет Тип сайта: Каталог Регистрация … Википедия
Открытый каталог — Open Directory Project Открытый Каталог (ODP) http://www.dmoz.org/ Коммерческий: Нет Тип сайта: Каталог Регистрация … Википедия
открытый код — 3.5 открытый код: Исходный код программного обеспечения, передаваемый разработчиком пользователю на определенных лицензионным договором условиях. Источник: ГОСТ Р 54593 2011: Информационные технологии. Свободное программное обеспечение. Общие… … Словарь-справочник терминов нормативно-технической документации
Открытое программное обеспечение — Логотип Open Source Initiative (OSI) У этого термина существуют и другие значения, см. OS (значения). Открытое программное обеспечение (англ. … Википедия
Сравнение средств разработки для создания мультиагентных систем — Платформа Основное назначение Лицензия Требуемый язык программирования Требуемая ОС Поддержка пользователя Соответствует ли требованиям FIPA Возможности ГИС Трехмерные возможности ABLE … Википедия
ADempiere — Тип ERP, CRM, SCM Разработчик Adempiere Community Написана на Java Операционн … Википедия
День загрузки — Запрос «Firefox» перенаправляется сюда. Cм. также другие значения. Mozilla Firefox Firefox 3.0 на платформе GTK+/Linux Тип Браузер … Википедия
Огнелис — Запрос «Firefox» перенаправляется сюда. Cм. также другие значения. Mozilla Firefox Firefox 3.0 на платформе GTK+/Linux Тип Браузер … Википедия
Фаерфокс — Запрос «Firefox» перенаправляется сюда. Cм. также другие значения. Mozilla Firefox Firefox 3.0 на платформе GTK+/Linux Тип Браузер … Википедия
Файерфокс — Запрос «Firefox» перенаправляется сюда. Cм. также другие значения. Mozilla Firefox Firefox 3.0 на платформе GTK+/Linux Тип Браузер … Википедия