Комментарии 56
Наглядно, понятно.
Спасибо)
Спасибо)
Наглядно, понятно, только почти везде — некорректно. Всякие Public domain и CC0 — это не «все пофиг», а на самом деле весьма умная и дальновидная лицензия. Там вполне четко обычно прописывают, что «распространяется AS IS» и «никаких претензий к автору, даже если это ПО сделает сильно плохо».
Различие GPL2 и GPL3 — гораздо больше, чем кажется на первый взгляд и даже на второй взгляд. Это и последствия FAT-конфликта, и защита от тивоизиации, и запрет DRM, и вполне опробованные судами уточнения массы формулировок терминов, которые сильно упрощают работу адвокатов.
Совершенно упущено из вида, что всякие *GPL — это почти всегда для кода на C- и C-подобных языках. Для скриптовых языков, для VM-based языков и т.д. есть свои лицензии, которые зачастую лучше и гораздо более явно описывают ситуацию, чем лицензии, приспособленные к терминам C.
И т.д. и т.п. К сожалению, вопрос с лицензиями объективно сложный и его нельзя взять и просто так свести к 5-6 вопросам на чарте-картинке.
Различие GPL2 и GPL3 — гораздо больше, чем кажется на первый взгляд и даже на второй взгляд. Это и последствия FAT-конфликта, и защита от тивоизиации, и запрет DRM, и вполне опробованные судами уточнения массы формулировок терминов, которые сильно упрощают работу адвокатов.
Совершенно упущено из вида, что всякие *GPL — это почти всегда для кода на C- и C-подобных языках. Для скриптовых языков, для VM-based языков и т.д. есть свои лицензии, которые зачастую лучше и гораздо более явно описывают ситуацию, чем лицензии, приспособленные к терминам C.
И т.д. и т.п. К сожалению, вопрос с лицензиями объективно сложный и его нельзя взять и просто так свести к 5-6 вопросам на чарте-картинке.
А чем wtfpl отличается от MIT?
Я так понимаю, что если лицензия MIT, то делай что хочешь.
Я так понимаю, что если лицензия MIT, то делай что хочешь.
Тема BSD не раскрыта:
4-clause license (original «BSD License»)
3-clause license («New BSD License» or «Modified BSD License»)
2-clause license («Simplified BSD License» or «FreeBSD License»)
4-clause license (original «BSD License»)
3-clause license («New BSD License» or «Modified BSD License»)
2-clause license («Simplified BSD License» or «FreeBSD License»)
А под какой лицензией данная картинка? ;)
Интересна была бы подобная диаграмма «взаимодействия» их друг с другом, а ля можно ли распространять LGPL библиотеку со своим кодом на MIT ну и тд
Ответы «Нет» и «Пофиг» на первый вопрос логически эквивалентны.
НЛО прилетело и опубликовало эту надпись здесь
Нунаконецта!
а то какие-то не понятные apache & BSD licence.
Уже в избранном ;)
а то какие-то не понятные apache & BSD licence.
Уже в избранном ;)
Ещё есть отличный сайт по лицензиям на русском: licenseit.ru
НЛО прилетело и опубликовало эту надпись здесь
мне эта нравится
www.gzip.org/zlib/zlib_license.html
www.gzip.org/zlib/zlib_license.html
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Нужно быть идиотом, чтобы в наше время выпускать продукт под лицензией GPL
Если не важно кто и как возьмет код вашей программы, закроет и использует в своей программе, а потом продаст, то конечно. Но если вы думаете о том, что создаете, то только GNU GPL 3
www.defectivebydesign.org/
www.defectivebydesign.org/
Именно поэтому, эту лицензию вряд ли можно считать opensource. На самом деле лишь ограничивает свободу программистов. 20 лет назад, когда создавалась эта лицензия, люди думали исходный код --> плагиат. Теперь это бессмысленно, т.к. сейчас другие представления об opensource.
Считать лицензию opensource? Это как? Если только текст лицензии, он открыт.
GNU GPLv3 была создана в 2007, никак не 20 лет назад. Она отлично защищает программистов и их труд, а так же дает гарантии, что ваш код всегда будет открыт, а не утонет в каком-нибудь корпоративном продукте и будет прозябать там в закрытом виде.
GNU GPLv3 дает защиту для пользователей. Например вы используете программу, которую уже никто не разрабатывает много лет, вы всегда можете запросить исходный код у разработчика и доработать программу для новых систем. В большинстве случаев, программы под этой лицензией выкладывают на хостинги проектов, типа sourceforge.net, где она хранится долгое время, и вам нет нужды обращаться конкретно к разработчику, хотя такое бывает не всегда.
В чем-то есть ограничение, конкретно в линковке только с GNU GPL совместимыми лицензиями, но это так-же дает защиту, что вся программа будет работать и в дальнейшем, и её можно будет модифицировать под свои нужды. Если так необходимо линковать продукт с несовместимыми лицензиями — есть LGPL.
GNU GPLv3 была создана в 2007, никак не 20 лет назад. Она отлично защищает программистов и их труд, а так же дает гарантии, что ваш код всегда будет открыт, а не утонет в каком-нибудь корпоративном продукте и будет прозябать там в закрытом виде.
GNU GPLv3 дает защиту для пользователей. Например вы используете программу, которую уже никто не разрабатывает много лет, вы всегда можете запросить исходный код у разработчика и доработать программу для новых систем. В большинстве случаев, программы под этой лицензией выкладывают на хостинги проектов, типа sourceforge.net, где она хранится долгое время, и вам нет нужды обращаться конкретно к разработчику, хотя такое бывает не всегда.
В чем-то есть ограничение, конкретно в линковке только с GNU GPL совместимыми лицензиями, но это так-же дает защиту, что вся программа будет работать и в дальнейшем, и её можно будет модифицировать под свои нужды. Если так необходимо линковать продукт с несовместимыми лицензиями — есть LGPL.
Она отлично защищает программистов и их труд, а так же дает гарантии, что ваш код всегда будет открыт, а не утонет в каком-нибудь корпоративном продукте и будет прозябать там в закрытом виде.Защищает от чего?
Если человек сделал хороший софт, не все ли ему равно на подобные случаи?
В данном случае главное, чтобы продуктом могло воспользоваться как можно больше людей. При ГПЛ таких людей будет меньше. Поэтому я согласен с точкой зрения NARKOZ и в своих open source продуктах использую только MIT. Apache тоже очень хороша, но необходимость ставить информацию о лицензии в каждый файл просто убивает.
Защищает от того, что кто-то может сделать продукт, на основе вашего кода, закрыть его и продать как свой. И в случае BSD-like лицензии будет иметь на это полное право.
Как написали в одном месте «BSD это свобода для разработчика, GPL это свобода для пользователя».
В каком случае главное, чтобы программой могли воспользоваться как можно больше людей? Если вы преследуете такие цели то вам дорога в android market или app store, цела туча хомячков загрузят вашу программу.
И странно другое, если программа будет под лицензией GNU GPL, то в каком случае человек не сможет её использовать, в отличие от MIT?
Можете поинтересоваться почему Microsoft вкладывает деньги в Apache Foundation и поощряет использование именно лицензии Apache.
Выбирая GNU GPL вы уверены, что все библиотеки и наработки, созданные под этой лицензией, будут вам доступны и не придется заново изобретать велосипед, когда кто-то уже написал для этого библиотеку.
По поводу того, что надо в каждый файл исходного кода — для этого есть автоматизация текстовых редакторов (не знаю какой конкретно вы используете), не вижу в этом ничего сложного.
Как написали в одном месте «BSD это свобода для разработчика, GPL это свобода для пользователя».
В каком случае главное, чтобы программой могли воспользоваться как можно больше людей? Если вы преследуете такие цели то вам дорога в android market или app store, цела туча хомячков загрузят вашу программу.
И странно другое, если программа будет под лицензией GNU GPL, то в каком случае человек не сможет её использовать, в отличие от MIT?
Можете поинтересоваться почему Microsoft вкладывает деньги в Apache Foundation и поощряет использование именно лицензии Apache.
Выбирая GNU GPL вы уверены, что все библиотеки и наработки, созданные под этой лицензией, будут вам доступны и не придется заново изобретать велосипед, когда кто-то уже написал для этого библиотеку.
По поводу того, что надо в каждый файл исходного кода — для этого есть автоматизация текстовых редакторов (не знаю какой конкретно вы используете), не вижу в этом ничего сложного.
Защищает от того, что кто-то может сделать продукт, на основе вашего кода, закрыть его и продать как свой. И в случае BSD-like лицензии будет иметь на это полное право.Я не вижу в этом ничего плохого. Копирайты то они не затирают. Если какие-то компании используют мой исходный код, это ли не показатель хорошего продукта или библиотеки?
Тот же John Reisig после создания jQuery стал очень известным разработчиком.
То же самое с Игорем Сысоевым и nginx.
Там где копирайты затирают, вы уже не узнаете.
Тут другое, в случае с GNU GPL они будут обязаны выложить свои наработки в открытый доступ или предоставить по первому требованию. Т.е. если они что-то доработали в вашем продукте, то это вернется к вам и вы сможете использовать эти наработки у себя, чтобы улучшить свой продукт.
Если кто-то использует ваш код в своих закрытых продуктах и наживается на этом, ничего не принося сообществу в целом — это нехорошо. Про качество тут речи не идет. Они просто хотят сэкономить, используя чужой труд, при этом ничего не отдавая в замен.
Почему те или иные проекты выбрали для себя BSD-like лицензию может быть много причин, и иногда это не зависит от самих разработчиков(например компания не позволяет сотрудникам выпускать программу под GNU GPL лицензией). Каким образом выбор той или иной лицензии поможет распространению вашего продукта(кроме случаев корпоративного внедрения, где строго оговорен список допустимых лицензий, и это скорее всего продиктовано спонсором)?
Тут другое, в случае с GNU GPL они будут обязаны выложить свои наработки в открытый доступ или предоставить по первому требованию. Т.е. если они что-то доработали в вашем продукте, то это вернется к вам и вы сможете использовать эти наработки у себя, чтобы улучшить свой продукт.
Если кто-то использует ваш код в своих закрытых продуктах и наживается на этом, ничего не принося сообществу в целом — это нехорошо. Про качество тут речи не идет. Они просто хотят сэкономить, используя чужой труд, при этом ничего не отдавая в замен.
Почему те или иные проекты выбрали для себя BSD-like лицензию может быть много причин, и иногда это не зависит от самих разработчиков(например компания не позволяет сотрудникам выпускать программу под GNU GPL лицензией). Каким образом выбор той или иной лицензии поможет распространению вашего продукта(кроме случаев корпоративного внедрения, где строго оговорен список допустимых лицензий, и это скорее всего продиктовано спонсором)?
Посмотрите на Apache или Eclipse. На их основе их продуктов создаются продукты как открытые, так и закрытые. И многие компании вносят свой вклад, т.к. это намного выгодней. Конечно, не каждая компания будет делать вклад, но если продукт окажется действительно полезным, то вклад будет достаточно огромным.
Мое мнение: создаете продукт с открытым кодом, то делайте его открытым без ограничений. Это спасет время программистов, которые хотят просто создать продукт, а не разбираться с лицензиями. А рядовому пользователю всё равно какая лицензия, будь то New BSD или GPL.
Мое мнение: создаете продукт с открытым кодом, то делайте его открытым без ограничений. Это спасет время программистов, которые хотят просто создать продукт, а не разбираться с лицензиями. А рядовому пользователю всё равно какая лицензия, будь то New BSD или GPL.
Но если программисту не наплевать на то, что будет с его кодом дальше, то он скорее выберет GNU GPL, чем BSD-like лицензию.
С каких пор, лицензия отличная от GPL говорит о плевательском отношении к своему коду в дальнейшем? Всегда считал, что программисту наплевать на свой код, если у него нет хорошей документации или хотя бы нормального readme, но никак не присутствие отличной от GPL лицензии.
Почитайте http://programmers.stackexchange.com/q/7720/4935
Ясно видно, что минусов, больше чем плюсов.
Почитайте http://programmers.stackexchange.com/q/7720/4935
Ясно видно, что минусов, больше чем плюсов.
Я уже писал почему, смотрите вышел.
Наличие или отсутствие документации совсем не показатель, тем более для других программистов, которые хотят использовать код у себя.
По ссылке видно, что человек указал только один минус, который я уже описал выше — это запрет на использование GNU GPL программ в некоторых корпорациях. Для линковки с кодом под несовместимыми лицензиями есть GNU LGPL.
Наличие или отсутствие документации совсем не показатель, тем более для других программистов, которые хотят использовать код у себя.
По ссылке видно, что человек указал только один минус, который я уже описал выше — это запрет на использование GNU GPL программ в некоторых корпорациях. Для линковки с кодом под несовместимыми лицензиями есть GNU LGPL.
Кстати, sourceforge и svn тоже устарели. Не так сильно, но всё же.
Устарели для чего? Ими можно пользоваться и они работают, не вижу проблемы в этом.
НЛО прилетело и опубликовало эту надпись здесь
Это мода.
Тут скорее идет противостояние svn с git. Сначала с трудом переходили на svn, пока разбирались что там к чему, потом вот появились git и hg, на них тоже переходить уже нет большого желания у некоторых разработчиков.
А самому разработчику главное чтобы был хостинг для кода, и какая там уже внутри система контроля версий уже дело десятое(IMHO).
Тут скорее идет противостояние svn с git. Сначала с трудом переходили на svn, пока разбирались что там к чему, потом вот появились git и hg, на них тоже переходить уже нет большого желания у некоторых разработчиков.
А самому разработчику главное чтобы был хостинг для кода, и какая там уже внутри система контроля версий уже дело десятое(IMHO).
Это не мода, это ИТ. Если не можете идти в ногу с ним, то вам здесь не место.
Вы уже можете отвечать за всю индустрию, не много ли на себя берёте?
И — нет, это как раз мода. Неужели программа, которая находится под svn станет лучше работать, если перевести её на git? Зато если переводить, то придется менять инфраструктуру разработки, переучивать разработчиков, перенастраивать средства разработки. Есть плюсы в более простом слиянии бранчей и децентрализации разработки, но они меркнут перед мерами, которые необходимо предпринять для перехода.
Каждый разработчик может сделать у себя реп git наравне с уже существующим репом svn, но именно переход бывает менее чем оправданным.
Новые проекты можно начать делать на git или mercurial, они уже достаточно взрослые для повседневного использования, но для старых проектов в этом особой нужды нет.
И — нет, это как раз мода. Неужели программа, которая находится под svn станет лучше работать, если перевести её на git? Зато если переводить, то придется менять инфраструктуру разработки, переучивать разработчиков, перенастраивать средства разработки. Есть плюсы в более простом слиянии бранчей и децентрализации разработки, но они меркнут перед мерами, которые необходимо предпринять для перехода.
Каждый разработчик может сделать у себя реп git наравне с уже существующим репом svn, но именно переход бывает менее чем оправданным.
Новые проекты можно начать делать на git или mercurial, они уже достаточно взрослые для повседневного использования, но для старых проектов в этом особой нужды нет.
Спасибо за ссылку. Узнал про ISC лицензию.
Как раз недавно задал в разделе вопросов свой: «Доработка кода под лицензией MS-Pl и дальнейшее распространение под своим брендом. Корректно ли это?». Возможно кто то из присутствующих сможет помочь и посоветовать как лучше сделать?
Может лучше первое предложение сделать заголовком?
Думаю из ромбиков стоит убрать частицы «не», сделав их положительными по смыслу. Иначе когда хочешь пройти по стрелке «нет» получаешь двойное отрицание.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наглядно о популярных Open Source лицензиях