Как написать договор на разработку open source?

Для тех, кто может включиться, есть contributors' guidelines, и это другая история

А вот для того, кто на зарплате, если он коммитит по-нормальному, то исключительные права в этот же момент и испаряются, а чтоб сразу не испарялись, надо технически заморачиваться и коммитить как-то по-неудобному

OCTAGRAM, каким образом права испаряются при коммите? open source означает, что кто угодно может смотреть исходники. А права на код - это отдельная тема (лицензия). В случае работы на дядю в рамках проекта или рабочего времени (да еще и на оборудовании дяди) весь труд принадлежит дяде. А кто там может видеть его или не может, это не важно.

OCTAGRAM, Никуда и ничего не испаряется.
У вас есть работник, работник пишет код, комитит код в репозиторий.
Где этот репозиторий и под какими правами всем пофигу, это вы уже определяете сами.
Хотите вообще завернуть это всё, ставите внутренний GIT сервер, ну тот-же гитлаб, а на публику уже в тот-же гитхаб делаете зеркало репы.

Есть разраб, есть трудовой договор, всё что напишет разраб в рабочее время, принадлежит компании которая оплатила это время.
Всё что контрибьюторы напишут вам не принадлежит, если нужны исключительные права на код то о контрибьюторах в принципе речи нет.

dollar, Вот и я о том-же :)
Но только брать контрибьюторов нельзя, иначе слегка всё сложно становится.

ТыжСисАдмин, да, это тема отдельного вопроса. "Что если я случайно закоммитил свой код в проприетарный проект? Теперь я имею право на 50% прибыли с него как соавтор?"))

dollar, вот именно, что нет. Исключительные права на интеллектуальную собственность, производимую человеком, принадлежат только ему. Юридически ничтожно пытаться присвоить права только потому что на оборудовании дяди или в рабочее время. А есть примеры, когда обиженный сисадмин оспаривал некорректный договор, и суд признавал за ним исключительные права.

Поэтому в договорах и прописывается передача исключительных прав как предмет договора.

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

Городить несколько хранилищ вот как раз сильно не хотелось бы. Хотелось бы, чтоб в трекере можно было при обсуждении ссылаться на ревизии, и ревизии только в одном хранилище существовали, без умножения сущностей.

OCTAGRAM, это вопрос не опенсорса а разработки софта вообще.
Как в договоре напишете так и будет, ну конечно если вы человека не оформите как дворника а писать он будет код :)
Короч опенсор тут вообще не при делах.
В общем сделаю так, вот есть такой замечательный товарищ как Дмитрий, является автором GitLab. Можете с ним поговорить на эту тему, не знаю тут есть он или нет но в твитторе @dzaporozhets

OCTAGRAM, окей, давайте простую ситуацию разберем. Есть open source репозиторий, в корне которого указана MIT лицензия. Некто неизвестный делает pull request. Его принимают. Что дальше?

Формально можно сказать, что содержимое PR принадлежит его автору. Но он состоит из множества мелких правок. Т.е. это не произведение. Это для начала.

Далее он формально меняет существующее произведение, и получается измененное произведение. То есть он взял старое произведение, переработал, и получил новое (новую версию). Значит ли это, что он одним лишь PR по сути присвоил себе права на новую версию всего продукта? Звучит как бред, если честно.

Ладно, думаю если вклад мал, то любой суд не станет принимать его во внимание. Предположим, что этот некто очень круто переработал весь проект и существенно улучшил его. Допустим, с этого момента его можно считать соавтором с исключительными правами. Но лицензия-то осталась та же! То есть он по сути согласен с нею. И весь его труд, не смотря на авторство, вы сможете использовать в любых целях.

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

Так и в чем проблема в итоге?

dollar, нет, для принятия pull request в норме нужно соблюдение contributors' guidelines, а там в том числе условия лицензирования своих правок. С контрибьюторов спрашивают согласие с этими условиями перед включением.

Интеллектуальная собственность на правки имеет место быть. Бывали случаи, когда приходилось всех разработчиков разрозненных поднимать, чтоб лицензию поменять, а код не согласных или потерявшихся исключали или переписывали. То есть, у каждого разработчика остаются исключительные права, на основании которых он может лицензировать всё те же правки на новых условиях.

кодом может пользоваться только ваша компания

Я уже писал, что семантически у нас научный фонд, и это бессмысленно. Вообще лицензия по плану Apache 2.0. Может быть, двойное лицензирование для стратегически важных, но не совместимых с ней лицензий сразу стоит предусмотреть. Это наоборот, чуть менее, чем нараспашку, ну как и положено научному фонду, если он не военный там или ещё что-то с ним не так. Нам бы пооперативней и попрозрачней свою деятельность вести. Закоммитил — показал. Медийно это сразу освещать, реклама ВК дешёвая, если узко таргетировать. Имена себе делать.

В договоре с сотрудником надо как-то правильно получение неисключительных прав прописать, с исключительными бессмысленная морока.

Так в чем проблема-то?

Пишите contributors' guidelines для своего репозитория. Пусть там значится передача эксклюзивных или не очень прав во время PR.

Если хотите менять лицензию в любое время без согласия всех соавторов, пропишите этот пункт в самой лицензии - что ваша организация может ее менять без согласия остальных. Чем в этом случае мешают исключительные или не исключительные права, если они всё же есть?

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

А в бумажном договоре с сотрудником - всё то же самое, что и в вышеперечисленных местах. Просто для галочки. Лишняя бумажка в суде, если что. И никакой коммит ничего не испортит.

Так в чем проблема-то?

Пишите contributors' guidelines для своего репозитория. Пусть там значится передача эксклюзивных или не очень прав во время PR.

С теми, кому не платить по договору, проблем нет. Тем, кому платить по договору, в договор прописать как-то надо, чтоб они и я не заблокированы волокитой были.

Кстати, речь про гитхаб или про что вообще?

OSDN с зеркалом на GitHub в режиме только чтение. Может быть, каким-то проектам удастся пробиться на OW2

Если хотите менять лицензию в любое время без согласия всех соавторов

Не хочу. Как в начале лицензия стоит, так и должна остаться. Я бы вообще в общественное состояние всё отправлял, если не патентное законодательство и патентные тролли. Это из-за них Фонд СПО так настоятельно рекоммендует предпочесть Apache 2.0 передаче в общественное достояние. Apache 2.0 уже и так можно (но нужно ли?) поменять на что-то другое в достаточно широких пределах, ведь согласие авторов случается просто при публикации под такой лицензией.