что такое открытый исходный код и закрытый
В чем смысл open source?
Хабр, привет! Я Юра, руководитель платформенной команды inDriver. В IT уже более 12 лет, на iOS пишу 7 лет. В этой статье обращусь к принципам и целям open source. Мы разберемся с его лицензиями, посмотрим на рынок и государственное участие в этом процессе. Добро пожаловать под кат!
Содержание
Минутка истории
Начну с определения того, что такое open source. Это открытое программное обеспечение, исходный код которого доступен для просмотра, изучения, изменения и позволяет убедиться в отсутствии уязвимостей.
Попробуем разобраться с корнями определения. Есть 2 термина: free software и open source. Термин open source был использован в качестве определения в 1998 году Эриком Реймондом и Брюсом Перенсом. Они утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих коммерческих предпринимателей.
Эрик Реймонд и Брюс Перенс
Но откуда же пошли эти термины? В 1985 году появился Free Software Foundation. Он возник благодаря трудам разработчика Ричарда Столлмана, который присоединился к лаборатории искусственного интеллекта при Массачусетском технологическом институте. Столлман принимал участие в работе над свободным ПО (например, над Emacs — текстовым редактором для мини-компьютеров). Позднее редактор продали коммерческому дистрибьютору, и в 1984 году Столлман решил основать проект свободного ПО под названием GNU.
Ричард Столлман
Если не знали, GNU — во-первых, рекурсивный акроним — GNU’s Not UNIX, во-вторых, ОС типа UNIX с набором свободных программ. В рамках проекта энтузиасты придумали термин «свободное ПО» и сформулировали его критерии: использование, изучение, шеринг и улучшение.
4 основных принципа
В 1985 году Столлман основал фонд Free Software Foundation для развития свободного ПО за счет пожертвований. Цель организации — способствовать свободе пользователей компьютеров во всем мире. Фонд взял на себя задачу защиты прав всех пользователей программного обеспечения.
Философия фонда строится на 4 основных свободах:
Свобода запускать программу в любых целях (свобода 0).
Свобода изучения работы программы и ее адаптация к вашим нуждам (свобода 1). Доступ к исходным текстам является необходимым условием.
Свобода распространять копии, так что вы можете помочь вашему товарищу (свобода 2).
Свобода улучшать программу и публиковать ваши улучшения, так что все общество выиграет от этого (свобода 3). Доступ к исходным текстам является необходимым условием.
Программа свободна, если у ее пользователей есть 4 вышеупомянутых пункта. Все достаточно прозрачно и позитивно. Но здесь накладываются взаимоотношения между разработчиками в юридическом плане и в рамках государства. Свободная программа часто не значит «некоммерческая», она может быть доступна для коммерческого применения и распространения. Это правило фундаментально важно, без этого свободные программы не могли бы достичь своих целей.
В англоязычных текстах free означает не только «свободное», но и «бесплатное». Оно нередко употребляется к бесплатному программному обеспечению, которое распространяется без взимания платы, но недоступно для изменения. Получается, такое ПО не является свободным.
Чтобы устранить недоразумения, как раз и был придуман термин open source. Его сформулировала некоммерческая организация Open Source Initiative, которая была основана вышеупомянутыми Реймондом и Перенсом.
Логотип организации
В середине 1990-х годов в open source пришла первая крупная компания — Netscape. Ее браузер Netscape Navigator был одним из самых популярных в мире, но с появлением Internet Explorer стал вытесняться с рынка.
В 1998 году в Netscape решили открыть исходный код своего браузера. Год спустя компании не стало, но исходный код Navigator лег в основу одного из самых популярных современных браузеров — Mozilla Firefox. В том же 1998 году возникла Open Source Initiative, которая и начала заниматься популяризацией открытого исходного кода.
Интерфейс Netscape Navigator
Основатели Open Source Initiative придумали альтернативу free software и сделали больший упор на open source. То есть это не свободное ПО, а ПО с открытым исходным кодом. Разработчики написали определение, описали более подробно, что такое open source и на чем он зиждется.
По их мнению, открытый исходный код — не просто доступ к исходному коду, но и условия распространения программного обеспечения с открытым исходным кодом. Также Реймонд и Перенс задекларировали 3 важных критерия:
Лицензия не должна ограничивать любую сторону от продажи или раздачи программного обеспечения как компонента совокупного распространения.
Лицензия не требует лицензионных или иных сборов за такую продажу.
Программа должна включать исходный код и допускать распространение в исходном коде, а также в скомпилированном формате.
Эти постулаты были частично взяты из Debian Free Software Guidelines. Я не буду их раскрывать по части дискриминации и лицензий, но после этого начинается постепенное развитие open source от одной некоммерческой организации к другой.
dino
Кстати, еще одно достоинство Open Source Initiative — репозиторий SourceForge для программ с открытым исходным кодом. Помню его с домобильной эпохи по скачиванию архиваторов на Windows, но сейчас он уже не столь популярен.
Лицензии
Расскажу немного о взаимоотношениях разработчиков открытого исходного кода, а также под какими лицензиями этот исходный код распространяется сейчас. Выделяют 4 категории:
1. Public Domain. Категория лицензий, которые относятся к творческим материалам. Они не защищены законами об интеллектуальной собственности или авторском праве, о товарных знаках или патентах. Эти работы принадлежат публике, а не отдельному автору или художнику. Кто угодно может использовать произведение, являющееся общественным достоянием, без получения разрешения.
Пример такой лицензии — СС0 от Creative Commons
2. Permissive. Это лицензии на программное обеспечение, которые практически не ограничивают свободу действий пользователей ПО и разработчиков, работающих с исходным кодом. В отличие от других лицензий, они не являются копилефтными. По духу похожи на Public Domain, но не требуют отказа от авторского права.
3. Copyleft. Это лицензии, которые требуют, чтобы распространение продукта подчинялось той же лицензии, что и оригинал. То есть нельзя делать проприетарным этот софт.
4. Proprietary. Это вид лицензий, который является частной собственностью авторов или правообладателей и не удовлетворяет критериям свободного ПО. Правообладатель сохраняет за собой монополию на его использование, копирование, модификацию.
Рынок
Теперь о многообразии open source-проектов. Open source участвует практически во всех сферах, начиная от мобилок и заканчивая блокчейном и искусственным интеллектом.
Простой пример. Android, операционная система, 2,5 миллиарда активных устройств, огромнейший рынок, который построен на open source. В вебе это WordPress, на котором крутится более 40% сайтов в интернете. В бэкэнде, инфраструктуре — NGINX и Kubernetes, используются для оркестрации нагрузки, контейнеров, являются стандартами индустрии. В AI это TensorFlow — платформа, которая используется для машинного обучения. Для блокчейна это Ethereum — платформа, которая лежит в основе многих криптовалют.
Многие индивидуальные разработчики делают вклад в open source не менее значимый, чем корпорации. Благодаря Линусу Торвальдсу появился Linux. Микаэль Видениус создал, наверное, самую популярную у веб-разработчиков базу данных — MySQL, а Майкл Стоунбрейкер с командой из Беркли — PostgreSQL.
Если переходить к корпорациям, все крупные IT-игроки понимают важность open source-проектов. Как пример приведу исследования компании Red Hat. Она ежегодно опрашивает более 1 000 компаний и делает обзор рынка, куда IT двигается и как меняется. Согласно последнему исследованию, 90% опрошенных респондентов считают, что open source играет важную роль в технологиях корпораций. Наиболее распространенные пути использования open source в корпоративном секторе: IT-инфраструктура, разработка приложений, цифровая трансформация. За 2 года эти показатели увеличились на 11%.
Почему корпорации идут в open source? В первую очередь, участие в открытых проектах позволяет привлечь внимание не только к этому проекту, но и к другим своим программам. Вовлечение открытого сообщества в проекты компаний делает проще найм сотрудников и позволяет удерживать таланты внутри компании. Мотивационная часть также важна — поддержка проектов извне мотивирует разработчиков активнее их развивать.
Но есть и минусы. Открытый код может использоваться в тех проектах, о которых его авторы даже не подозревают. Если проект многокомпонентный и собран из большого числа подмодулей, в цепочке зависимостей легко может возникнуть дыра в безопасности, которую долго могут не замечать.
Russia Open Source
Перейдем к российским реалиям. 1 октября 2021 года Министерство цифрового развития России и крупные IT-компании обсудили стратегию работы с открытым кодом до 2024 года.
Целями развития программного обеспечения с открытым кодом в России являются:
Развитие стека продуктов для госсектора. Обеспечение безопасного использования в нем компонентов с открытым кодом.
Повышение эффективности цифровизации государственных органов благодаря повторному использованию программного кода, разработанного за бюджетные средства.
Также при создании стратегии идут отсылки к опыту других стран. В США, согласно политике, принятой в 2016 году, публикуют не менее 20% исходного кода правительственного ПО под открытыми лицензиями.
В Евросоюзе тоже есть стратегия развития открытого ПО с упоминанием технологического суверенитета. Китай способствует созданию независимой экосистемы. В частности, реализует свои варианты открытых операционных систем: например, HarmonyOS. Есть аналоги Java, PostgreSQL, GitHub.
В России создается некоммерческая организация, которая будет поддерживать репозиторий, куда будут выкладываться лицензии. Создается аналог открытой лицензии, под которой все будет выкладываться. Более подробно можно прочитать в проекте стратегии.
Hacktoberfest
Hacktoberfest — это фестиваль поддержки open source-комьюнити с целью мотивации разработчиков улучшать проекты с открытым исходным кодом. Он ежегодно проводится в октябре. Open source-проекты — вариант устроиться на работу, развивать личный бренд или просто отразить свои знания в коде.
Участники должны сделать 4 пул-реквеста на GitHub или GitLab. Предварительно, конечно же, зарегистрироваться на сайте.
Один из этапов регистрации
Из нюансов — вы можете контрибьютить в свои собственные репозитории, необязательно развивать сторонний проект. Неважно и то, на каком языке вы программируете. Можно выбрать ваш любимый продукт или open source-проект, посмотреть issues, которые можно закрыть, и даже поправить документацию. Вариантов много, выбор остается за вами.
Из личных примеров: когда устраивался в inDriver сделал open source-проект под «Роскачество». В свое время в маркете было приложение «Роскачество», где российская лаборатория тестировала и проверяла продукты, но визуальная реализация оставляла желать лучшего. Заодно попробовал новую архитектуру, новые технологии, которые появлялись в iOS (например, Swift UI с однонаправленной архитектурой). Это стало долгосрочным полезным вкладом.
Логотип UDF
Наконец, приглашаю всех поучаствовать в развитии open source-проекта inDriver. Мы опубликовали iOS-архитектуру c Redux-парадигмой. Конечно, это не первая реализация однонаправленной архитектуры, но у нее есть ряд преимуществ: адаптация под UI Kit, модуляризируемая, с апробацией в крупном проекте. Подробнее про UDF можно прочитать в статьях моего коллеги Антона Гончарова на Хабре (часть 1 и часть 2).
У меня все. Спасибо, что читали. Задавайте ваши вопросы в комментариях.
Можно ли закрыть обратно открытый исходный код?
Эта концепция кажется довольно простой для любого человека, некоторое время работавшего с открытым исходным кодом: проект, однажды выпущенный в виде открытого кода, остаётся открытым навсегда. Конечно, разработчик может решить, что будущие версии проекта будут закрытыми, и иногда такое случалось, но то, что уже выпущено на свободу, отозвать обратно не получится. У интернета нет кнопки «удалить»; опубликовав свой код, и дав миллионам людей потенциальную возможность скачать его, загнать джина обратно в бутылку не получится.
Но что насчёт уважительных причин? Что, если проект превратится во что-то, к чему вы больше не хотите иметь отношения? Возможно, вы отправляли свой код для проекта, имея представление о том, как его будут использовать, а потом правила поменялись. Или же вас забанили на этом проекте, и при этом у людей, поддерживающих его, нет проблем с тем, чтобы оставить ваш значительный вклад в виде кода, даже когда вас выкинули на обочину?
Из-за того, что некоторые люди считают вынужденным изменением в правилах поведения разработчиков Linux, у некоторых разработчиков наиболее исключительного проекта с открытым кодом в мире возникают вопросы. С такой ситуацией сообществу приходится сталкиваться редко, и такого ещё никогда не случалось с проектом подобного масштаба.
Действительно ли невозможно отозвать исходный код, отправленный в проект, выпущенный под такой свободной и открытой лицензией, как GPL? А если можно, то что тогда будет? Что случится, если окажется, что миллиарды устройств, исполняющие у себя ядро Linux, нарушают интеллектуальные права одного разработчика? Эти вопросы крайне важны для интернета и, вероятно, даже нашего образа жизни. Однако ответы на них найти не так легко, как вам могло бы показаться.
Копилефт и права на владение
GPL известна как лицензия с копилефтом, добавляющая прав конечным пользователям, которые без этого оказались бы ограничены законами об авторских правах. Она, к примеру, даёт пользователю права копировать работу и создавать её производные. Важный момент: такие копилефт-лицензии, как GPL, не заменяют копирайта – они его лишь дополняют. Права на оригинальный код остаются у его автора, и, в итоге, основного владельца.
Это порождает концепцию двойного лицензирования: единственный автор программы может выпустить её под несколькими лицензиями одновременно, причём обычно одна из них позволяет делать с программой больше остальных. К примеру, версия программы для Windows может иметь закрытый код, а для Linux – открытый, даже если сам код программ не отличается. Чаще это используется для того, чтобы под одной лицензией программу использовали в коммерческих целях, а под другой, более свободной – в личных.
У некоторых проектов с открытым кодом, обычно больших и имеющих поддержку корпораций, иногда встречается Contributor License Agreement. Этот документ описывает все необходимые дополнительные требования и правила по добавлению кода в проект, и обычно содержит пункт, объясняющий, что человек, вносящий код, передаёт право на него владельцу проекта. К примеру, вот часть такой лицензии от Google:
По правилам и условиям данного соглашения вы передаёте Google и получателям ПО, распространяемого компанией, бессрочные, всемирные, не эксклюзивные, бесплатные, не требующие отчислений, безотзывные права на воспроизведение, создание производных работ, публичную демонстрацию, публичное исполнение, повторное лицензирование и распространение вашего вклада и производных работ от него.
Стоит отметить, что Linux не использует такое соглашение, поэтому права на любой внесённый разработчиком код остаются за ним.
Репутационные потери
Так что если разработчик свободен в выборе лицензий для распространения своего кода вплоть до диаметрально противоположных (открытый и закрытый код), и общепризнано, что в отсутствии CLA у него остаётся неоспоримое право на написанный им код, то ситуация становится щекотливой. Разве из этого не следует, что у разработчика остаётся право отозвать своё обещание сделать код открытым, если возникнет ситуация, которая заставит его считать, что код уже не стоит открывать?
Эрик Рэймонд
Эрик Рэймонд, один из основателей инициативы открытого кода, Open Source Initiative, и автор трилогии «Собор и Базар», считает, что у них такое право есть. В записи в списке рассылки Linux Kernel Эрик, в частности, обращается к угрозе, сделанной некоторыми разработчиками, по поводу отзыва их исходного кода из ядра:
Для начала позвольте мне подтвердить, что это не пустая угроза. При основании Open Source Initiative я изучал связанные с этим законы. В США существует прецедентное право, подтверждающее, что репутационные потери, связанные с преобразованием прав участника проекта под GPL, могут рассматриваться в суде. Я не знаю о существовании прецедентного права вне США, но в странах, соблюдающих Бернскую конвенцию без поправок США на «моральные права» [после присоединения к Конвенции США заявили, что моральные права уже защищаются положениями о клевете и, соответственно, не требуют дополнительного регулирования / прим. перев.], эта статья конвенции, вероятно, ещё больше упрочит позицию противников в суде.
Секция 6 Бернской конвенции поясняет, что изначальный автор работы, даже передав свои права другому лицу или организации, может возражать против её использования, если ему кажется, что её используют «в ущерб его чести и репутации». Так что, в теории, недовольны разработчик должен лишь убедить судью, что руководители проекта навредили его репутации, допустим, публично забанив за нарушение правил поведения, в результате чего тот может обязать проект прекратить использовать их код вне зависимости от использовавшейся лицензии.
Критика
При этом действие лицензии, предоставленной вами третьим лицам, получившим от вас копии или права согласно этой лицензии, не будет прекращено, пока эти лица будут полностью соблюдать её условия.
Все права, предоставленные согласно Данной лицензии предоставляются на срок действия авторского права на Программу, и не могут быть отозваны при условии, что установленные условия соблюдены.
Некоторые считают, что это отличие может оказаться критически важным. Юридически «отзыв» обычно означает, что соглашение было отозвано тем, кто его предлагал (тут – изначальный разработчик), а «прекращение» просто означает конец действия соглашения. В результате остаётся пространство для интерпретаций, и в принципе, можно утверждать, что поскольку в GPLv2 не указано, что разработчик не может отзывать свои права, эта возможность сохраняется.
Неизученные территории
С учётом оценки Эрика Рэймонда, по которой разработчик может заявлять о том, что проект, в котором он участвует, порочит его репутацию, и того факта, что в текущей лицензии Linux разработчикам напрямую не запрещено отзывать свой вклад, ситуация становится туманной, и пока никто ни в чём не уверен. Мы находимся в неизведанной местности, и старые предположения могут не выдержать юридической экспертизы.
Также стоит упомянуть, что в игру может вступить такая юридическая концепция, как «эстоппель» – она, по сути, запрещает лицу забирать назад своё обещание, если другое лицо уже предприняло шаги на основании этого обещания. То есть, если вы сказали кому-то, что он может использовать ваш код, и он использовал его для создания успешного проекта, вы не можете передумать, поскольку тем самым нанесёте ему ущерб.
С практической точки зрения, даже если бы человек смог защитить свою точку зрения в суде, требуя удалить свою часть кода из Linux, это было бы физически невозможно сделать. И тогда вместо возможности удалить код из устройств, которые с этого момента нарушают авторские права, упомянутый разработчик, скорее всего, получит некоторое денежное вознаграждение. Что всё равно станет ужасным прецедентом для открытого сообщества: обиделся – получил компенсацию.
В итоге, разговоры об отзыве лицензий на открытый код ошибочны. Перефразируя Иена Малькольма, персонажа «Парка Юрского периода»: обиженные разработчики так заняты размышлениями о том, могут они это сделать или нет, что у них не остаётся времени подумать о том, должны ли они это делать вообще. После появления легального прецедента, по которому разработчик может отозвать свой код из открытого проекта, открытое сообщество будет разрушено. У открытого ПО ушли десятилетия на то, чтобы достичь сегодняшнего процветания, но поспешные действия нескольких несчастных разработчиков могут утащить его обратно в область идей, которые лишь хочется воплотить в жизнь.
Почему и зачем писать 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 репорты. Задавайте вопросы владельцам проектов и не забывайте отвечать на вопросы, заданные Вам. Спасибо.