Страничният ви проект току-що премина 500 звезди и непознат отвори първия сериозен pull request: 2000 реда, които решават проблем, който отбягвате от месеци. Искате да натиснете merge. Но преди да го направите, задайте си неудобния въпрос: имате ли всъщност законното право да разпространявате този код — и да продължите да го разпространявате под лиценза си, завинаги, независимо за кого работи този сътрудник?
Ако хранилището ви няма политика за сътрудничество, честният отговор е, че не сте сигурни. Сътрудникът все още притежава авторското право върху всеки ред, който е написал, а лицензът на проекта ви сам по себе си не винаги урежда кой какви права на кого е предоставил. Тази несигурност остава невидима до деня, в който стане важна: прелицензиране, придобиване, корпоративен потребител, извършващ проверка на лицензите, или работодателят на сътрудник, който твърди, че работата е била негова през цялото време.
Два механизма решават този проблем и почти всеки проект с отворен код избира един от тях: Споразумението за лиценз на сътрудник (CLA) и Сертификатът на разработчика за произход (DCO). И двете съществуват, за да установят, че даден сътрудник има право да направи приноса и че проектът има правото да го разпространява. Те се различават огромно по тежест, триене и по това какво ви позволяват да правите по-късно. Това ръководство обяснява как работи всяко от тях, кога да изберете кое и как да настроите избора си за един следобед.
Защо на проекта ви е нужна политика за сътрудничество
Авторското право възниква автоматично. В момента, в който някой напише код, той го притежава — не е нужна регистрация, не е нужно обозначение за авторско право. Когато го изпрати на проекта ви, лицензът ви за отворен код покрива много, но оставя празнини, които само политика за сътрудничество запълва:
- Входящото предоставяне на права. Вашият изходящ лиценз (MIT, Apache-2.0, GPL) казва на потребителите какво могат да правят с кода ви. Политиката за сътрудничество прави изрично, че входящите приноси пристигат при съвместими условия, така че можете да разпространявате комбинираната работа, без да проследявате произхода файл по файл на ръка.
- Претенции на работодатели. Повечето трудови договори прехвърлят IP върху странични проекти на работодателя, поне за работа, свързана с длъжността на служителя. Политика, която иска от сътрудниците да потвърдят, че имат право да предоставят приноса, възлага тази отговорност — и документалната следа — на сътрудника.
- Възможност за прелицензиране. Ако някога поискате да смените лицензите, да добавите търговско издание или да дарите проекта на фондация, се нуждаете от правата на всеки сътрудник. Събирането на това разрешение впоследствие от десетки минали сътрудници е някъде между болезнено и невъзможно. Политика, избрана в първия ден, решава дали тази врата остава отворена.
- Патентна защита. Приносите на код могат да носят със себе си патентни права. Някои политики включват изрично предоставяне на патентни права; други — не, което е по-важно, отколкото повечето поддържащи осъзнават.
Нищо от това не изисква адвокатска кантора на постоянен договор. Изисква да изберете CLA или DCO, да го запишете в хранилището си и да го наложите автоматично. Ето какво включва всеки избор.
Какво е Споразумение за лиценз на сътрудник (CLA)?
Споразумението за лиценз на сътрудник е подписан правен документ между сътрудника и проекта (или компанията, или фондацията зад него). Сътрудникът подписва веднъж и този подпис покрива всичките му бъдещи приноси.
За разлика от лицензите за отворен код, CLA не са стандартизирани. Всеки проект написва своето, но повечето попадат в две познати форми:
Индивидуални срещу корпоративни CLA
- Индивидуален CLA (ICLA): подписан от лице, което допринася от свое име. Обикновено предоставя на проекта широк лиценз за авторско право и често патентен лиценз, докато сътрудникът запазва своето авторско право.
- Корпоративен CLA (CCLA): подписан от компания, упълномощаваща своите служители да допринасят. Компанията предоставя същите права за работата, която нейните хора предоставят. Проекти, които приемат корпоративни приноси без CCLA, се доверяват, че ръководителят на всеки служител знае — и одобрява — което е точно видът доверие, който се изпарява по време на проверка.
Предоставяне на лиценз срещу прехвърляне на авторско право
Повечето съвременни CLA са предоставяне на лиценз: сътрудникът запазва собствеността и дава на проекта вечен, световен, безвъзмезден лиценз — често достатъчно широк, за да позволи прелицензиране. ICLA на Apache Software Foundation е каноничният пример.
Малцинство проекти използват прехвърляне на авторско право, при което сътрудникът прехвърля собствеността направо (подходът на Free Software Foundation). Прехвърлянето дава на проекта максимална свобода да налага права и да прелицензира, но изисква най-много от сътрудниците и е излязло от употреба при проектите, водени от общността.
Какво ви струва CLA — на вас и на сътрудниците ви
Компромисът е триенето. Сътрудник за първи път трябва да напусне pull request-а, да прочете правен документ, да го подпише (обикновено електронно) и да изчака проверката на статуса да стане зелена, преди поддържащ да прегледа кода му. Инструментите са направили това почти безболезнено — ботове като CLA Assistant коментират pull request-а с връзка за подписване и записват подписа автоматично — но все още е порта между „поправих бъга ви" и „можете да обедините поправката ми". Някои случайни сътрудници се отказват пред нея.
В замяна проектът получава подписан, проверим запис: това лице, на тази дата, предостави тези права. За проекти с корпоративна подкрепа, проекти с двойно лицензиране и всичко, което някой ден може да бъде придобито, тази документална следа си струва реални пари.
Какво е Сертификатът на разработчика за произход (DCO)?
Сертификатът на разработчика за произход беше въведен от Linux Foundation през 2004 г. за ядрото на Linux, именно за да се избегне тежестта на CLA. Той не е договор, който сътрудникът подписва и архивира. Той е кратко удостоверение — пет параграфа, версия 1.1 — което сътрудникът потвърждава при всяко комитване, като добавя ред Signed-off-by в съобщението на комита:
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>Добавянето на реда е един флаг: git commit -s го добавя автоматично, използвайки конфигурираната ви Git самоличност. С подписването сътрудникът удостоверява, че:
- Той е създал приноса (изцяло или частично) и има правото да го предостави под лиценза за отворен код на проекта, или
- Неговият принос се основава на предишна работа, вече под подходящ лиценз за отворен код, който позволява това предоставяне, или
- Той е получил приноса от някой друг, който е удостоверил едно от горните, и не го е променил, и
- Той разбира, че приносът и записът за него — включително подписът му — са публични и се съхраняват за неопределено време.
Това е целият механизъм. Без отделен документ, без свързване на акаунти, без въвеждане за всеки проект. Наложението е проверка на статуса: приложението DCO или еквивалентна проверка потвърждава, че всеки комит в pull request-а носи валиден подпис, и поддържащите обединяват само когато е зелено.
Умишлените ограничения на DCO
Забележете какво DCO не прави. Не предоставя лиценз извън това, което изходящият лиценз на проекта вече дава — разчита на това, че приносът пристига при условията на лиценза на проекта. Не съдържа патентно предоставяне. И тъй като нищо не се подписва и архивира за всеки отделен сътрудник, няма централен регистър кой на какво е съгласил; самата git история е записът.
Привържениците смятат това за предимство: ниската бариера на DCO е смисълът. Ядрото на Linux, GitLab (което премина от CLA през 2017 г.) и Chef (което премина през 2016 г.) всички заключиха, че удостоверяването при всяко комитване им дава произхода, от който се нуждаят, без да облага всеки сътрудник. Техническият комитет на OpenStack реши през 2025 г. да замени своя CLA с DCO за всички приноси. Индустриалната тенденция е неоспорима — но тенденцията не е присъда за вашия проект, както обясняват следващите раздели.
CLA срещу DCO рамо до рамо
| Измерение | CLA | DCO |
|---|---|---|
| Правен механизъм | Подписано споразумение, архивирано веднъж за всеки сътрудник | Удостоверяване при всяко комитване в съобщението на комита |
| Какво прави сътрудникът | Подписва документ (обикновено чрез връзка от бот) | Добавя Signed-off-by с git commit -s |
| Обработка на авторско право | Изрично предоставяне на лиценз (или прехвърляне) на проекта | Приносът пристига под лиценза на проекта; без отделно предоставяне |
| Патентно предоставяне | Обикновено включено | Няма |
| Свобода за прелицензиране | Широките предоставяния често го позволяват | Без допълнителни права; прелицензирането изисква съгласието на всеки сътрудник |
| Триене за сътрудника | По-високо: прочети, подпиши, изчакай проверката | Минимално: един Git флаг |
| Инструменти за налагане | CLA Assistant, EasyCLA, персонализирани ботове | Приложение DCO, проверки на съобщението на комита |
| Запис за съгласие | База данни с подписи | Самата git история |
| Покритие на работодатели | Корпоративният CLA покрива служителите изрично | Сътрудникът сам удостоверява, че има право да предостави приноса |
| Най-подходящ за | Проекти с корпоративна подкрепа, двойно лицензиране или значение за придобиване | Проекти на общността, където триенето при принос е най-важно |
Кога CLA е правилният избор
Изберете CLA, когато бъдещето на проекта може да зависи от права, които DCO не улавя:
- Планирате двойно лицензиране или прелицензиране. Ако търговско издание, смяна на лиценз или преминаване от копилефт към разрешителен лиценз е дори отдалеч вероятно, CLA с широко обратно предоставяне е единственият лек начин да запазите тази възможност отворена. Реконструирането на съгласие години по-късно е кошмарният сценарий.
- Зад проекта стои компания. Корпоративни спонсори, купувачи и корпоративни клиенти, извършващи проверка на IP, искат регистър с подписи, а не археология. Google, проектите на Apache и Canonical използват CLA точно поради тази причина.
- Патентите имат значение във вашата област. Кодеци, безжични протоколи, архитектури на ML модели — в области, наситени с патенти, изричното патентно предоставяне на CLA върши реална работа, която DCO тихо пропуска.
- Фондация го изисква. Някои фондации налагат своя CLA като условие за hosting или завършване. Проверете, преди да предположите, че DCO е достатъчен.
Ако поемете по този път, дръжте самия CLA стандартен и скучен: започнете от Apache ICLA или шаблон на Harmony, вместо да съставяте от нулата, публикувайте както индивидуалната, така и корпоративната версия, и свържете бот за подписване в първия ден, така че триенето да е едно кликване, а не размяна на PDF.
Кога DCO печели
Изберете DCO, когато приносите са жизнената сила, а триенето е врагът:
- Проекти на общността с много случайни сътрудници. Поправки в документацията, корекции на печатни грешки, малки кръпки за бъгове — приносите, които най-вероятно ще се откажат пред порта за подписване, са също тези, които DCO обработва изящно.
- Разрешителен лиценз, без планове за прелицензиране. Ако проектът ще остане MIT или Apache-2.0 завинаги и няма търговско издание в плановете, допълнителните права на CLA ви носят малко.
- Самостоятелни поддържащи и малки екипи. DCO не се нуждае от инфраструктура за подписи, от правно лице, което да съхранява споразумения, и от процес за подписване на корпоративни формуляри. Това е управление, което можете да водите от файл
CONTRIBUTING.mdи проверка на статуса. - Позиция за максимална съвместимост. Някои сътрудници — особено тези, наети от големи компании със строги IP политики — могат да подпишат DCO, но не могат да подпишат външен CLA без правен преглед. DCO оставя тази врата отворена.
Което и да изберете, запишете решението. CONTRIBUTING.md, който посочва политиката, показва точния поток за подписване или удостоверяване и свързва пълния текст, премахва най-честия източник на объркване: сътрудници, които гадаят изискванията от неуспешна проверка на статуса.
5 грешки, които подкопават всеки от изборите
1. Да кажете и двете. Най-честият реален провал е CONTRIBUTING.md, който изисква DCO подписи в един параграф и CLA подписи в друг — обикновено след наполовина завършена миграция. Сътрудниците следват една инструкция, другата проверка се проваля и поддържащите все пак обединяват, което обезсмисля и двата механизма. Изберете един механизъм, наложете го и изтрийте всяка следа от другия.
2. Без автоматизирано налагане. Политика, заявена само в проза, е предложение. Свържете проверката в работния поток на pull request-ите си като задължителна проверка на статуса — приложението DCO за подписите, CLA Assistant или EasyCLA за подписването — така че неодобрен принос да не може да се обедини случайно или от умора на поддържащия.
3. Да игнорирате корпоративните сътрудници. Ако компании използват и кръпват проекта ви, служителите ще предоставят код в работно време. При политика с CLA това означава да получите подписания CCLA рано, докато отношенията са топли. При политика с DCO това означава да се уверите, че изискването за подпис е достатъчно видимо, че първият принос на никого да не се превърне в IP инцидент.
4. Да предполагате, че трудовите договори позволяват принос. Обратната страна на същата монета: ако допринасяте към други проекти, проверете първо собствения си трудов договор. Много от тях прехвърлят IP върху свързани с работата странични проекти на работодателя по подразбиране. Удостоверяването на DCO („имам правото да предоставя това") е вярно само ако документацията го потвърждава.
5. Без политика за код, подпомогнат от AI. Машинно генерираните приноси повдигат въпроси за произхода, които нито текстът на DCO от 2004 г., нито повечето шаблони на CLA са предвидили. Решете позицията си — разрешено с преглед, разкрито или забранено — и я заявете в CONTRIBUTING.md заедно с политиката си за CLA/DCO, преди да пристигне първият ви AI-генериран pull request, а не след това.
Не забравяйте финансовата страна на проекта си
Ето частта, която поддържащите отлагат до данъчния сезон: в момента, в който проектът ви спечели първия си долар — изплащания от GitHub Sponsors, дарения от Open Collective, консултантски ангажимент, който дойде заради README-то ви — той има финанси, а финансите се нуждаят от счетоводни книги.
Същата дисциплина, която прави произхода на приносите проверим, прави и парите на проекта управляеми. Проследявайте спонсорския доход отделно от заплатата си, за да знаете какъв е облагаемият доход от самостоятелна заетост. Записвайте разходите на проекта — подновявания на домейни, CI минути, следобеда, който адвокат прекара в преглед на CLA ви — в отделни сметки, така че удръжките да не се изпарят в извлеченията на личната ви карта. Ако проектът прерасне в LLC или се присъедини към фискален домакин, чистите исторически записи правят прехода скучен, а не съдебно-медицински.
Счетоводството на чист текст пасва необичайно добре на този работен поток: счетоводната ви книга живее в контрол на версиите до кода ви, всеки запис има история и нищо не се крие в патентован формат. Нашата документация показва как да стартирате първа счетоводна книга за минути.
Пазете книгите на проекта си толкова чисти, колкото е git историята му
Изборът между CLA и DCO отнема един следобед; разплитането на произход или финанси на проекта години по-късно отнема седмици. Вземете решението за приносите сега, автоматизирайте налагането му и дайте на парите на проекта същата грижа, която давате на комитите му. Beancount.io предоставя счетоводство на чист текст, което ви дава пълна прозрачност и контрол върху финансовите ви данни — без черни кутии, без обвързване с доставчик. Започнете безплатно и вижте защо разработчиците и финансовите специалисти преминават към счетоводство на чист текст.
