Какую Open source лицензию выбрать?
На самом деле универсального ответа на этот вопрос нет. Всё, как обычно, зависит от целей проекта и личных предпочтений автора. Open source лицензий великое множество и каждый может выбрать абсолютно любую. Главное, что нужно помнить, open source — это не код без лицензии.
Даже для мини-проектов на github нужно указывать лицензии. Зачем? Допустим, Вы сделали небольшую, но крайне полезную библиотеку. Допустим, её нашёл какой-нибудь разработчик и захочет использовать в своём коммерческом приложении. Но ни одна компания в здравом уме не будет использовать библиотеку без лицензии. Никому не нужны проблемы с юристами. Именно поэтому, Ваш, хоть и полезный проект, не будет использован. А разработчики вынуждены будут либо использовать альтернативы, либо полностью переписывать Ваш код. Чтобы избежать этой ситуации, лучше озаботиться правильной лицензией заранее.
Зоопарк
Существует целый зоопарк Open source лицензий. Наверное, именно поэтому, разработчики не заморачиваются и просто не указывают лицензию. Однако, разобраться с ними достаточно просто.
Дэвид провёл небольшое исследование и собрал наиболее популярные open source лицензии на одной картинке. Если вкратце, то все open source лицензии условно можно разделить на 3 основные группы:
- Разрешающие (permissive)
- Слабо защищающие (weak protective)
- Сильно защищающие (strong protective)
Стрелочками указана совместимость между лицензиями. Например, разрабатывая программу под GPLv3, Вы можете включать в неё компоненты, выпущенные по лицензии Apache 2.0. Но не наоборот.
Разрешающие
Наиболее распространённые лицензии — это MIT, BSD и Apache 2.0. За небольшими девиациями, эти лицензии позволяют использовать код как в коммерческих, так и в open source проектах. Главное указывать авторство оригинальной программы. Полное описание доступно по ссылкам выше.
Слабо защищающие
Различные варианты Lesser GPL. Основное отличие от разрешающих лицензий — это необходимость предоставлять исходные коды и лицензировать программу под GPL лицензией (копилефт). При этом, если в Вашем проекте используется библиотека (динамическая линковка или статическая) под лицензией LGPL, то она будет совместима с любой лицензией Вашего проекта.
Сильно защищающие
Различные варианты GPL. Эти лицензии требуют раскрытие исходных кодов и лицензирование проекта, независимо от того, как используется библиотека.
Немного экзотики
Существует ещё одна достаточно полезная лицензия — GPLv2 with classpath extensions. Она используется компанией Oracle для лицензирования своих open source решений. Зачем она вообще нужна и чем отличается от обычной LGPL?
Для начала нужно сказать, что все “классические” GPL лицензии не работают с такой штукой как байт-код. В них есть описание процесса линковки и компиляции, что совсем не подходит интерпретируемым языкам, в том числе Java. Для этого как раз и была выпущена специальная лицензия GPLv2 with classpath extensions. Она ясно и чётко говорит, что библиотеки, выпущенные под этой лицензией можно использовать в коммерческих приложениях с любой другой лицензией.
Выбор лицензии
После того как лицензия выбрана, её достаточно добавить в корень проекта. Это можно сделать во время создания проекта или в любое другое время. Например, github сделали очень удобный способ добавления лицензии при старте проекта:
license_finder
Однако, это ещё не всё. Нужно проверить все зависимости, которые использованы в проекте. Если одна из зависимостей в проекте выпущена под лицензией GPL, то и Ваш проект должен быть GPL-совместим. Для такой проверки есть очень удобный инструмент — license_finder. Он поддерживает все современные системы сборки и может получить лицензии всех зависимых библиотек.
На картинке выше, эта программа автоматически определила систему управления зависимостями maven и прошлась по каждой из них. В результате найдено множество зависимостей и напротив каждой из них проставлено название лицензии.
Программа сама не разрешает конфликтов между лицензиями и не выбирает правильную. Это лишь удобный инструмент просмотреть лицензии всех своих зависимостей. Разруливать конфликты нужно вручную. Для этого можно добавить лицензии в список разрешённых.
После того как лицензии вручную одобрены, программа создаст файл doc/dependency_decisions.yml . В этом файле будет список всех разрешённых лицензий.
Ну и вишенкой на торте будет добавление license_finder шагом сборки в CI. Если он найдёт не одобренную лицензию, то статус код будет не равен 0, и сборка упадёт. Очень удобно, если случайно добавили новую зависимость, но не посмотрели её лицензию. Вот пример добавления в travis-ci:
Выбор правильной лицензии для open-source проекта на Objective-C, чтобы не было проблем с App Store?
В силу неведения я представляю, что мне нужна какая-то самая простая, самая свободная лицензия:
- За свой код я ни перед кем не отвечаю
- За мой код, его модификацию и использование никто не отвечает передо мной 😉
- В силу простоты проекта и его специфичности смешно говорить о каких-либо «коммерческих целях» и прочем.
Если таких простых лицензий несколько, буду рад увидеть описание их различий. Также приветствуются любые дополнительные разъяснения по поводу лицензирования простого и безамбициозного open-source кода на github.
Да, мне известно, что существуют сайты, подобные http://www.tldrlegal.com/browse.
Но мне было бы, скажем, удобно увидеть ответы вроде «у меня на гитхабе вот уже n штук проектов — и я использую такие и такие-то лицензии» прежде чем начинать вникать во всё это количество.
Другими словами, узнать, какие конкретно простые лицензии люди успешно используют для своих проектов (примеры приветствуются) да так, что эти проекты одобряются App Store.
ОБНОВЛЕНО ЕЩЁ ПОЗЖЕ:
Я разобрался с тем, какие бывают лицензии и, более точно, какую лицензию мне следует выбрать.
Судя по тому, что ни одного развёрнутого содержательного ответа так и не появляется, я делаю вывод, что должен написать ответ на этот топик сам. И я обязательно сделаю это после того, как проект в составе приложения окажется на App Store.
Наконец, дошли руки написать ответ по теме лицензирования.
С момента создания этого топика прошло 1,5 года, и хотя за это время лично мне ни разу не пришлось столкнуться с проблемами лицензирования своего или использования чужого кода, мне кажется, что минимальные представления о лицензировании необходимы любому разработчику. Попробую отметить несколько моментов, которые считаю для себя ключевыми:
Отсутствие лицензии у проекта — плохо
Эта вещь может быть совершенно неочевидной, но проект, который не содержит лицензии, максимально защищен: все права принадлежат автору, и вы никак не можете его использовать. Точка.
То есть, если вы используете проект без лицензии, вы подвергаете себя неопределенных размера и качества риску, который пропорционален «серьезности» проекта и случайному стечению обстоятельств. Если вы публикуете куда-либо, например, на Github, свой собственный проект-фреймворк-библиотеку без лицензии, вы подвергаете риску кого-то другого.
В одной из статей, ссылки на которые я привожу ниже, есть совет (цитирую вольно): «если вы заметили, что в некоем проекте на Github отсутствует лицензия, создайте pull request и предложите автору какую-нибудь свободную лицензию вроде Apache License v2. Если он в своем уме, то он задумается, если нет, то по крайней мере вы попытались».
Алгоритм разбора лицензий, который используется в процессе AppStore review как бы не суров, но все равно пренебрегать им не стоит
Теперь, имея чуть больше знаний о лицензировании, я понимаю, что Apple многих огрешностей в лицензировании или не видит, или «сознательно» игнорирует.
Например, в одно из своих приложений я несколько раз включал очень сильно модифицированную мной версию third-party библиотеки, распространяемой по лицензии Apache License v2. Согласно этой лицензии, я должен был задокументировать все свои изменения в заголовках модифицированных файлов. Я этого по незнанию, конечно же, не сделал. Очевидно, что на это никто не обратил внимание, и я пока ни разу не слышал от коллег, чтобы они столкнулись с вниманием Apple к такого рода мелким огрехам.
Здравый смысл и отсутствие сведений о противоположном заставляют думать, что AppStore пропускает приложения и с гораздо более грубыми нарушениями лицензирования, и что зависит это скорее всего от того, насколько «рыба крупная»: количества денег, завязанных на приложении, размера целевой аудитории и т.д.
Несмотря на отсутствие видимой строгости со стороны Apple, теперь я достаточно строго следую правилам лицензий, которые указаны в third-party проектах и теперь уже автоматически всегда обращаю внимание на то, какая именно лицензия передо мной, есть ли у нее специальные добавления, правки и.т.п.
Необходимость наличия файла лицензии в проекте (и в исходных файлах проекта)
Например, если ваш проект использует лицензию MIT, то простого указания «этот проект использует лицензию MIT» будет недостаточно.
Указанное выше уведомление об авторском праве и данные условия должны быть включены во все копии или значимые части данного Программного Обеспечения.
Поэтому в случае с MIT необходимо наличие файла с лицензией LICENSE в корне проекта, и очень желательно присутствие текста лицензии в заголовке каждого файла исходного кода, Пример: Alamofire.
В случае с Apache License 2.0 также необходимо наличие файла с лицензией, но нет необходимости включать текст самой лицензии в файлы исходного кода, будет достаточно лишь ссылки на лицензию, Пример: Realm.
Выбор лицензии
MIT License — это самая распространенная лицензия для проектов под iOS/OSX на Github. Если совсем нет желания разобраться в лицензировании, можно абсолютно спокойно выбирать ее и считать, что вопрос решен, однако лучше знать хотя бы о следующих видах лицензий:
iOS/OSX dynamic frameworks / CocoaPods / Carthage
Вопрос с лицензированием, возможно, становится слегка более острым в связи с тем, что в связи с появлением iOS dynamic frameworks сейчас все большее количество iOS-разработчиков начинает использовать CocoaPods с опцией use_frameworks! , многие переходят на Carthage, а некоторые и вовсе переходят на ручное управление фреймворками. Все эти три способа предполагают, что есть множество папок с расширением .framework, которые лежат внутри архива приложения, отдельно от него, что автоматически как бы намекает на необходимость наличия в папках этих фреймворков файлов LICENSE.
Хороший пример: база данных Realm, поддерживающая все перечисленные виды распространения и содержащая в своих Realm.framework/Resources файл составной лицензии. Кстати, в этой лицензии есть очень интересные строки, согласно которым, если я правильно понимаю, пользователь Realm не может находиться в странах Cuba, Iran, North Korea, Sudan, or Syria:
(теперь я очень легко могу представить себя гражданином Ирана, который по поводу этой лицензии напишет письмо разработчикам Realm с просьбой прояснить этот пункт).
Ссылки
Помимо сервиса для выбора лицензии, который порекомендовал @aknew: Software Licenses in Plain English, есть еще один, тоже интересный: Choosing an OSS license doesn’t need to be scary.
А вот две статьи, которые я очень советую прочитать всем, кто заинтересовался этой темой:
В чём разница между популярными Open Source лицензиями? Объясняет Github
В сентябре Github добавила на страницы проектов, которые используют стандартные Open Source лицензии, секцию, в которой эта лицензия указывается:
После переработки условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что — нет. С этой целью на страницу просмотра файла LICENSE из корневой директории проекта были добавлены краткие сведения о лицензии с сайта Choose A License:
Мы решили перевести для вас эти замечания, чтобы вы в случае необходимости могли быстро вспомнить, зачем нужна та или иная лицензия. Ниже мы приводим краткие описания лицензий и таблицы, которые содержат три колонки:
- Первая содержит информацию о том, что лицензия вам разрешает делать с проектом (авторское право или закрытые лицензии обычно, напротив, запрещают делать это);
- Вторая — о том, какие ограничения лицензия накладывает на тех, кто модифицирует или распространяет работу;
- Последняя — о том, чего лицензия не гарантирует и чего не разрешает.
Пояснения некоторых значений таблиц
Разрешения * распространять, * использовать в коммерческих целях или * изменять работу значат ровно то, что написано — вы можете пользоваться этими правами, но лишь до тех пор, пока соблюдаете условия, указанные в секциях * «Требует» и * «Запрещает».
Пункт * «Разрешает личное использование» (англ. private use) означает, что если вы изменяете работу, вы не обязаны её распространять — на своей машине вы можете делать с кодом всё, что захотите.
Пункт * «Предоставление патентных прав» означает что соавторы работы (контрибьюторы) отказываются от патентных прав (если они есть) на те части кода, которые они добавили; это гарантирует безопасность при использовании работы — иск на вас точно не подадут.
Пункты * «Отказ от ответственности» и * «Никакой гарантии» означают, что ни при каких условиях авторы произведения не могут быть ответственны за последствия его использования, продажи и вообще чего угодно.
GNU AGPLv3
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Использование по сети приравнивается к распространению
* Производные продукта необходимо выпускать под той же лицензией
Запрещает:
* Отказ от ответственности
* Никакой гарантии
Это самая сильная копилефтная лицензия из всех существующих. Она разрешает делать с кодом всё, что угодно, но взамен от всех, кто изменяет или распространяет произведение, требуется указание исходного авторства, распространение исходного кода вместе с работой (или предоставление его по первому требованию), а также указание того, что в работу были внесены изменения. При этом производные работы должны публиковаться строго под этой же лицензией, без исключений. Лицензия гарантирует, что к пользователю (распространителю) не будут применены никакие требования из-за патентных прав.
Отличительной особенностью этой лицензии от основной лицензии GPL является то, что если кто-то предоставляет доступ к программе по сети (например, через интернет), то это считается распространением, а значит, распространитель обязан представлять исходный код, если от него этого потребуют.
GNU GPLv3
Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Производные продукта необходимо выпускать под той же лицензией
Запрещает:
* Отказ от ответственности
* Никакой гарантии
Это самая популярная копилефтная лицензия. От предыдущей она отличается только тем, что не приравнивает использование программы по сети к её распространению.
GNU LGPLv3
Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки)
Запрещает:
* Отказ от ответственности
* Никакой гарантии
От основной GPL лицензии эта отличается тем, что использование работы под LGPL в качестве части для большей работы (т.е. в качестве библиотеки) не накладывает требования лицензировать большую работу под LGPL, или открывать её исходный код. Но код самой библиотеки все равно должен предоставляться по первому требованию.
Mozilla Public License 2.0
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
* Распространять исходный код вместе с продуктом (в случае использования в качестве библиотеки — только исходный код библиотеки)
* Упоминания авторства и лицензии в работе
* Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки)
Запрещает:
* Отказ от ответственности
* Никакой гарантии
* Не передаются права на торговые марки
Ещё одна лицензия, которая хорошо подходит для библиотек из-за слабого копилефта. В отличие от LPGL, при использовании работы под этой лицензией в качестве библиотеки, не нужно открывать даже исходный код самой библиотеки, равно как и указывать изменения, которые были внесены в работу.
Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговым марками.
The MIT License
Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
Требует:
* Упоминания авторства и лицензии в работе
Запрещает:
* Отказ от ответственности
* Никакой гарантии
Одна из так называемых «разрешительных» лицензий — с работой можно делать что угодно до тех пор, пока вы указываете автора оригинальной работы. Производные работы можно выпускать под другой лицензией и не открывать их исходники. Однако эта лицензия не гарантирует пользователю патентных прав, поэтому вместо неё рекомендуется использовать Apache License, которая приведена ниже.
Apache License 2.0
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
Запрещает:
* Никаких обязательств
* Никакой гарантии
* Не передаются права на торговые марки
Ещё одна разрешительная лицензия — от пользователей она требует только, если работа была изменена, писать об этом, и, конечно, указывать исходное авторство. Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговым марками.
The Unlicense
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав
Требует:
(Ничего не требует)
Запрещает:
* Никаких обязательств
* Никакой гарантии
Выпуская работу под этой лицензией, вы отказываетесь от всех прав на неё, буквально передавая её в общественное достояние — на тех, кто её использует, не накладывается никаких ограничений. Приятная новость в том, что вы не будете нести ответственность за то, что написали — отсутствие гарантии здесь прописано так же, как и везде.
А как же остальные лицензии? Как же BSD?
Этого набора более чем достаточно, если вы хотите выбрать лицензию для своего Open Source проекта — не надо писать свою лицензию или использовать что-то более специфическое. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом — актуальная проблема Open Source. Лицензия BSD достаточно популярна, но её сокращённый вариант полностью совпадает по смыслу с лицензией MIT, и GNU советуют использовать именно последнюю. Если же вы столкнулись с проектом, который использует какую-то нестандартную лицензию, и хотите узнать, что она вам разрешает, вы можете подсмотреть в шпаргалке на сайте Choose A License.
Лицензирование репозитория
Общедоступные репозитории в GitHub часто применяются для совместного использования ПО с открытым кодом. Чтобы репозиторий действительно был репозиторием с открытым кодом, вам потребуется лицензировать его, чтобы другие пользователи могли использовать, изменять и распространять программное обеспечение.
Выбор подходящей лицензии
Мы создали choosealicense.com, чтобы помочь вам понять, как лицензировать код. Лицензия на программное обеспечение сообщает другим пользователям, что им можно делать с исходным кодом, а что делать нельзя, поэтому им важно принять обоснованное решение.
Вы не обязаны выбирать лицензию. Однако без лицензии применяются законы об авторских правах по умолчанию, то есть вы сохраняете все права на исходный код, а остальным запрещено воспроизводить и распространять вашу работу и создавать производные от нее. Если вы создаете проект с открытым кодом, мы настоятельно рекомендуем включить лицензию с открытым кодом. Руководство по открытому коду предоставляет дополнительные рекомендации по выбору правильной лицензии для проекта.
Примечание: Если вы публикуете исходный код в общедоступном репозитории в GitHub, в соответствии с условиями обслуживаниядругие пользователи GitHub.com имеют право просматривать и создавать вилку репозитория. Если вы уже создали репозиторий и больше не хотите, чтобы пользователи имели доступ к нему, вы можете сделать репозиторий закрытым. При изменении видимости репозитория на частный, существующие вилки или локальные экземпляры, созданные другими пользователями, по-прежнему будут существовать. Дополнительные сведения см. в разделе Настройка видимости репозитория.
Определение расположения лицензии
Большинство пользователей помещают текст лицензии в файл с именем LICENSE.txt (или LICENSE.md ) LICENSE.rst в корень репозитория. Вот пример от Hubot.
В некоторых проектах сведения о лицензии приводятся в файле README. Например, README проекта может включать примечание о том, что этот проект лицензирован в соответствии с условиями лицензии MIT.
Рекомендуется включить в проект отдельные файл лицензии.
Поиск в GitHub по типу лицензии
Вы можете отфильтровать репозитории на основе их лицензии или семейства лицензий с помощью квалификатора license и точного ключевого слова лицензии:
| Лицензия | Ключевое слово лицензии |
|---|---|
| Academic Free License v3.0 | afl-3.0 |
| Apache license 2.0 | apache-2.0 |
| Artistic license 2.0 | artistic-2.0 |
| Boost Software License 1.0 | bsl-1.0 |
| BSD 2-clause «Simplified» license | bsd-2-clause |
| BSD 3-clause «New» or «Revised» license | bsd-3-clause |
| BSD 3-clause Clear license | bsd-3-clause-clear |
| Creative Commons license family | cc |
| Creative Commons Zero v1.0 Universal | cc0-1.0 |
| Creative Commons Attribution 4.0 | cc-by-4.0 |
| Creative Commons Attribution Share Alike 4.0 | cc-by-sa-4.0 |
| Do What The F*ck You Want To Public License | wtfpl |
| Educational Community License v2.0 | ecl-2.0 |
| Eclipse Public License 1.0 | epl-1.0 |
| Eclipse Public License 2.0 | epl-2.0 |
| European Union Public License 1.1 | eupl-1.1 |
| GNU Affero General Public License v3.0 | agpl-3.0 |
| GNU General Public License family | gpl |
| GNU General Public License v2.0 | gpl-2.0 |
| GNU General Public License v3.0 | gpl-3.0 |
| GNU Lesser General Public License family | lgpl |
| GNU Lesser General Public License v2.1 | lgpl-2.1 |
| GNU Lesser General Public License v3.0 | lgpl-3.0 |
| ISC | isc |
| LaTeX Project Public License v1.3c | lppl-1.3c |
| Microsoft Public License | ms-pl |
| MIT | mit |
| Mozilla Public License 2.0 | mpl-2.0 |
| Open Software License 3.0 | osl-3.0 |
| PostgreSQL License | postgresql |
| SIL Open Font License 1.1 | ofl-1.1 |
| University of Illinois/NCSA Open Source License | ncsa |
| The Unlicense | unlicense |
| zLib License | zlib |
При поиске по семейству лицензий результаты будут включать все лицензии в этом семействе. Например, при использовании запроса license:gpl результаты будут включать репозитории, лицензированные в соответствии с GNU General Public License v2.0 и GNU General Public License v3.0. Дополнительные сведения см. в разделе Поиск репозиториев.
Gem Ruby с открытым кодом Licensee сравнивает файл LICENSE репозитория с коротким списком известных лицензий. Licensee также предоставляет Licenses API и дает нам представление о том, как лицензированы репозитории в GitHub. Если ваш репозиторий использует лицензию, которая не указана на веб-сайте выбора лицензии, вы можете запросить лицензию.
Если репозиторий использует лицензию, указанную на веб-сайте выбора лицензии, и она не отображается в верхней части страницы репозитория, он может содержать несколько лицензий или другие сложности. Чтобы вашу лицензию было легко обнаружить, упростите файл LICENSE и укажите сложность в другом месте, например в файле README репозитория.
Применение лицензии к репозиторию с существующей лицензией
Средство выбора лицензий доступно только при создании нового проекта на GitHub.
Вы можете вручную добавить лицензию с помощью браузера. Дополнительные сведения о добавлении лицензии в репозиторий см. в разделе Добавление лицензии в репозиторий.
Отказ от ответственности
Цель лицензирования открытого кода GitHub заключается в предоставлении отправной точки, чтобы помочь вам сделать обоснованный выбор. GitHub отображает сведения о лицензиях, чтобы помочь пользователям получать сведения о лицензиях с открытым кодом и проектах, которые их используют. Мы надеемся, что это поможет, но, пожалуйста, имейте в виду, что мы не юристы и можем ошибаться, как и все остальные. По этой причине GitHub предоставляет информацию на условиях «как есть» и не дает никаких гарантий в отношении какой-либо информации или лицензий, предоставленных в нем или им, а также отказывается от ответственности за ущерб, вызванный использованием информации о лицензиях. Если у вас возникли вопросы о выборе лицензии для вашего кода или любые другие юридические вопросы по этой теме, всегда лучше проконсультироваться с профессионалом.