Разбиране на правните последици от отворения код
Споделянето на вашата творческа работа със света може да бъде вълнуващо и възнаграждаващо изживяване. Това може да означава и куп правни неща, за които не сте знаели, че трябва да се тревожите. За щастие, с това ръководство не е нужно да започвате от нулата. (Преди да се задълбочите, не забравяйте да прочетете нашия отказ от отговорност.)
Защо хората се интересуват толкова много от правната страна на отворения код?
Радвам се, че попита! Когато правите творческо произведение (като писане, графики или код), това произведение е под изключителни авторски права по подразбиране. Тоест законът предполага, че като автор на вашето произведение вие имате думата какво другите могат да правят с него.
Като цяло това означава, че никой друг не може да използва, копира, разпространява или модифицира вашата работа, без да бъде изложен на риск от премахване, разклащане или съдебни спорове.
Отвореният код обаче е необичайно обстоятелство, тъй като авторът очаква други да използват, променят и споделят работата. Но тъй като правното подразбиране все още е изключително авторско право, трябва изрично да дадете тези разрешения с лиценз.
Тези правила се прилагат и когато някой допринася за вашия проект. Без лиценз или друго споразумение всички приноси са изключителна собственост на техните автори. Това означава, че никой – дори вие – не може да използва, копира, разпространява или променя техния принос.
И накрая, вашият проект може да има зависимости с лицензионни изисквания, за които не сте знаели. Общността на вашия проект или политиките на вашия работодател може също да изискват вашият проект да използва конкретни лицензи с отворен код. Ще разгледаме тези ситуации по-долу.
Публичните GitHub проекти с отворен код ли са?
Когато създадете нов проект в GitHub, имате опцията да направите хранилището частно или публично.
Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си. Публичните проекти са обхванати от Условията за ползване на GitHub, което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.
Просто ми дайте обобщение за това, от което се нуждая, за да защитя проекта си.
Имате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект.
MIT, Apache 2.0 и GPLv3 са популярни лицензи за отворен код, но има и други опции за избор. Можете да намерите пълния текст на тези лицензи и инструкции как да ги използвате на choosealicense.com.
Когато създадете нов проект в GitHub, ще бъдете помолени да добавите лиценз.
Кой лиценз с отворен код е подходящ за моя проект?
Трудно е да сгрешите с MIT License, ако започвате с празен лист. Той е кратък, лесен за разбиране и позволява на всеки да прави каквото и да е, стига да пази копие от лиценза, включително вашето известие за авторски права. Ще можете да пуснете проекта под различен лиценз, ако някога се наложи.
В противен случай изборът на правилния лиценз с отворен код за вашия проект зависи от вашите цели.
Вашият проект много вероятно има (или ще има) зависимости, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm).
Зависимости с разрешителни лицензи като MIT, Apache 2.0, ISC и BSD ви позволяват да лицензирате проекта си както искате.
Зависимостите с лицензи за авторско право изискват по-голямо внимание. Включително всяка библиотека със “силен” лиценз за копиралефт като GPLv2, GPLv3, или AGPLv3 изисква да изберете идентичен или съвместим лиценз за вашия проект. Библиотеки с “ограничен” или “слаб” лиценз за копиралефт като MPL 2.0 и LGPL могат да бъдат включени в проекти с произволен лиценз, при условие че следвате допълнителните правила посочват те.
Можете също така да разгледате общностите, които се надявате да използвате и да допринесете за вашия проект:
- Искате ли вашият проект да бъде използван като зависимост от други проекти? Вероятно най-добре е да използвате най-популярния лиценз в съответната общност. Например MIT е най-популярният лиценз за npm библиотеки.
- Искате ли вашият проект да се хареса на големия бизнес? Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай Apache 2.0 покрива вас (и тях).
- Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код? GPLv3 или (ако те също не желаят да допринасят за услуги със затворен код) AGPLv3 ще мине добре.
Вашата компания може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с правния отдел на вашата компания за насоки.
Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте choosealicense.com, за да намерите правилния лиценз за вашия проект, дори ако не е софтуер.
Какво ще стане, ако искам да сменя лиценза на моя проект?
Повечето проекти никога не се нуждаят от промяна на лицензи. Но понякога обстоятелствата се променят.
Например, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект:
Сложно е. Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за “управленско събитие” за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало!
Съществуващият лиценз на вашия проект. Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите.
Съществуващи носители на авторски права на вашия проект. Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? Хората, които имат ангажименти във вашия проект е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.
Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник (вижте по-долу). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
Моят проект има ли нужда от споразумение за допълнителен сътрудник?
Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят “inbound=outbound” изрично по подразбиране.
Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците.
Освен това, чрез добавяне на “бумащина”, която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта.
Някои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват:
- Вашите адвокати искат всички сътрудници изрично да приемат (подписват, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. Лицензионното споразумение за jQuery Individual Contributor е добър пример за леко споразумение за допълнителен сътрудник.
- Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за Сертификат за произход на разработчици е колко проекта постигат това. Например общността Node.js използва DCO вместо от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е DCO Probot.
- Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. Лицензионното споразумение за личен сътрудник на Apache е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.
- Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. Споразумението за сътрудник на MongoDB е пример за този тип споразумение.
- Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени.
Ако все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като CLA помощник, за да сведете до минимум разсейването на сътрудниците.
Какво трябва да знае правният екип на моята компания?
Ако пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код.
За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате “споразумение за интелектуална собственост на служителите” с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания би трябвало лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания.
Ако търсите проект с отворен код за вашата компания, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:
-
Материал на трета страна: Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни (вижте по-горе). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да добавят лиценз с отворен код, и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
-
Търговски тайни: Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
-
Патенти: Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал публично разкриване? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници (вижте по-горе).
-
Търговски марки: Проверете отново дали името на вашия проект не е в конфликт със съществуващи търговски марки. Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. FOSSmarks е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
-
Поверителност: Вашият проект събира ли данни за потребители? “Домашен телефон” към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
Ако пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения).
В по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност:
- Правила за приноса на служителите: Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е Модел IP и политика за принос с отворен код на Rackspace.
- Какво да публикувате: (Почти) всичко? Ако вашият правен екип разбира и е инвестирани в стратегията на вашата компания за отворен код, те ще могат най-добре да помогнат, вместо да пречат на вашите усилия.
- Съответствие: Дори ако вашата компания не пуска проекти с отворен код, тя използва чужд софтуер с отворен код. Осъзнаването и процесът могат да предотвратят главоболия, забавяния на продукти и съдебни дела .
- Патенти: Вашата компания може да пожелае да се присъедини към Open Invention Network, споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго алтернативно патентно лицензиране.
- Управление: Особено ако и когато има смисъл да се премести проект към юридическо лице извън компанията.