W jaki sposób podpisanie CLA zapobiega problemom prawnym w projektach typu open source?

Na przykład: yeoman . Jest licencjonowany na licencji BSD. Formularz CLA (Umowa licencyjna dla współtwórców) nie jest specyficzny dla projektu i można go podpisać elektronicznie.

• Jak i jakim problemom może zapobiec podpisanie tej umowy?
• Czy ma znaczenie, jak duży lub niewielki wkład wniesiłem?
• Dlaczego niektóre projekty wymagają podpisanego CLA do akceptowania poprawek, a inne nie? (np. node.js vs rails)

Umowy CLA zazwyczaj istnieją w celu wykonania kilku czynności:

• Uniemożliwiają cofnięcie kodu na później. W krajach, które są sygnatariuszami konwencji berneńskiej, autorzy zachowują prawa autorskie do wszystkich oryginalnych dzieł, a inni mogą kopiować je tylko za wyraźną zgodą. Umowa o pracę sprawia, że ​​udzielasz tego zezwolenia wprost i często na zawsze, więc nie możesz później zmienić zdania. Niniejsza klauzula CLA zawiera taką klauzulę, więc nie ma żadnych zwrotów kodu po wniesieniu wkładu.
• Mogą powstrzymać Cię przed pozwaniem ich o naruszenie patentu. Niektórzy współautorzy są zdublowani i mogą wnieść kod, o którym wiedzą, że jest objęty jednym z ich patentów, mając nadzieję, że później pozbędą się wszystkich, gdy kod będzie rozpowszechniony. Stało się tak w niektórych głównych organach normalizacyjnych, a także w oprogramowaniu typu open source. Tutaj CLA zabrania ci ciągnięcia tego wyczynu: kiedy przesyłasz kod do tego projektu, udzielasz im, a także ich użytkownikom, wieczystych licencji royalty-free na wszelkie posiadane przez ciebie patenty, które obejmują kod, który sam przesyłasz.
• Obejmuje ich tyłek, jeśli ktoś ich pozwie lub będzie rościł sobie prawa autorskie. Większość umów CLA, w tym niniejsza, powoduje, że przysięgasz, że wszystko, co wnosisz, należy do Ciebie. Zasadniczo służy to jako sposób dla Google (lub innego projektu wyższego szczebla), który zostaje pozwany o naruszenie praw autorskich, aby wskazać na ciebie i powiedzieć: przepraszam, ale to nie my, to był on.
• Może opcjonalnie zmienić przypisanie praw autorskich, dając organizacji rodzicielskiej zęby do pozwania o naruszenie praw licencyjnych. Wreszcie, mimo że CLA, do którego się dałeś, nie robi tego, wiele projektów typu open source, w tym wszystkie prowadzone przez FSF, ma CLA, który wymaga jawnego przypisania praw autorskich, co oznacza, że ​​każdy przesłany kod będzie chroniony prawami autorskimi projektu, a nie ty. Ma to dwie zalety dla organizacji nadrzędnej: nie muszą zaokrąglać wszystkich współpracowników, jeśli chcą pozwać o naruszenie zasad open source; i nie muszą konsultować się z autorami, jeśli chcą zmienić licencję na późniejszym etapie. Większość umów CLA, które wymagają przypisania praw autorskich, przyznaje także wieczystą licencję bez opłat współautorowi i ich klientom w sposób odwrotny do działania innych umów CLA. Jak wspomniano, niniejszy CLA nie wymaga przeniesienia praw autorskich.

Większość projektów w pełni wolontariackich, takich jak Rails i Node, nie wymaga CLA, choćby z innego powodu niż dlatego, że nie ma podmiotu wspierającego, który wymagałby lub zrobiłby z nimi cokolwiek znaczącego. (Jak wspominano wcześniej, projekty wspierane przez FSF są tutaj głównym wyjątkiem). Większość wspieranych komercyjnie projektów open source, takich jak te, które są oficjalnymi produktami Google / Oracle / Apple, wymagają jakiejś formy CLA, zarówno dlatego, że większość firm ma prawników którzy myślą o tych rodzajach rzeczy, a ponieważ nie jest pojedynczą jednostką podkład do egzekwowania tego rodzaju rzeczy.

CLA mogą również (oprócz innych rzeczy wymienionych na tej stronie) chronić współpracowników przed problemami prawnymi. Spójrz na ten fragment z CLA firmy Google :

Nie oczekuje się, że zapewnisz wsparcie dla Twoich Wkładów, z wyjątkiem zakresu, w którym chcesz zapewnić wsparcie. Możesz zapewnić wsparcie za darmo, za opłatą lub wcale. O ile nie wymaga tego obowiązujące prawo lub nie uzgodniono na piśmie, przekazujesz swój wkład na zasadzie „TAK JAK JEST”, BEZ ŻADNYCH GWARANCJI ANI WARUNKÓW, wyraźnych lub dorozumianych, w tym, bez ograniczeń, jakichkolwiek gwarancji lub warunków TYTUŁU, NIE NARUSZENIE, PRZYDATNOŚĆ HANDLOWA lub PRZYDATNOŚĆ DO KONKRETNEGO CELU.

Odpowiedź Benjamina była dość jasna, ale chciałbym podkreślić jeden punkt. CLA chroni firmy korzystające lub uczestniczące w projektach. Firmy, szczególnie te duże, boją się, że zostaną zaskoczone kwestiami prawnymi. Prawnicy korporacyjni powiedzieli ludziom, że wiem, że nawet w przypadkach, gdy prawo jest po twojej stronie, masz tylko 60% pewności, że wygrasz sprawę.

Zastanów się nad sytuacją firmy, szczególnie bardzo dużej z dużymi przychodami, która tworzy produkt wokół narzędzia typu open source. Zdobywają klientów, budują infrastrukturę i zatrudniają pracowników. Jeśli nagle współtwórca oryginalnego narzędzia pozywa ich za naruszenie patentu lub praw autorskich, firma znajduje się w legalnej gorącej wodzie. Jeśli przestaną dostarczać swój produkt, zmarnują pieniądze na infrastrukturę i pracowników, których nie potrzebują, a co ważniejsze, wkurzają klientów. Z drugiej strony, jeśli przestaną dostarczać swój projekt, ich odpowiedzialność kończy się w chwili, gdy sprawa zostanie ustalona.

Biorąc pod uwagę obecny legalny krajobraz oprogramowania, CLA to najlepszy sposób, aby firmy czuły się komfortowo, korzystając z oprogramowania typu open source. To nie jest idealne (fajnie byłoby nigdy nie mieć do czynienia z żadną z tych legalnych kwestii), ale w tej chwili jest to jeden z niewielu sposobów, aby te wkłady pos