Есть у меня pet-проект, исходники которого я хочу опубликовать на github.
Встал вопрос с выбором лицензии.
Начал читать про то какие существуют лицензии, но описание по-русски слишком краткое, по-английски — слишком лойерское.
Может тут кто подскажет какая лицензия мне подойдет? Или где нормальное объяснение почитать?
Чего бы мне хотелось:
1. Разрешить некоммерческое использование исходников.
2. Если кто хочет коммерческого использования, то можем договориться.
Такая комбинация вообще бывает?
ПС: в проекте есть зависимость от стороннего компонента под Apache 2.0
Здравствуйте, Muxa, Вы писали:
M>1. Разрешить некоммерческое использование исходников. M>2. Если кто хочет коммерческого использования, то можем договориться. M>Такая комбинация вообще бывает?
Опенсорсная лицензия, по определению, не может запрещать коммерческое использование. Но она может требовать раздавать исходники, в т.ч. исходники, производные от твоих.
А так, можно, к напримеру, сделать dual license. Скажем GPL или платную, без требований GPL. Имей ввиду, если ты будешь принимать к своему проекту патчи, то авторские права на патчи принадлежат их авторам. Но ты можешь явно оговорить, что граждане, присылающие патчи, тем самым безвозмездно передают тебе свои права на них и количество патчей сразу поуменьшится
M>ПС: в проекте есть зависимость от стороннего компонента под Apache 2.0
Apache 2.0, мне кажется, не налагает особых требований, кроме как сохранять ее упоминание в исходниках и всякое такое.
Pzz>Опенсорсная лицензия, по определению, не может запрещать коммерческое использование. Но она может требовать раздавать исходники, в т.ч. исходники, производные от твоих.
Запрещать полностью не хочу. Хочу чтобы без моего согласия мой проект не использовался коммерчески.
Pzz>А так, можно, к напримеру, сделать dual license.
Когда в проекте две лицензии, то на что каждая из них распространяется?
На исходники/бинарники или на некоммерческое/коммерческое использование?
Здравствуйте, Muxa, Вы писали:
Pzz>>Опенсорсная лицензия, по определению, не может запрещать коммерческое использование. Но она может требовать раздавать исходники, в т.ч. исходники, производные от твоих. M>Запрещать полностью не хочу. Хочу чтобы без моего согласия мой проект не использовался коммерчески.
По определению, опенсорсная лицензия не может давать разные права при коммерческом и не-коммерческом использовании. Но требование раздавать исходники может оказаться неприемлимым при коммерческом использовании. Но может и не оказаться.
Pzz>>А так, можно, к напримеру, сделать dual license. M>Когда в проекте две лицензии, то на что каждая из них распространяется? M>На исходники/бинарники или на некоммерческое/коммерческое использование?
По выбору пользователя. Либо пользователь выбирает GPL, со всеми ее правами и ограничениями, либо не GPL, а какую-то другую, возможно, платную лицензию.
Лицензия — это договор между правообладателем и пользователем о том, на каких условиях пользователь может пользоваться объектом авторских прав. Ничего не мешает с разными пользователями заключать разные договора на одни и те же исходники.
Здравствуйте, Muxa, Вы писали:
M>Есть у меня pet-проект, исходники которого я хочу опубликовать на github. M>Встал вопрос с выбором лицензии. M>Начал читать про то какие существуют лицензии, но описание по-русски слишком краткое, по-английски — слишком лойерское.
Pzz>Опенсорсная лицензия, по определению, не может запрещать коммерческое использование.
"Опенсорсная лицензия" — это не более чем открытый исходный код. Т.е. код, доступный для чтения (например, в целях проверки кода на отсутствие бэкдоров).
Дальше возможны вариации, касающиеся прав на пользование, изменение и распространение кода.
Здравствуйте, L.K., Вы писали:
Pzz>>Опенсорсная лицензия, по определению, не может запрещать коммерческое использование.
LK>"Опенсорсная лицензия" — это не более чем открытый исходный код. Т.е. код, доступный для чтения (например, в целях проверки кода на отсутствие бэкдоров).
Нет. OSI сформулировала требования, каким должна соответствовать лицензия, чтобы считаться опенсорсной. Одно из требований — отсутствие дискриминации пользователей по принципу коммерческие/некоммерческие.
Существуют и другие лицензии, открывающие исходный код, но не являющиеся опенсорсными. Например, когда Microsoft открывает код C RTL, разрешая изучение, но не разрешая распостранение самосборных бинарных имеджей, такая лицензия не является опенсорсной, хотя код при этом вполе опубликован.
Здравствуйте, Muxa, Вы писали:
M>Чего бы мне хотелось: M>1. Разрешить некоммерческое использование исходников. M>2. Если кто хочет коммерческого использования, то можем договориться.
А в чем проблема? Так и пиши: вот вам (L)GPL, а если не нравится — пишите, договорися. Если ты автор, то можешь выпускать под любой лицензией
Как пример смотри Qt: у них LGPL и коммерческая.
Здравствуйте, Skorodum, Вы писали:
S>А в чем проблема? Так и пиши: вот вам (L)GPL, а если не нравится — пишите, договорися. Если ты автор, то можешь выпускать под любой лицензией S>Как пример смотри Qt: у них LGPL и коммерческая.
LGPL позволяет линковаться динамически без последствий в виде раскрытия своих исходников. Поскольку при наличии возможности линковаться динамически, статически никто в своем уме линкиваться и не захочет, LGPL не налагает практически значимых ограничений.
Здравствуйте, уважаемый Pzz, Вы писали:
... Pzz>Поскольку при наличии возможности линковаться динамически, статически никто в своем уме линкиваться и не захочет...
Вопрос не такой уж и однозначный.
Приемущества при статической линковке:
1) Дистрибуция проще — всё в одном исполнимом файле легче распространять.
2) Зависимостей от сторонних компонентов меньше (всё своё — при себе).
3) Быстрота запуска приложения.
P.S. Главное приемущество динамической линковки — более экономичное использование ресурсов (памяти), на сегодняшний день, за счет програсса технологий, фактически утратило прежнюю актуальность.
Здравствуйте, AlexGin, Вы писали:
AG>Приемущества при статической линковке: AG>1) Дистрибуция проще — всё в одном исполнимом файле легче распространять. AG>2) Зависимостей от сторонних компонентов меньше (всё своё — при себе). AG>3) Быстрота запуска приложения.
Угу. Только все равно найдется десяток внешних зависимостей, которых статически не прилинкуешь, как не старайся. А если так, то какая разница, одной библиотекой больше или меньше?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, AlexGin, Вы писали:
AG>>Приемущества при статической линковке: AG>>1) Дистрибуция проще — всё в одном исполнимом файле легче распространять. AG>>2) Зависимостей от сторонних компонентов меньше (всё своё — при себе). AG>>3) Быстрота запуска приложения.
Pzz>Угу. Только все равно найдется десяток внешних зависимостей, которых статически не прилинкуешь, как не старайся. А если так, то какая разница, одной библиотекой больше или меньше?
Ну здесь бы логично было разделить зависимости на два типа:
-системные — от которых в действительности не уйти (но считаем, что поставка OC их закрывает);
-прикладные — собственно говоря, это все библиотеки связанные с расчетной частью (бизнес-логикой), сетью и GUI нашего приложения.
Здравствуйте, AlexGin, Вы писали:
AG>Ну здесь бы логично было разделить зависимости на два типа: AG>-системные — от которых в действительности не уйти (но считаем, что поставка OC их закрывает); AG>-прикладные — собственно говоря, это все библиотеки связанные с расчетной частью (бизнес-логикой), сетью и GUI нашего приложения.
Угу. Только какую-нибудь Qt очень муторно, если вообще возможно, прилинковать статически. И потянет она за собой целый лес, всякие там zlib'ы, sqlite и проч.
