В связи с приближающейся аттестацией iOS-приложения в App Store, я задумался о том,
какую лицензию выставить простому open-source проекту, расположенному на Github-е?
В силу неведения я представляю, что мне нужна какая-то самая простая, самая свободная лицензия:
За свой код я ни перед кем не отвечаю
За мой код, его модификацию и использование никто не отвечает передо мной ;)
В силу простоты проекта и его специфичности смешно говорить о каких-либо "коммерческих целях" и прочем.
Если таких простых лицензий несколько, буду рад увидеть описание их различий. Также приветствуются любые дополнительные разъяснения по поводу лицензирования простого и безамбициозного open-source кода на github.
ОБНОВЛЕНО ПОЗЖЕ:
Да, мне известно, что существуют сайты, подобные http://www.tldrlegal.com/browse
Но мне было бы, скажем, удобно увидеть ответы вроде "у меня на гитхабе вот уже n штук проектов - и я использую такие и такие-то лицензии" прежде чем начинать вникать во всё это количество.
Другими словами, узнать, какие конкретно простые лицензии люди успешно используют для своих проектов (примеры приветствуются) да так, что эти проекты одобряются App Store.
ОБНОВЛЕНО ЕЩЁ ПОЗЖЕ:
Я разобрался с тем, какие бывают лицензии и, более точно, какую лицензию мне следует выбрать.
Судя по тому, что ни одного развёрнутого содержательного ответа так и не появляется, я делаю вывод, что должен написать ответ на этот топик сам. И я обязательно сделаю это после того, как проект в составе приложения окажется на App Store.
Ответ
Наконец, дошли руки написать ответ по теме лицензирования.
С момента создания этого топика прошло 1,5 года, и хотя за это время лично мне ни разу не пришлось столкнуться с проблемами лицензирования своего или использования чужого кода, мне кажется, что минимальные представления о лицензировании необходимы любому разработчику. Попробую отметить несколько моментов, которые считаю для себя ключевыми:
Отсутствие лицензии у проекта - плохо
Эта вещь может быть совершенно неочевидной, но проект, который не содержит лицензии, максимально защищен: все права принадлежат автору, и вы никак не можете его использовать. Точка.
No license
То есть, если вы используете проект без лицензии, вы подвергаете себя неопределенных размера и качества риску, который пропорционален "серьезности" проекта и случайному стечению обстоятельств. Если вы публикуете куда-либо, например, на Github, свой собственный проект-фреймворк-библиотеку без лицензии, вы подвергаете риску кого-то другого.
В одной из статей, ссылки на которые я привожу ниже, есть совет (цитирую вольно): "если вы заметили, что в некоем проекте на Github отсутствует лицензия, создайте pull request и предложите автору какую-нибудь свободную лицензию вроде Apache License v2. Если он в своем уме, то он задумается, если нет, то по крайней мере вы попытались".
Алгоритм разбора лицензий, который используется в процессе AppStore review как бы не суров, но все равно пренебрегать им не стоит
Теперь, имея чуть больше знаний о лицензировании, я понимаю, что Apple многих огрешностей в лицензировании или не видит, или "сознательно" игнорирует.
Например, в одно из своих приложений я несколько раз включал очень сильно модифицированную мной версию third-party библиотеки, распространяемой по лицензии Apache License v2. Согласно этой лицензии, я должен был задокументировать все свои изменения в заголовках модифицированных файлов. Я этого по незнанию, конечно же, не сделал. Очевидно, что на это никто не обратил внимание, и я пока ни разу не слышал от коллег, чтобы они столкнулись с вниманием Apple к такого рода мелким огрехам.
Здравый смысл и отсутствие сведений о противоположном заставляют думать, что AppStore пропускает приложения и с гораздо более грубыми нарушениями лицензирования, и что зависит это скорее всего от того, насколько "рыба крупная": количества денег, завязанных на приложении, размера целевой аудитории и т.д.
Несмотря на отсутствие видимой строгости со стороны Apple, теперь я достаточно строго следую правилам лицензий, которые указаны в third-party проектах и теперь уже автоматически всегда обращаю внимание на то, какая именно лицензия передо мной, есть ли у нее специальные добавления, правки и.т.п.
Необходимость наличия файла лицензии в проекте (и в исходных файлах проекта)
Например, если ваш проект использует лицензию MIT, то простого указания "этот проект использует лицензию MIT" будет недостаточно.
Вот отрывок из Лицензии MIT
Указанное выше уведомление об авторском праве и данные условия должны быть включены во все копии или значимые части данного Программного Обеспечения.
Поэтому в случае с MIT необходимо наличие файла с лицензией LICENSE в корне проекта, и очень желательно присутствие текста лицензии в заголовке каждого файла исходного кода, Пример: Alamofire
В случае с Apache License 2.0 также необходимо наличие файла с лицензией, но нет необходимости включать текст самой лицензии в файлы исходного кода, будет достаточно лишь ссылки на лицензию, Пример: Realm
Выбор лицензии
MIT License - это самая распространенная лицензия для проектов под iOS/OSX на Github. Если совсем нет желания разобраться в лицензировании, можно абсолютно спокойно выбирать ее и считать, что вопрос решен, однако лучше знать хотя бы о следующих видах лицензий:
Apache License 2.0 и BSD 2-clause “Simplified” License
Полезно знать, что лицензии GPL не совместимы с AppStore: Is it possible to have GPL software in the Mac App Store?
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:
EXPORT COMPLIANCE
You understand that the Software may contain cryptographic functions that may be
subject to export restrictions, and you represent and warrant that you are not
located in a country that is subject to United States export restriction or embargo,
including Cuba, Iran, North Korea, Sudan, or Syria, and that you are not on the
Department of Commerce list of Denied Persons, Unverified Parties, or affiliated
with a Restricted Entity.
(теперь я очень легко могу представить себя гражданином Ирана, который по поводу этой лицензии напишет письмо разработчикам Realm с просьбой прояснить этот пункт).
Ссылки
Помимо сервиса для выбора лицензии, который порекомендовал @aknew: Software Licenses in Plain English, есть еще один, тоже интересный: Choosing an OSS license doesn’t need to be scary
А вот две статьи, которые я очень советую прочитать всем, кто заинтересовался этой темой:
Github needs to take open source seriously
Using CocoaPods Without Going to Court
Комментариев нет:
Отправить комментарий