Дмитрий
1 августа 2015
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Много читал про лицензии ГПЛ, МИТ, БСД и так далее. Там много нюансов, но главное разделение по признаку «нужно ли открывать производные программы или нет». На линукс-форумах людей в основном беспокоит «полная незащищённость трудов программиста от копирования в закрытый проект» — это реальная цитата.

У меня другое видение. Допустим, написал я библиотеку и опубликовал её. Я разрешаю использовать её всем желающим в открытых и закрытых программах, коммерческих и нет. Это всё неважно, пусть люди пользуются. Но я хочу запретить форкать мой проект. Мне не нравится, что кто-то может скопировать мою работу целиком, изменить в нём несколько строк и опубликовать под другим именем, дробя рынок и внося путаницу в умы пользователей.

Как это сделать? Полностью запретить модификацию моего кода? Это не вариант, люди могут дорабатывать его под свои нужды и это нормально. Запретить публиковать измененный код? Тоже неприменимо на практике. Нет ничего плохого в том, что мой файл с модификациями будет лежать где-то на сервере. Выходит, надо запретить выпускать производные именно в виде отдельного аналогичного продукта. Но как?


Дмитрий!

По-моему, в вашем вопросе уже есть готовый ответ: так как вы — автор, вы праве разрешать и запрещать использовать библиотеку так, как считаете нужным. Если перевести ваши пожелания на юридический язык, получатся формулировки для лицензионного договора:

    • Лицензиар вправе:
    • заключать сублицензионные договоры с третьими лицами;
    • модифицировать и адаптировать библиотеку в любых целях;
    • использовать библиотеку на территории всего мира в течение всего срока действия исключительного права;
    • использовать библиотеку в коммерческих и некоммерческих целях, включая рекламные, информационные и иные цели.
    • Лицензиар не вправе:
    • использовать библиотеку для создания самостоятельных производных произведений;
    • удалять или менять информацию об авторе библиотеки и условиях её лицензирования.

Добавьте преамбулу и реквизиты, приправьте полезными подробностями и используйте на здоровье.

См. советы
P. S. Это был субботний юридический совет. Хотите узнать всё о правах, товарных знаках, договорах, офертах, заимствовании элементов интерфейса и фоток со стоков? Присылайте вопросы.

P. P. S. Я веду практический курс «Дизайн и право». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии

Станислав Биченко
1 августа 2015

Дмитрий, имейте в виду: никакая крупная фирма не станет использовать библиотеку с нестандартной лицензией.

Пример того, как нестандартная лицензия может обернуться большими проблемами: http://habrahabr.ru/post/198312/

Иван Гришаев
2 августа 2015

Дмитрий, зачем вам вообще открывать исходный код? Выкладывайте скомпилированные бинарники. Или представьте, что нашли в чужой библиотеке способ обработки массива в три раза быстрее вашего. Однако автор категорически запрещает использовать его код. В чём польза такого подхода?

Виктор Накоряков
4 августа 2015

GPL, MIT, BSD — все имеют пункт, по которому отметка о копирайте обязательно должна быть сохранена в производной работе. Поэтому просто форкнуть, изменить 2 строки и переписать ваш © на свой не получится, это будет нарушением условий лицензии.

Разница в лицензиях заключается в том, как может распространяться продукт, который использует лицензируемый компонент.

Грубо, GPL — это вирусная лицензия, весь продукт, к которому *прилинкован* (статически или динамически, но не средствами RPC) компонент обязан быть GPL. Распространять его бинарную версию без исходников нельзя.

MIT/BSD — более свободные, но не совместимые с GPL. Бинарную версию можно распространять без исходников. А если публикуются изменённые исходники, они должны сохранить лицензию и, как раз, ваш copyright notice. BSD отличается от MIT тем, что пользователи не могут использовать ваше имя или имя вашей компании для продвижения своего продукта.

Роман Буянов
7 августа 2015

Запрет форкинга вреден: слишком часто авторы переоценивают свои силы и энтузиазм, и в результате софт через пару лет остается без развития. Вместо полного запрета можно включить в лицензию пункты, позволяющие создание форков через определенное время после прекращения релизов от автора.

Роман Буянов
10 августа 2015

Между прочим, многие лицензии (MIT, BSD) требуют сохранять текст об исходном авторе, а некоторые (Apache, Zlib) запрещают убирать инфу об изначальном произведении и требуют отмечать, если сделаны изменения. Возможно, этого будет достаточно без жёсткого запрета форков.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Распространяются ли авторские права на текст договора? Зачем нужны юристы? Зачем ИП нужен расчётный счёт? Посоветуйте формулировки для оферты об услугах на сайте?




Недавно всплыло

Как создавался новый сайт бюро. Часть третья 1 Начальник считает, что перед встречей нужно обязательно разработать несколько вариантов предложений 6 2 1