Открытые исходные IP-контракты для фрилансеров

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

Вопрос заключается в следующем: как я могу написать свой контракт для учета следующих ситуаций:

1. В ходе работы над проектом клиента я хочу открыть часть кода для сообщества под своим именем.
2. В ходе работы над проектом клиента я использую некоторые из моих существующих проектов с открытым исходным кодом и улучшаю их.
3. В ходе работы над проектами клиента я делаю улучшения в сторонних проектах с открытым исходным кодом и добавляю их обратно.
4. В ходе работы над проектом клиента мы решили открыть исходную часть кода под именем клиента.

Какие прецеденты этому, если таковые имеются?

Обновление: я добавил элемент в список выше (элемент № 3).

Кроме того, IANAL - поэтому я бы рекомендовал проконсультироваться с адвокатом, который конкретно разбирается или специализируется на вопросах интеллектуальной собственности программного обеспечения .

Но я думаю, что ответ довольно прост: 1. Я не думаю, что есть необходимость обсуждать термин «открытый исходный код» с клиентом (прочитайте, прежде чем составить мнение по этому утверждению) 2. В вашем контракте вы Необходимо четко указать следующее: Любая работа, которую вы создаете для клиента, СОВМЕСТНАЯ СОБСТВЕННАЯ, и каждая может создавать производные рабочие продукты. Это означает, что каждый из вас может использовать его по своему усмотрению, включая участие в проекте с открытым исходным кодом (конечно, ознакомьтесь с требованиями IP проекта с открытым исходным кодом). б. Вы сохраняете право собственности на любой ранее существовавший рабочий продукт, который вы достаточно любезны, чтобы включить его бесплатно, и вы предоставляете клиенту неограниченную лицензию на бессрочное использование этого кода, включая создание производных работ c.

Вы также захотите, ЧТОБЫ УВЕРЕНЫ, что вы никогда не будете подписывать какие-либо контракты с оговоркой об уступке изобретений, которая не является чрезвычайно ограниченной (они никогда не бывают), иначе вы можете быть юридически СОЛНЫМ. Обратите внимание, что есть несколько штатов (например, Калифорния), которые ограничивают (но не устраняют) это по закону независимо от того, что говорится в контракте. Это ожидается в трудовом договоре (но об ограничениях можно договориться), но IMHO не следует предоставлять для контракта с независимым подрядчиком.

Вашей самой большой проблемой будет заставить их принять совместное владение исходным кодом. Это противоречит доктрине «Работа по найму», которая является специфическим языком, который очень часто используется в контрактах на разработку программного обеспечения при использовании подрядчиков.

Если они понимают IP, они могут не согласиться с этим - но я предполагаю, что это не тот тип клиентов, с которым вы имеете дело. Я могу с уверенностью сказать вам, что есть по крайней мере одна чрезвычайно крупная компания-разработчик программного обеспечения, которая делает это для любого консалтингового / пользовательского кода, написанного для любого клиента - и если они не согласятся с этим, то они не будут этого делать - точка ( но они направят их к партнеру).

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

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

Я думаю, что это охватывает ваши вопросы 1,2 и 4.

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

Серьезно, оба ответа начались с IANAL - я думаю, что вам нужно перестать даже думать о написании контракта и поговорить с юристом, прежде чем продолжить. Вы не спросите своего адвоката, как провести рефакторинг частей вашего кода.

Кроме того - @ Пит Уилсон прав, ваши условия, вероятно, не будут хорошо согласовываться с вашим клиентом.

Применяется обычный IANAL, что означает, проконсультируйтесь с реальным юристом.

Тем не менее, мой дубль будет:

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

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

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