Написано довольно много хороших материалов о свободных лицензиях, в том числе тут, на Habr. Почему стоит прочитать еще и эту статью:
Постаралась собрать основную информацию по всем ключевым вопросам, чтобы у вас была общая картина.
Я - IP/IT юрист, поэтому могу помочь увидеть и нейтрализовать правовые риски.
В конце статьи есть ссылки на разные ресурсы и статьи по теме, чтобы все было под рукой.
Звучит неплохо? Тогда поехали.
Оглавление
Вы можете читать статью не полностью, а выбрать нужное вам. Блоки написаны так, чтобы даже если вы начнете с середины, вы все поняли.
Вариант 1. Вы пишите код для коммерческого использования или вы руководитель разработчиков
Вариант 3. Вы написали код и думаете, под какой лицензией разместить
Базовая информация об опен сорсе
В этой статье пойдет речь о программном обеспечении с открытым исходным кодом, распространяемом на условиях свободных лицензий. Я использую термины - опен сорс, свободные лицензии.
Это исключение из правил. Во всех остальных случаях исходный код ПО не раскрывается, а для его использования необходимо заключить лицензионный договор с правообладателем. Как правило, такой договор является возмездным и предусматривает конкретные индивидуальные условия использования ПО. Зачастую такие лицензии не предполагают возможность модификации ПО без разрешения правообладателя.
Опен сорс в этом плане и проще, и сложнее. Проще - потому что исходный код открыт для каждого, его можно относительно просто использовать и дорабатывать. Сложнее - потому что каждая лицензия имеет индивидуальные условия. Некоторые свободные лицензии “заражают” весь код, например, запрещают некоторые способы его использования. Подробнее об этом будет дальше.
Свободные лицензии предоставляются безвозмездно, но использование открытого ПО все же может предполагать определенные расходы. Это может быть пожертвование разработчикам открытого ПО, оплата технического сопровождения или адаптация открытого ПО под задачи заказчика.
Я вынуждена пропустить аспекты истории и философии вопроса - иначе статья будет огромная. Но упомяну, что сертификацию свободных лицензий осуществляет OSI и не каждая лицензия может называться опен сорсом. Перечень актуальных лицензий размещен тут , а критерии - тут.
Есть разрешительные свободные лицензии (можно использовать в коммерческих продуктах), а есть копилефт. Его еще достаточно смешно называют “авторское лево”. Копилефт предполагает большую степень свободы. К сожалению, в ряде случаев это несовместимо с коммерческой разработкой, потому что предполагает раскрытие исходного кода. Вы понимаете, что если код раскрыт для любого - то за лицензию платить никто не будет. Подробнее про логику движения можно почитать тут.
Это вообще законно?
Свободным лицензиям посвящена статья 1286.1 ГК РФ. В статье речь идет о заключении простой (неисключительной) лицензии путем присоединения. Все просто. Простая (неисключительная) лицензия предполагает возможность выдачи лицензии неограниченное число раз на один и тот же программный продукт. Заключение договора путем присоединения означает, что вы полностью соглашаетесь с условиями лицензии и не можете в них вносить правки. Если вы скачиваете опен сорс - вы заключаете лицензионный договор.
Обратите внимание, что такой договор обязателен к соблюдению. То есть за нарушение условий открытой лицензии может быть установлена ответственность. Теоретически правообладатель может обратиться в суд и потребовать взыскания убытков или запретить вам использовать программу. Правда, риски невелики с учетом количества потенциальных нарушителей.
А вот попытки продавать лицензии на опен сорс с нарушением условий лицензии с большой вероятностью будут пресечены судом со взысканием убытков и расходов. В общем, свободные лицензии не похожи на обычный договор, но условия стоит соблюдать.
Если компания использует опен сорс в рамках лицензии - она действует в рамках закона. Ссылку на статью 1286.1. ГК РФ можно использовать в том числе при проверках правоохранительных органов.
Ниже я разберу три основных случая, когда вам может быть важно знать подробнее про свободные лицензии. Если какой-то случай не про вас - можно спокойно перелистывать дальше.
Вариант 1. Вы пишете код для коммерческого использования или вы руководитель разработчиков
Ситуация:
Вы разработчик фрилансер и разрабатываете ПО для заказчиков с фокусом на коммерческое использование (продажу лицензий);
Вы разработчик в коммерческой компании;
Вы руководитель разработчиков
Риски неправомерного использования опен сорса:
Программу нельзя будет включить в реестр отечественного ПО, а от этого зависит льгота по НДС. Ставка НДС сейчас 20%, так что это может быть довольно существенно;
Если в компанию зайдет новый инвестор или учредитель, он обратит внимание на проблемы с опен сорсом в программном обеспечении компании, что может повлиять на условия сделки
Программу будет сложно коммерциализировать (выдавать лицензии или продать);
Лицо, которое получило лицензию или купило программу, может потребовать возместить убытки. Это прямые расходы компании, судебные и репутационные издержки
Если вы руководитель и не подумали об этом, у вас могут быть проблемы на работе включая финансовые санкции и увольнение.
Что делать:
Стоит внимательно читать условия лицензии;
Если вы руководитель - обсудите внедрение в компании регламента использования опен сорса. Это локальный нормативный акт. В нем напишите, какие открытые лицензии в каких случаях разрешено использовать, дайте на подпись гендиру и ознакомьте всех разработчиков под подпись или иным образом;
Если вы разработчик, вы можете задать руководителю вопрос о разрешенных для использования свободных лицензиях в вашей компании.
Если вы фрилансер - один раз разберитесь и решите для себя, какие вы лицензии будете использовать. Если будут нужны новые - очень внимательно читайте условия
Вариант 2. Вы заказываете разработку кода по договору и переживаете, что разработчик будет использовать опен сорс
Ситуация
У вас есть ПО и его нужно дописать силами сторонних разработчиков (не сотрудников вашей компании);
Вы заказываете разработку ПО. Тип договора в данном случае не принципиален
Риски (магическим образом ровно те же, что и при недобросовестной разработке)
Программу нельзя будет включить в реестр отечественного ПО, а от этого зависит льгота по НДС. Ставка НДС сейчас 20%, так что это может быть довольно существенно;
Если в компанию зайдет новый инвестор или учредитель, он обратит внимание на проблемы с опен сорсом в программном обеспечении компании, что может повлиять на условия сделки
Программу будет сложно коммерциализировать (выдавать лицензии или продать);
Лицо, которое получило лицензию или купило программу, может потребовать возместить убытки. Это прямые расходы компании, судебные и репутационные издержки
Если вы руководитель и не подумали об этом, у вас могут быть проблемы на работе включая финансовые санкции и увольнение.
Важное уточнение - риски возникают при некорректном выборе свободной лицензии или при нарушении условий свободной лицензии. Сам по себе опен сорс не является проблемой или недостатком.
Что делать
Объективно заказчик далеко не всегда может проверить чистоту ПО. Экспертизы обычно не хватает, а аудит или специализированный софт для проверки - дополнительные расходы. Ключевая роль тут будет в условиях договора с исполнителем.
Вы можете:
Прописать конкретные разрешенные открытые лицензии;
Наоборот, прописать запрещенные к использованию открытые лицензии;
Указать, что исполнитель обязан указать все использованные свободные лицензии;
Предусмотреть возмещение убытков и/или выплату штрафов исполнителем в случае нарушения таких условий.
Расскажите вашему юристу для чего вы будете использовать ПО и попросите прописать эти гарантии.
Вариант 3. Вы написали код и думаете, под какой лицензией разместить
Ситуация
Вы разработали офигенный код и хотите рассказать об этом миру. Например, хотите опубликовать его на GitHub.
Риски
В целом, у вас тут все хорошо. Вы автор, вы решаете, кто и что будет делать с этим кодом.
Но есть некоторые особенности. Подумайте, захотите ли вы когда-либо использовать этот код эксклюзивно. Например, на следующий день после публикации вам позвонит CEO корпорации Big Numbers и предложит на базе этого кода сделать продукт в его компании. Или, возможно, вы захотите продавать ПО в дальнейшем.
Еще хорошо бы, чтобы условия лицензии предусматривали ограничение ответственности. То есть, чтобы ПО предоставлялось as is (как есть) и разработчик не возмещал убытки в случае каких-то проблем совместимости. Такое условие содержится во многих permissive лицензиях (об этом чуть ниже).
Также важно учитывать, что вы не обязаны публиковать ваш код с какой-то лицензией. Если вы не даете согласия на его использование - вы не выдали разрешение. Его использование будет неправомерным. Другой вопрос, что раскрытый вами же исходный код защитить сложно, но если вы не хотите заморачиваться с выбором лицензии - в данном случае это допустимо.
Что делать
Сохранить подтверждения того, что автор именно вы;
Выбрать удобную для вас лицензию. В качестве старта можно посмотреть либеральные лицензии из списка ниже;
Учитывать, использовали ли вы сами свободную лицензию. Возможно, она вам диктует, на какой лицензии публиковать ваш код
Некоторые виды лицензий: либеральные и вирусные
Все свободные лицензии делятся на две группы:
permissive (либеральные) - позволяют использовать свободное ПО для создания коммерческих программ с закрытым исходным кодом
copyleft (вирусные) - если разработчик использует ПО, распространяемое на условиях такой лицензии, то созданное в результате ПО должно распространяться на условиях такой же лицензии
Ниже я привожу ссылки на наиболее распространенные свободные лицензии для примера. если будете их использовать, пожалуйста, не забудьте перейти во вкладку Fulltext и внимательно прочитать условия лицензии.
Либеральные лицензии
Вирусные лицензии (копилефт)
Разобрать все лицензии в одной статье не получится, но давайте разберемся, на что вообще смотреть и обращать внимание.
Например, нам понравилась лицензия MIT. Читаем (ресурсы, где можно прочитать условия свободных лицензий, укажу ниже):
Это очень либеральная и простая лицензия. Она практически ничего от нас не требует.
Нужно:
Сохранять уведомление об авторском праве в каждой копии программного обеспечения. Ну то есть делаем файл с названием license, копируем туда условия полностью, сохраняем в корневом каталоге ПО;
Иметь в виду, что ПО предоставляется “как есть”, без гарантий (нормальная практика для либеральных лицензий)
Обратите внимание, что в википедии для этой лицензии указано “Копилефт - нет”. Для коммерческой разработки копилефт может не подойти.
Для контраста посмотрим копилефт лицензию GNU General Public License version 3. Сделать это одним скриншотом уже сложнее, лицензия более сложная. Весь текст можно посмотреть по ссылке, а я отражу основные условия, которые я бы отметила в первую очередь.
Такая лицензия сфокусирована на свободе пользователей. Если вы используете GNU GPL в своем ПО, то вы “заражаете” весь код. “Заражаете” в том смысле, что вы должны будете раскрыть исходный код вашего ПО, что очевидным образом препятствует его коммерциализации.
У вас появляются определенные обязанности. Например, сохранить все уведомления об отсутствии гарантий, включить в исходный текст уведомления о внесенных изменениях и ряд других
Вы никак не сможете пресечь дальнейшую доработку и распространение уже вашего ПО, в котором вы использовали GNU GPL
У GNU есть своя философия, она заслуживает уважения. Но на практике очень важно сверять, насколько условия лицензии подходят вам. Причем, речь не про одну эту копилефт лицензию - в каждой свои условия. Просто стоит привыкнуть внимательно читать условия лицензии или выбирать только знакомые разрешительные лицензии.
Полезные ссылки
Ресурсы для выбора лицензии
Англоязычный ресурс. На одной странице основные лицензии и условия. Каждую можно кликнуть и прочитать подробнее. https://choosealicense.com/appendix/
Еще один англоязычный ресурс для выбора лицензии https://tldrlegal.com/
Информация о лицензиях на русском языке licensit
Статьи на языке разработчика
Эти статьи хорошо дополняют мою, потому что я все-таки юрист и у меня немного другой фокус внимания.
Статья @marked-one Автор подробно разобрал условия отдельных лицензий. Статья написана в 2014 году, поэтому стоит перепроверять актуальность условий лицензий, но материал отличный
Статья @Mexos Автор разобрал условия некоторых лицензий. Нужно читать полный текст, но для стартового понимания отлично подходит
Статьи на юридическом языке
Статья Савельева А.И. Базовая информация о свободных лицензиях. Очень качественная статья, но может быть тяжеловато читать не юристу. Если вдруг вы юрист и почему-то читаете это - прочитайте книжку, она великолепна.
Статья на VC юридической фирмы Семенов и Певзнер с более подробным разбором условий GNU GPL.
Фух, кажется все. Вы еще тут, вы живы?
Спасибо большое, что дочитали до конца! Как всегда, буду рада вашим вопросам и комментариям.
