Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 117
Круто! Очень подробно и доходчиво, спасибо.
Не совсем. GPL 2 не упомянута, однако, многие пользуются этой версией. Из наиболее известных проектов — ядро Linux, хотя RMS лично уговаривал Линуса перейти на третью GPL. GPLv3 заметно строже и может создать некоторые проблемы автору. Например, одно из требований состоит в том, что должна быть предоставлена инструкция по установке изменённого приложения на устройство. Для приложений под iOS или WindowsPhone, где нет штатной возможности установить пакет не из магазина, выполнить такое требование проблематично.
Для проекта open source стоит ещё рассмотреть MPL 2.0. Своеобразная лицензия, что-то среднее между LGPL и BSD. От LGPL отличается отсутствием заморочек со статическим связыванием. Это может оказаться важным для программ на ЯП, в которых динамическое связывание не предусмотрено.
А что будет человеку, который использовал, к примеру, программу с лицензией GPLv3, но не выложил свои исходники? Он же может сказать, что сейчас у него нет времени, когда-нибудь потом выложу и будет кормить завтраками.
В теории он может и не выкладывать. Он должен предоставить по первому требованию любому потребовавшему, а если не предоставит, то это — нарушение условий лицензии, которое может повлечь за собой судебный иск, например.
Если использует программу для себя, не распространяя, то может и не выкладывать исходники, насколько я понимаю… А если распространяет не публикуя код, то вполне могут (тот же FSF) как минимум напихать палок в колеса, например, поспособствовать удалению из всех маркетов…
Прошу прощения. Я был неточен в статье, но coh и x0wl меня поправили: он не обязан выкладывать исходники, он обязан предоставить их конечным пользователям.Вот здесь подробнее: geektimes.ru/post/45878/
Если он не предоставит исходники, то тогда все зависит от пользователя: тот может обидиться, а может и в суд.
Если он не предоставит исходники, то тогда все зависит от пользователя: тот может обидиться, а может и в суд.
Но где границы этой обиды и подачи в суд? Допустим, я скажу, что сейчас у меня сломался компьютер, умер хомяк, уезжаю в командировку в Антарктиду и не могу сейчас предоставить исходники. Насколько я понимаю, это нигде не прописано и имеется множество причин откладывать выполнение требования.
Границы там, где сочтет нужным обиженный.
Как я написал в статье, лицензия — это договор. Вы, как разработчик, по нему обязуетесь выполнить одни условия, пользователь — другие. Если кто-то не выполняет условия договора — то это повод второму для обращения в инстанции. А границы в этом случае установит судья. Ну, или присяжные.
Лучшая лицензия: en.wikipedia.org/wiki/Beerware
/*
* — * «THE BEER-WARE LICENSE» (Revision 42):
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
* — */
Совершенно забыта самая правильная лицензия для тех, кто не знает, под какой лицензией выложить кусок кода — WTFPL:
ru.wikipedia.org/wiki/WTFPL
ru.wikipedia.org/wiki/WTFPL
Добавил WTFPL в статью, спасибо.
Кстати, регулярно пользуюсь. Очень удобно для всяких мелочей, которые лень лицензировать по-человечески.
У неё есть один существенный недостаток: она никак не ограничивает ответственность автора. Всякие отказы от гарантий и тому подобные вещи пишут не просто так, а для того, чтобы обезопасить себя от претензий пользователей, у которых что-то пошло не так.
Это хлам с пиаром автора. Строчка по сути, пять строчек про копирайт на текст лицензии, версии, даты и прочий мусор. Тьфу. Лучше уж так:
Ну а если серьёзно, то реальная минимальная лицензия с аналогичным результатом («почти PD») — Unlicense.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE*
TERMS AND CONDITIONS
1. You just DO WHAT THE FUCK YOU WANT TO.
Ну а если серьёзно, то реальная минимальная лицензия с аналогичным результатом («почти PD») — Unlicense.
За поиском определения я отправлю желающих на Википедию, для чего дам ссылки сразу на несколько статей:Лично для меня наиболее интересно было бы узнать, как это всё соответствует 4 части ГК РФ. Если никак, то какой смысл в этих рассуждениях? Бить-то будут по мне, а не по Столмену.
…
Я боюсь, что Вам мало кто сможет ответить. Лучше всего обратиться к юристу, причем, серьезно занимающемуся лицензиями на ПО и авторскими правами. И не с заявленями Столлмана, а с какой-либо конкретно интересующей лицензией, дабы разобраться о ее соответствии законам и правоприменению в РФ. И, честно говоря, я все равно не уверен, что юрист сможет Вам все разложить по полочкам, так как наши законы (равно как и их отсутствие по конкретной теме) порой могут трактоваться весьма интересными способами.
Возможно, Вам будет полезна вот эта ссылка: licenseit.ru/wiki/index.php, упомянутая sensboston ниже в комментариях.
Над реальными проектами трудятся команды разработчиков. Не совсем понятно, как применять лицензию в этом случае. Допустим, один разработчик создал файл, и в шапке указал копирайт на своё имя. Если другие разработчики вносят изменения в этот файл, должны ли они себя так же добавлять в шапку? Ведь по сути, изменения — это тоже продукт интеллектуальной работы.
Авторы изменений обычно отмечаются в системе контроля версий или в патчах…
Владелец прав на распространение (копирайт) != автор. Если над проектом работает команда, то создаётся компания/команда/группа и копирайт оформляется на неё. А авторы указываются отдельно.
Будет несколько строчек с копирайтом, как в примере.
Если же все они работники компании, то, как вам правильно ответили, правообладателем, скорее всего, является компания, и будет указана она.
// Copyright © 2022 John Doe
// Copyright © 2023-2028 Jane Doe
// Copyright © 2028-2096 Acme Corporation.
Если же все они работники компании, то, как вам правильно ответили, правообладателем, скорее всего, является компания, и будет указана она.
Небольшая неточность.
На сколько я помню, вы не обязаны предоставлять исходники программы всем желающим. Если вы взяли GPLv3 код и сделали приложение (для себя) и не распространяете его, вы не обязаны предоставлять исходный код всем кому попало. Таким образом, вы обязаны предоставить исходники только своим конечным получателям. Вы можете не распространять программу бесплатно, брать некую сумму, но в таком случае вы обязаны исходный код под GPLv3 и не можете как-то ограничить получателя. Проще говоря, ваш клиент может начать раздавать приложение бесплатно модифицировать, создавать производные продукты.
Мне кажется это очень важная деталь про которую забывают, поправьте меня если я ошибаюсь.
если вы решите использовать библиотеку под GPLv3 в вашем проекте, вам придется выложить исходники вашего проекта под GPL
На сколько я помню, вы не обязаны предоставлять исходники программы всем желающим. Если вы взяли GPLv3 код и сделали приложение (для себя) и не распространяете его, вы не обязаны предоставлять исходный код всем кому попало. Таким образом, вы обязаны предоставить исходники только своим конечным получателям. Вы можете не распространять программу бесплатно, брать некую сумму, но в таком случае вы обязаны исходный код под GPLv3 и не можете как-то ограничить получателя. Проще говоря, ваш клиент может начать раздавать приложение бесплатно модифицировать, создавать производные продукты.
Мне кажется это очень важная деталь про которую забывают, поправьте меня если я ошибаюсь.
А как это будет относиться к веб-приложению?
Например я выпускаю веб-сервис для поиска пропавших котят на платной основе. Для какой-то функциональности на серверной стороне я использую библиотеку под GPLv3. Я должен каким-то образом предоставлять код пользователю?
Например я выпускаю веб-сервис для поиска пропавших котят на платной основе. Для какой-то функциональности на серверной стороне я использую библиотеку под GPLv3. Я должен каким-то образом предоставлять код пользователю?
А никак. Если предоставить возможность пользоваться сервисом, не распространяя его как приложение (например, реализовав его в виде веб-приложения), то можно не предоставлять исходный код, не нарушая при этом GPL. Чтобы закрыть эту лазейку и придумали AGPL — «усиленную» версию GPL, покрывающую и этот случай.
Фирма исполняет на сайте модифицированную версию программы под GPL. Сказано ли в GPL, что они должны выпустить свои модифицированные исходные тексты? (#UnreleasedMods)
GPL разрешает всем делать модифицированные версии и применять из безо всякой передачи другим. То, что делает эта фирма — особый случай таких действий. Следовательно, фирма не обязана выпускать модифицированные исходные тексты.
Важно, чтобы у людей была свобода вносить изменения для личного пользования безо всякой публикации этих изменений. Однако размещение программы на сервере, чтобы публика с ней общалась, едва ли является “личным” использованием, так что было бы законным потребовать выпуска исходного текста в этом особом случае. Разработчики, заинтересованные в этом, могут воспользоваться GNU Affero GPL для программ, составляемых для применения на сетевых серверах.
www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
GPL разрешает всем делать модифицированные версии и применять из безо всякой передачи другим. То, что делает эта фирма — особый случай таких действий. Следовательно, фирма не обязана выпускать модифицированные исходные тексты.
Важно, чтобы у людей была свобода вносить изменения для личного пользования безо всякой публикации этих изменений. Однако размещение программы на сервере, чтобы публика с ней общалась, едва ли является “личным” использованием, так что было бы законным потребовать выпуска исходного текста в этом особом случае. Разработчики, заинтересованные в этом, могут воспользоваться GNU Affero GPL для программ, составляемых для применения на сетевых серверах.
www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
Спасибо, полезно. Игру лицензировал под GPLv3 + CC-by для ресурсов. Подумываю об откате до GPLv2…
del
В лицензии Apache 2.0 написано, что надо ее упоминать во всех файлах. Но это написано после текста лицензии. В самом же тексте лицензии написано «as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below)». И из написанного в лицензии означает что достаточно «приаттачить» файл LICENSE к проекту.
Вопрос — под какой лицензией будет проект, выложенный на github, если в корне этого проекта находится файл с текстом лицензии Apache 2.0, но ни в одном исходном файле ничего не упоминается?
Вопрос — под какой лицензией будет проект, выложенный на github, если в корне этого проекта находится файл с текстом лицензии Apache 2.0, но ни в одном исходном файле ничего не упоминается?
Проект будет под лицензией Apache 2.0. Но если кто-то получит/увидит файл исходного кода отдельно от проекта, ему будет проблематично узнать, под какой лицензией он распространяется и кто обладает правами на него.
Но ведь шансы на это примерно такие же, как «кто-то получит файл исходного кода отдельно от проекта, от которого отрезали шапку»? Или я что-то неправильно понимаю?
Отрезать — это уже чьи-то специальные действия. А просто при отсутствии — это может произойти случайно. Вы нашли файл в поисковике и не посмотрели, к какому проекту он относится. Ваш коллега переслал Вам его по почте без должных комментариев. То есть, увеличивается шанс на ошибку. Другое дело, что шанс на то, что такая ошибка приведет к юридическим последствиям, весьма невелик.
Кстати, если говорить о процитированной Вами фразе: «made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below)», то copyright notice — это не сама лицензия. Это как раз строка, указывающая правообладателя. А «made available under the License, as indicated» означает, что еще должна быть явно указана лицензия. То есть, что-то вида:
Кстати, если говорить о процитированной Вами фразе: «made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below)», то copyright notice — это не сама лицензия. Это как раз строка, указывающая правообладателя. А «made available under the License, as indicated» означает, что еще должна быть явно указана лицензия. То есть, что-то вида:
Copyright 2013 John Doe Licensed under the Apache License, Version 2.0должно быть в проекте. Не обязательно в исходном коде, Apache 2.0 позволяет для этого использовать файл NOTICE. Думаю, немного поправлю в статье пункт про Apache.
WTFPL ещё есть для совсем простых случаев
Спасибо, но уже было: habrahabr.ru/post/243091/#comment_8123629
WTFPL теперь есть в статье, спасибо.
А подскажите по портированию библиотек:
Я взял класс из библиотеки под лицензией MIT, портировал на другой язык для библиотеки под BSD 3clause. Что я должен написать и где, чтобы соблюсти авторские права исходной библиотеки.
Также интересует та же ситуация, но только не при портировании на другой язык, а небольшом изменении кода для другой библиотеки
Я взял класс из библиотеки под лицензией MIT, портировал на другой язык для библиотеки под BSD 3clause. Что я должен написать и где, чтобы соблюсти авторские права исходной библиотеки.
Также интересует та же ситуация, но только не при портировании на другой язык, а небольшом изменении кода для другой библиотеки
1. Думаю, примерно так: скопировать файл LICENSE с лицензией MIT в новую библиотеку (или даже добавить прямо в существующий файл с BSD, указав, на какой файл она распространяется). К содержащемуся в лицензии копирайту/копирайтам добавить свой (Copyright 2014 quantum). Если копирайт был еще и в исходном файле с классом, то стоит его перенести и в новый файл. И добавить Ваш собственный.
2. Аналогично: указываете себя в качестве одного из авторов в лицензии. Если копирайты есть в файлах, то добавляетесь только в те файлы, где что-то меняли. Если изменяете лицензию, тоже придется держать в проекте обе лицензии.
Не забудьте, что у проектов могут иметься правила, куда нужно скопировать лицензию, и где указывать копирайт.
2. Аналогично: указываете себя в качестве одного из авторов в лицензии. Если копирайты есть в файлах, то добавляетесь только в те файлы, где что-то меняли. Если изменяете лицензию, тоже придется держать в проекте обе лицензии.
Не забудьте, что у проектов могут иметься правила, куда нужно скопировать лицензию, и где указывать копирайт.
С MIT есть один момент, который не совсем понятен (мне во всяком случае; IANAL): т.к. она явно разрешает sublicense, то требование "[t]he above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software" может быть нарушено уже на втором сублицензиате. Т.е. я беру код MIT, перелицензирую его под условной DCL (Devoid Copyright License), включаю оригинальное авторство, как того требует MIT, но последующие чуваки могут, по идее, делать с копирайтом что хотят.
Получается, что MIT — этакая 0-clause BSD, требущая указывать copyright notice лишь до первого заимствования (0-clause потому, что лишь в самой лицензии; в отличие от BSD, которая явно упоминает сорцы и бинарники, MIT определяет Software довольно общо: «software and associated documentation files»).
Получается, что MIT — этакая 0-clause BSD, требущая указывать copyright notice лишь до первого заимствования (0-clause потому, что лишь в самой лицензии; в отличие от BSD, которая явно упоминает сорцы и бинарники, MIT определяет Software довольно общо: «software and associated documentation files»).
А может ли кто-либо подсказать нарушаются ли права MS в след.случае:
Есть хидер поставляемый Microsoft при установке MS Visual Studio:
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\WinNT.h
В этом хидере есть заголовки описывающие формат PE32\PE32+, к примеру IMAGE_NT_HEADERS64, IMAGE_OPTIONAL_HEADER64 и др. Есть очень много OpenSource проектов, которые работают с PE-файлами и которые у себя в коде используют один в один названия из winnt.h
Нарушают ли эти Open-Source проекты права MS?
Есть хидер поставляемый Microsoft при установке MS Visual Studio:
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\WinNT.h
В этом хидере есть заголовки описывающие формат PE32\PE32+, к примеру IMAGE_NT_HEADERS64, IMAGE_OPTIONAL_HEADER64 и др. Есть очень много OpenSource проектов, которые работают с PE-файлами и которые у себя в коде используют один в один названия из winnt.h
Нарушают ли эти Open-Source проекты права MS?
Почему все говорят хидер, а не хедер? -___-'
Полагаю, потому, что в большинстве случаев «ea» читается как [i:]. И, несмотря на то, что ни разу не слышал произношения «head» как «хид», с header'ом извечная проблема у многих.
Спасибо за поправку. Но что с моим вопросом? ;)
Рискну предположить, что в случае серьезных разбирательств по подобному вопросу им бы занималась экспертная комиссия, состоящая из программистов и юристов (занимающихся плагиатом и авторским правом). Поэтому на Хабре Вам вряд ли ответят что-то конкретное. Но, Вы можете либо подать в суд, запастись деньгами и попкорном, и посмотреть, чем все закончится, либо найти знакомого профильного юриста и провести менее точное моделирование за бутылочкой горячительного.
Или стоит поискать в сети результаты по похожим случаям. Одну ссылку Вам уже предложили.
Или стоит поискать в сети результаты по похожим случаям. Одну ссылку Вам уже предложили.
Можно рассудить по аналогии с en.wikipedia.org/wiki/SCO_v._IBM
Спасибо за ссылку. Ваш ответ еще больше подталкивает к мысли: «Береженого бог бережет». Другими словами использование тех же имен для проектов особого преимущества не несет, но при этом добавляет возможные проблемы. Небольшим преимуществом может быть разве что привычные названия для программистов знающих формат и читавших документ. Еще раз Спасибо!
Ещё бы EPL описать.
А что на счет смены лицензии?
Например в процессе разработки я решил сменить лицензию с GPL на какую нибудь копилефтную или проприетарную. Какие подводные камни? Ведь получается что последующая версия программы основывается на исходных кодах, которые уже были выложены под GPL лицензией?
Например в процессе разработки я решил сменить лицензию с GPL на какую нибудь копилефтную или проприетарную. Какие подводные камни? Ведь получается что последующая версия программы основывается на исходных кодах, которые уже были выложены под GPL лицензией?
Автор может делать со своим кодом что захочет. В том числе и лицензию сменить. Предыдущие же версии так и останутся под старой лицензией — иначе это нарушает права пользователей.
Это не совсем так.
Статья 1269. Право на отзыв
1. Автор имеет право до фактического обнародования произведения отказаться от ранее принятого решения о его обнародовании (право на отзыв) при условии возмещения лицу, которому отчуждено исключительное право на произведение или предоставлено право использования произведения, причиненных таким решением убытков.
2. Правила настоящей статьи не применяются к программам для ЭВМ, к служебным произведениям и к произведениям, вошедшим в сложный объект
Вообще, где-то на Хабре, или на GT, это проскакивало в комментариях, иначе я бы так легко не нагуглил.
Статья 1269. Право на отзыв
1. Автор имеет право до фактического обнародования произведения отказаться от ранее принятого решения о его обнародовании (право на отзыв) при условии возмещения лицу, которому отчуждено исключительное право на произведение или предоставлено право использования произведения, причиненных таким решением убытков.
2. Правила настоящей статьи не применяются к программам для ЭВМ, к служебным произведениям и к произведениям, вошедшим в сложный объект
Вообще, где-то на Хабре, или на GT, это проскакивало в комментариях, иначе я бы так легко не нагуглил.
Еще можно множественную лицензию использовать.
Автор творит с последующими релизами что хочет. Если авторов несколько, то со всеми надо договориться.
А что насчет ресурсов? Распространяются ли копилефтные лицензии на ресурсы, обязан ли автор вместе с исходниками распространять ресурсы проекта и т.д.? Хотелось бы поподробнее на эту тему.
К сожалению, не могу ответить. Сам бы с удовольствием послушал того, кто в этом разобрался. Вроде бы, GPL распространяется только на код, а ресурсы идут под своими лицензиями. А, например, CC0 применяется ко всему проекту. А про другие лицензии и этого не могу сказать. Да и эти сведения требуют проверки.
Любой кусок может лицензироваться отдельно, если это не запрещено лицензией. Например:
Doom 3 = GPL (код открыт) / DSL (код открыт для некоммерческого использования) + EULA (использование ресурсов в игре продаётся);
Descent = NC (код открыт для некоммерческого использования) + EULA (использование ресурсов в игре продаётся);
WoW = EULA (код закрыт) + NC (ресурсы можно использовать для некоммерческого Machinima).
Doom 3 = GPL (код открыт) / DSL (код открыт для некоммерческого использования) + EULA (использование ресурсов в игре продаётся);
Descent = NC (код открыт для некоммерческого использования) + EULA (использование ресурсов в игре продаётся);
WoW = EULA (код закрыт) + NC (ресурсы можно использовать для некоммерческого Machinima).
Это-то понятно, что автор/правообладатель может разделить проект на несколько частей и открыть отдельно только код без ресурсов, или даже использовать множественную лицензию для кода, чтобы одновременно выложить код в открытый доступ и отдельно линковать с ресурсами под проприетарной лицензией для продажи, без обязательств раскрытия изменений или других проприетарных частей, как например Qt, думаю с думом так же (хаха, каламбур).
Больше интересует случай, когда я в свой проект добавляю GPL-код, который обязывает раскрывать мой код, то обязывает ли он раскрывать мои ресурсы, распространяется он на них или действует только на код?
Больше интересует случай, когда я в свой проект добавляю GPL-код, который обязывает раскрывать мой код, то обязывает ли он раскрывать мои ресурсы, распространяется он на них или действует только на код?
А меня интересует несколько иное. Предположим, у меня есть проект, который содержит код, и, скажем, изображения. Я создаю в проекте файл LICENSE и копирую туда текст лицензии (интересует, в общем-то, для всего списка лицензий из статьи), нигде не уточняя, к чему именно в проекте применяется лицензия. Будет ли в таком случае лицензия распространяться и на изображения? И как в этом случае понимать фразу про «исходные коды», если она упомянута в лицензии? Должен ли я буду с исходным кодом распространять исходники изображений (проекты Gimp или Photoshop)?
GPL — это лицензия для кода. Для ресурсов, документации лучше выбрать более подходящую лицензию. С кодом под GPL хорошо пойдут CC-BY-SA для ресурсов, GFDL для документации. У них та же идея, что и у GPL, но они подходят для графики и текстов.
В комплекте с пермиссивными лицензиями подойдёт CC-BY для контента. Если лицензия MIT, которая не говорит про сорцы, то можно всё под ней, наверное.
Отказ от ответственности: никогда не лицензировал контент, вышеописанное — теория, основанная на прочитанном мной.
В комплекте с пермиссивными лицензиями подойдёт CC-BY для контента. Если лицензия MIT, которая не говорит про сорцы, то можно всё под ней, наверное.
Отказ от ответственности: никогда не лицензировал контент, вышеописанное — теория, основанная на прочитанном мной.
Получается непонятка: допустим, проект под GPL с двоичными ресурсами (картинки в SVG вполне можно считать кодом). Если GPL не распространяется на эти ресурсы, а отдельной лицензии нет, выходит, что их вообще нельзя использовать.
Спасибо за ответ. У меня примерно схожие мысли насчет MIT. К сожалению, хотелось бы разобраться досконально.
1. GPL требует публиковать исходники именно под GPL, или в любом виде?
2. Если именно под GPL — что, если использовать код под GPL, а свой проект выпустить одновременно под GPL и, скажем, под MIT?
2. Если именно под GPL — что, если использовать код под GPL, а свой проект выпустить одновременно под GPL и, скажем, под MIT?
1. Да, GPL — т.н. «вирусная лицензия»
2. Perl, например
2. Perl, например
То есть, таким способом возможно «вывести» код из GPL?
Использование его в проекте, лицензированном одновременно под GPL и под MIT, сделает возможным взять уже из этого проекта код, но под MIT, и, соответственно, освободиться от требования использовать GPL?
Использование его в проекте, лицензированном одновременно под GPL и под MIT, сделает возможным взять уже из этого проекта код, но под MIT, и, соответственно, освободиться от требования использовать GPL?
То есть, таким способом возможно «вывести» код из GPL?Нет, конечно. Ваш код будут под обеими лицензиями, а тот который был под GPL под ним и останется, без согласия всех авторов перелицензирование не выполняется независимо от Вашего желания. Будет смесь лицензий и сложно понять, что можно копировать, а что нет (если менять оригинальные файлы).
Вот тут еще добрый человек с ЛОРа разместил Практическое руководство по соответствию GPL:
tim4dev.com/2014/11/compliance-gpl-1/
tim4dev.com/2014/11/compliance-gpl-2/
tim4dev.com/2014/11/compliance-gpl-3/
tim4dev.com/2014/11/compliance-gpl-1/
tim4dev.com/2014/11/compliance-gpl-2/
tim4dev.com/2014/11/compliance-gpl-3/
Спасибо, добавил ссылку в статью.
Еще есть вот это.
А у меня есть вопрос по авторскому праву. Как известно, у автора есть неимущественное право на защиту произведения, включая его название, от всякого искажения или иного посягательства, способного нанести ущерб чести и достоинству автора.
Как известно, программный код приравнивается к художественным произведениям (во всяком случае у нас, в Беларуси), а неимущественные права есть только у автора и не могут передаваться.
Вопрос такой: может ли разработчик, который написал программу/часть программы запретить изменять свой код? (под разным предлогом)
Как известно, программный код приравнивается к художественным произведениям (во всяком случае у нас, в Беларуси), а неимущественные права есть только у автора и не могут передаваться.
Вопрос такой: может ли разработчик, который написал программу/часть программы запретить изменять свой код? (под разным предлогом)
Лучше всего к юристу обратиться.
Но я немного погуглил. По Беларуси вот:
Пункт 6 статьи 17
6. Наниматель, обладающий исключительным правом на служебное произведение, имеет
право вносить в него изменения, сокращения и дополнения, вызванные необходимостью
адаптации произведения к конкретным условиям его использования, без получения на это
согласия автора служебного произведения, если иное не предусмотрено договором между
нанимателем и автором. При этом наниматель обязан указать в произведении об
осуществленной им адаптации.
А вот если нанимателя нет (например, разработка опенсурс проекта силами команды), то, может быть. Правда, как мне кажется, это должно подпадать под «соавторство» (ищите в тексте по той же ссылке).
А еще для Беларуси нагуглилось пособие Правовая охрана компьютерных программ и баз данных.
В России изменение программы приравнивается к использованию, а это исключительное право, которое можно передавать.
Статья 1270. Исключительное право на произведение
…
2. Использованием произведения независимо от того, совершаются ли соответствующие действия в целях извлечения прибыли или без такой цели, считается, в частности:
…
9) перевод или другая переработка произведения. При этом под переработкой произведения понимается создание производного произведения (обработки, экранизации, аранжировки, инсценировки и тому подобного). Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения, в том числе перевод такой программы или такой базы данных с одного языка на другой язык, за исключением адаптации, то есть внесения изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя;
Опенсурс силами команды — предполагаю, что тоже попадает подсоучастие соавторство.
Но я немного погуглил. По Беларуси вот:
Пункт 6 статьи 17
6. Наниматель, обладающий исключительным правом на служебное произведение, имеет
право вносить в него изменения, сокращения и дополнения, вызванные необходимостью
адаптации произведения к конкретным условиям его использования, без получения на это
согласия автора служебного произведения, если иное не предусмотрено договором между
нанимателем и автором. При этом наниматель обязан указать в произведении об
осуществленной им адаптации.
А вот если нанимателя нет (например, разработка опенсурс проекта силами команды), то, может быть. Правда, как мне кажется, это должно подпадать под «соавторство» (ищите в тексте по той же ссылке).
А еще для Беларуси нагуглилось пособие Правовая охрана компьютерных программ и баз данных.
В России изменение программы приравнивается к использованию, а это исключительное право, которое можно передавать.
Статья 1270. Исключительное право на произведение
…
2. Использованием произведения независимо от того, совершаются ли соответствующие действия в целях извлечения прибыли или без такой цели, считается, в частности:
…
9) перевод или другая переработка произведения. При этом под переработкой произведения понимается создание производного произведения (обработки, экранизации, аранжировки, инсценировки и тому подобного). Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения, в том числе перевод такой программы или такой базы данных с одного языка на другой язык, за исключением адаптации, то есть внесения изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя;
Опенсурс силами команды — предполагаю, что тоже попадает под
del
Тема не раскрыта. Весьма поверхностно. Как выбирать — непонятно.
Чего-чего требует?
В лицензии это не оговорено. Различия между динамической и статической линковкой — это фантазии FSF, которые не были обоснованы в суде. Есть альтернативные мнения, в том числе мнение Линуса.
Опять-таки, это левая рекомендация. В современном мире побеждают пермиссивные лицензии, которые ещё значительнее увеличивают популярность библиотеки.
Читать: «Если вас замучала паранойя при разработке веб-программ, ограда — здесь». AGPL практически не существует в окружающем мире, поэтому рекомендовать её хоть для чего-то — занятие странное. И уж тем более для веб-программ, где традиция основательно смещена в сторону пермиссивных лицензий.
Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить — ограничений нет.
Это верно для всех лицензий, а не только для одной.
И поэтому бесполезна чуть менее, чем полностью. Копилефтная лицензия должна быть одна (или совместимое семейство), иначе копилефтность создаёт слишком много проблем. Даже из-за несовместимости GPLv2 и GPLv3 куча проблем, вплоть до переписывания проектов.
Очень смешно звучит подобное ограничение в свете большого количества крупных проектов под MIT.
Темасисек не раскрыта. Вы так и не объяснили, в чём профит от пермиссивных лицензий.
Забыли про деление на 2-clause и 3-clause (есть не только старая 4-clause).
В тексте этой «лицензии» больше мусора про правила использования лицензии, чем слов по сути. Я использую модификацию без хлама.
Ещё Unlicense есть. Для прагматичных минималистов. CC0 тоже не все любят.
LGPL — это надстройка над GPL, и требует ее наличия в проекте.
Чего-чего требует?
Динамическая компоновка не требует открывать исходные коды. Со статической компоновкой сложнее, при ее использовании необходимо предоставлять вашу программу в объектной форме (исходные коды не обязательны), для того чтобы пользователь мог сам изменить библиотеку и перелинковать бинарник.
В лицензии это не оговорено. Различия между динамической и статической линковкой — это фантазии FSF, которые не были обоснованы в суде. Есть альтернативные мнения, в том числе мнение Линуса.
GNU рекомендует применять эту лицензию только в том случае, если применение вместо нее обычной GPL приведет к тому, что библиотеку перестанут использовать, заменив на аналогичную.
Опять-таки, это левая рекомендация. В современном мире побеждают пермиссивные лицензии, которые ещё значительнее увеличивают популярность библиотеки.
Мы рекомендуем разработчикам подумать о применении GNU AGPL для любых программ, которые обычно выполняются в сети.
Читать: «Если вас замучала паранойя при разработке веб-программ, ограда — здесь». AGPL практически не существует в окружающем мире, поэтому рекомендовать её хоть для чего-то — занятие странное. И уж тем более для веб-программ, где традиция основательно смещена в сторону пермиссивных лицензий.
Но если вы все же меняете код, то обязаны предоставить доступ к измененному вами коду под все той же MPL 2.0.
Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить — ограничений нет.
Также стоит добавить в проекта файл LICENSE с текстом лицензии.
Это верно для всех лицензий, а не только для одной.
По просьбе kidar2 добавляю лицензию EPL. Это копилефтная лицензия, но она не совместима с GNU GPL.
И поэтому бесполезна чуть менее, чем полностью. Копилефтная лицензия должна быть одна (или совместимое семейство), иначе копилефтность создаёт слишком много проблем. Даже из-за несовместимости GPLv2 и GPLv3 куча проблем, вплоть до переписывания проектов.
И вполне подходит для небольших проектов.
Очень смешно звучит подобное ограничение в свете большого количества крупных проектов под MIT.
когда вам необходима разрешительная лицензия
Тема
BSD
Забыли про деление на 2-clause и 3-clause (есть не только старая 4-clause).
WTFPL Version 2
В тексте этой «лицензии» больше мусора про правила использования лицензии, чем слов по сути. Я использую модификацию без хлама.
Вследствие подобных нюансов, появились лицензии подобные следующей.
Ещё Unlicense есть. Для прагматичных минималистов. CC0 тоже не все любят.
Тема не раскрыта. Весьма поверхностно. Как выбирать — непонятно.
Вы имеете полное право поставить статье минус. А за конструктивную часть критики — спасибо.
LGPL — это надстройка над GPL, и требует ее наличия в проекте.
Чего-чего требует?
Поправил, спасибо.
В лицензии это не оговорено. Различия между динамической и статической линковкой — это фантазии FSF, которые не были обоснованы в суде. Есть альтернативные мнения, в том числе мнение Линуса.
Поправил.
Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить — ограничений нет.
Добавил в описание.
Также стоит добавить в проекта файл LICENSE с текстом лицензии.
И мной это явно указано для всех лицензий, кроме тех, где я даю внешний линк на инстуркцию по их применению.
И вполне подходит для небольших проектов.
Очень смешно звучит подобное ограничение в свете большого количества крупных проектов под MIT.
Поправил.
Забыли про деление на 2-clause и 3-clause (есть не только старая 4-clause).
Добавил в статью упоминание 2-clause BSD.
Ещё Unlicense есть. Для прагматичных минималистов. CC0 тоже не все любят.
Добавил Unlicense, спасибо. Но, она таки проблемна.
По остальной части Вашего комментария. Я так понял, что Вы не любите копилефтные лицензии, и любите разрешительные. Это Ваше право. В статье я не ставил перед собой задачи пропагандировать те или иные лицензии. Каждый может выбрать сам, что ему больше подходит. Для этого я привел список наиболее известных лицензий (и добавил к ним озвученные в комментариях) и постарался кратко описать, какие требования они накладывают, как их применять и какие проблемы с ними существуют.
И, Ваш комментарий я не минусовал.
Было бы неплохо, если бы кто-нибудь еще расписал механику работы с контрибьюторами, про передачу прав, цифровое подписание соглашений и прочее, может отдельным топиком… :)
JFYI есть забавная лицензия JSON, которая признана несовместимой с GPL и считается «несвободной». Реально же она лишь запрещает использовать ПО в плохих целях:
(AFAIR у автора были проблемы с распространением модлей json для python по этому поводу.)
Относительно beerware, как заметил один мой коллега, существуют трудности реализацией «купить пива при встрече». Т.е. допустим один из вариантов проблемы, я сказал что куплю чуваку пива, а при случайной встрече не признал его =)
The Software shall be used for Good, not Evil.
(AFAIR у автора были проблемы с распространением модлей json для python по этому поводу.)
Относительно beerware, как заметил один мой коллега, существуют трудности реализацией «купить пива при встрече». Т.е. допустим один из вариантов проблемы, я сказал что куплю чуваку пива, а при случайной встрече не признал его =)
Относительно beerware, как заметил один мой коллега, существуют трудности реализацией «купить пива при встрече». Т.е. допустим один из вариантов проблемы, я сказал что куплю чуваку пива, а при случайной встрече не признал его =)
Кажется, это не относится к beerware. Так говорили в общем случае о подобных лицензиях и есть подозрение, что случаев было достаточно, так как мне встречалось обсуждение «при встрече» несколько раз в иных статьях о лицензиях. Тут по тексту «can», так что это опционально и ни к чему не должно обязывать.
Чтобы было понятно, чем плоха лицензия JSON, попробуйте дать определение Добру и Злу.
свободные — с целью предоставить возможность безвозмездно пользоваться плодами вашего труда
В случае копилефт лицензий это не совсем так. Основная задача таких лицензий не просто «предоставить возможность безвозмездно пользоваться», а именно поощрять вклад. Т.е. это не просто «пожертвование во благо общества», как CC0 или даже BSD/MIT, но об этом забывают/упускают/не упоминают.
Ещё boost и Zlib, тоже очень-очень разрешающие :)
Не до конца понятно, зачем вообще прилагать к коду текст лицензии. Какие могут быть последствия, если не указывать лицензию?
Очевидно, двоякая трактовка.
Для Вас, если Вы выложили код: с вероятностью близкой к единице — никаких. Для того, кто воспользуется Вашим кодом — самые любые. Иначе говоря, если Вы выложили некий код в публичный доступ без лицензии, то кто-либо другой не имеет прав им пользоваться, так как Вы ему эти права никаким образом не предоставили. А раз прав у него нет, то он нарушит закон, если использует этот код. За что и могут быть последствия. Поэтому, в общем случае, кодом без лицензии пользоваться не будут, исключая тех, кому закон это разрешает (fair use в США) или тех, кто не следует закону по разным причинам (преступники, спецслужбы, ну или там дети и другие люди, не знакомые с авторским правом и тп).
Кроме того, существует и двухпунктовая лицензия BSD, [...] и эта версия практически совпадает по функциональности с лицензией MIT. GNU советуют вместо лицензии BSD использовать MIT, чтобы исключить путаницу с тем, какая именно версия лицензии BSD используется.Мне всегда казалось странным, когда MIT фактически приравнивают к 2-clause BSD, и тем более такая позиция GNU/FSF. MIT разрешает sublicense (а не только redistribution and use) и не требует явно указывать авторские права в сорцах и бинарниках. В некотором приближении MIT можно считать 0-clause BSD с возможностью перелицензирования, но все-таки достаточно отличающейся от BSD лицензией.
Насчет sublicense сломано много копий и в англоязычной части интернета. После беглого гугления я нашел три варианта трактовки:
— да, можно перевыпускать чужой код под MIT и под другими лицензиями,
— да, как бы можно, но лицензия требует сохранять ее текст, а, следовательно, можно только добавлять дополнительные ограничения к ней, но никак не подменять ее полностью,
— нет, нельзя, это просто означает, что Вы имеете право передавать код далее под той же лицензией со всеми правами, полученными по ней.
Мне видится наиболее близким к действительности второй вариант. А это означает, что MIT не так уж сильно и отличается от BSD, ввиду чего их и считают практически идентичными даже юристы из GNU.
— да, можно перевыпускать чужой код под MIT и под другими лицензиями,
— да, как бы можно, но лицензия требует сохранять ее текст, а, следовательно, можно только добавлять дополнительные ограничения к ней, но никак не подменять ее полностью,
— нет, нельзя, это просто означает, что Вы имеете право передавать код далее под той же лицензией со всеми правами, полученными по ней.
Мне видится наиболее близким к действительности второй вариант. А это означает, что MIT не так уж сильно и отличается от BSD, ввиду чего их и считают практически идентичными даже юристы из GNU.
С юристами GNU, конечно, сложно спорить; у меня нет причин сомневаться их компетентности.
И тем не менее: описанная вами вторая трактовка кажется вполне корректной, но мне все-таки непонятно, как MIT защищает продукт (код) от перелицензирования под лицензией, которая с одной стороны 1) соблюдает условия MIT, т.е. указывает оригинальный copyright; 2) явно разрешает (или даже требует) дальнейшее использование оного без указания копирайта вообще (см. мой комментарий выше).
Единственное явное ограничение MIT — [t]he above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software — ничего не говорит о том, что их необходимо сохранять «по всей цепочке».
И тем не менее: описанная вами вторая трактовка кажется вполне корректной, но мне все-таки непонятно, как MIT защищает продукт (код) от перелицензирования под лицензией, которая с одной стороны 1) соблюдает условия MIT, т.е. указывает оригинальный copyright; 2) явно разрешает (или даже требует) дальнейшее использование оного без указания копирайта вообще (см. мой комментарий выше).
Единственное явное ограничение MIT — [t]he above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software — ничего не говорит о том, что их необходимо сохранять «по всей цепочке».
Ну вот, в цитате же и написано:
and this permission noticeТо есть, требуется копировать не только строчку с копирайтом, но и текст лицензии до waiver'а внизу (это где заглавными буквами про отказ от ответственности). А это значит, что тот же набор требований окажется и в следующих «звеньях цепочки», по Вашей терминологии.
Смотрите, я взял код MIT и пишу:
Copyright 2015 Original Copyright Holders (hey guys, thanks for MIT!)Или так не получится?
Permission is hereby granted, [...]
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
[ MY COOL LICENSE NAME ]
Permission is hereby granted to do whatever you want: I've relicensed it, it's allowed per the above note.
Скорее всего — нет. А так, как Вы написали — точно нет.
Во-первых, то, что там под тремя точками скрывается, оно должно быть явно текстом прописано, так, как этого требует лицензия.
Во-вторых, и это основное, как раз этот отсутствующий кусок и не дает Вам возможности написать to do whatever you want, так как в таком случае Вы пытаетесь дать кому-то больше прав, чем у Вас есть — в этой скрытой части текста они все перечислены, как и ограничения, при которых у Вас есть эти права.
В-третьих, не relicensed, а sublicensed. Если relicensed — то это как бы уже явно нарушение лицензии, так как такого права Вам не давали.
Ну и, в четвертых: значение глагола to sublicense трактуется по-разному даже англоязычными людьми. Тут нужно американских юристов спрашивать.
Во-первых, то, что там под тремя точками скрывается, оно должно быть явно текстом прописано, так, как этого требует лицензия.
Во-вторых, и это основное, как раз этот отсутствующий кусок и не дает Вам возможности написать to do whatever you want, так как в таком случае Вы пытаетесь дать кому-то больше прав, чем у Вас есть — в этой скрытой части текста они все перечислены, как и ограничения, при которых у Вас есть эти права.
В-третьих, не relicensed, а sublicensed. Если relicensed — то это как бы уже явно нарушение лицензии, так как такого права Вам не давали.
Ну и, в четвертых: значение глагола to sublicense трактуется по-разному даже англоязычными людьми. Тут нужно американских юристов спрашивать.
Кстати насчет sublicensed vs. relicensed верное замечание; возможно, в этом все и дело. (Троеточия, конечно же, использовались лишь с целью укоротить комментарий до сути.)
Извините, что ответил не в ту ветку. :-(
Извините, что ответил не в ту ветку. :-(
Сайт про выбор лицензии от GitHub:
https://choosealicense.com/
Software Licenses in Plain English:
https://tldrlegal.com/
Также неплохо было бы указать, под какими лицензиями я могу распространять ПО, скомпилированное различными компиляторами: GCC, MinGW, LLVM/Clang, Visual Studio и другими.
А ещё хотелось бы прочитать, какова практика изменения лицензий — как часто в России и в мире публикуют софт с договором (лицензией), похожим на одну из этих именованных «стандартных» лиценизий, но отличающимся в каких-либо деталях.
Например, ведь ничего не мешает ту Beerware написать от своего имени, и никаких проблем не иметь с запретом на авторство? Или текст лицензии тоже лицензирован, и просто так брать его и менять под себя запрещено лицензией на текст лицензии??
Например, ведь ничего не мешает ту Beerware написать от своего имени, и никаких проблем не иметь с запретом на авторство? Или текст лицензии тоже лицензирован, и просто так брать его и менять под себя запрещено лицензией на текст лицензии??
Можно было бы и на русский вариант применения ссылку дать ;-)
www.gnu.org/licenses/gpl-howto.ru.html
www.gnu.org/licenses/gpl-howto.ru.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лицензия для вашего open-source проекта