Należy zauważyć, że ten scenariusz może mieć miejsce zarówno w formie prawnej, jak i nielegalnej.
Może to nastąpić zgodnie z prawem, jeśli firma jest właścicielem lub ma dostęp do praw autorskich związanych z kodem. Na przykład mniejsze, niezależne zespoły programistów mogą chcieć sprzedać lub licencjonować swoje prawa autorskie większej firmie. Podobnie, jeśli większość praw autorskich do kodu można uzyskać, część „nieosiągalna” może być po prostu wyrzucona i przepisana.
Po drugiej stronie monety kod można po prostu pobrać nielegalnie. New Corp, Inc. może nie dbać o konsekwencje prawne. Projekt może być za stary lub zarzucony albo New Corp uważa, że wygra w procesie sądowym. Lub New Corp może być zarejestrowany w obszarze, w którym tego rodzaju „przejęcie” po prostu nie jest zdefiniowane jako nielegalne. Nie wszystkie licencje OSS są możliwe do wyegzekwowania, szczególnie nie te, które zostały połączone przez nie-ekspertów w dziedzinie prawa. Nie wszyscy właściciele projektów mogą mieć możliwość egzekwowania swoich roszczeń dotyczących praw autorskich, a większe organizacje, takie jak FSF, mogą nie występować w tej jurysdykcji w związku z tym roszczeniem. TL; DR - ten obszar może szybko stać się mętny i brzydki.
Przejście i zapobieganie
Jak przebiega przejście i co można zrobić, aby nie dopuścić do wybrania licencji różnicowej?
Przeniesienie następuje, gdy New Corp, Inc. nabywa bazę kodu i umieszcza te kopie pod ich kontrolą. Deweloperzy Nowy Corp następnie rozpocząć pracy nad ich wersją tworzeniu kodu bazowego cokolwiek zmienia władcy korporacyjnych zarządził konieczne. Rzeczywista mechanika tego widelca będzie się różnić w zależności od repozytorium. I choć jest to filozoficznie ważna sprawa, w praktyce jest to naprawdę rozczarowujące. get allz OpenRepos, a następnie checkindo PrivateRepos.
Co można zrobić, aby zapobiec rozpowszechnianiu źródła? Nic. Przepraszam.
Jako przykładu użyjmy GPL (licencja publiczna GNU). GPL wymaga, aby źródło było dostępne dla każdego, kto otrzyma legalną kopię projektu. Nie ma przepisów, które pozwalają posiadaczowi źródła odmówić dostarczenia źródła prawowitemu posiadaczowi kopii aplikacji GPL. Jest to sprzeczne z zasadami Wolnego oprogramowania i dlatego obowiązuje copyleft GPL.
Potencjalnie masz do czynienia z faktycznymi prawnymi działaniami. Ale to wszystko po tym, jak źródło uciekło i zostało rozwidlone, nie wcześniej. W niektórych jurysdykcjach nie będziesz mieć możliwości skorzystania z pomocy prawnej. A wszystko to zakłada, że zdajesz sobie sprawę, że widelec miał miejsce. Możesz się nigdy nie dowiedzieć.
Etyka
Jakie są (etyczne lub społeczne) obowiązki firmy? (Na przykład: oddanie się projektowi typu open source byłoby etyczne)
Etyka ma charakter lokalny w kulturze. Więc odpuszczaj ten fragment tym ziarnem soli. Pełna dyskusja na temat kulturowego rozważania etyki wykracza poza zakres tej odpowiedzi i jest nie na temat dla programistów.
Zauważyłem, że społeczność programistyczna reaguje negatywnie na wrogie rozwidlenie. Heck, w niektórych przypadkach ta sama społeczność nadal negatywnie reaguje na przyjazny i legalny rozwidlenie. To dość złożona społeczność.
Z punktu widzenia FOSS oczekuje się, że New Corp „spłaci” społeczności za wniesiony przez nią wkład. Warunki i czas trwania tej spłaty są tak różne, jak liczba istniejących projektów OSS. Niektórzy członkowie społeczności (sądzą, że Richard Stallman) nigdy nie będą zadowoleni z zamknięcia otwartego projektu. Inni będą szukać korzyści dla całej społeczności i na tej podstawie ocenią. A inni po prostu nie będą się tym przejmować, ponieważ nigdy nie wiedzieli o projekcie pochodzenia ani nie dbali o niego.
Dostępność źródła
Jeśli zarówno wersja open source, jak i wersja zamknięta są dostępne, jak konkurencja wpływa na którykolwiek z produktów?
To naprawdę zależy od tego, jak porównywalne są dwie podstawy kodu pod względem funkcjonalności, wydajności i stabilności.
Jeśli podstawy kodu pozostają podobne, a New Corp jest przyjazny społeczności OSS, mogą wnieść swoje aktualizacje z powrotem do projektu podstawowego. W tym przypadku wszyscy korzystają. W tym przypadku nie jest to „konkurencja”, ale raczej wzajemnie korzystna współpraca.
Jeśli podstawy kodu gwałtownie się różnią, a New Corp nie jest przyjazny dla społeczności OSS, nadal nie ma konkurencji. Im bardziej bogaty w funkcje produkt przetrwa, a mniej bogaty produkt zwykle umiera. Pamiętaj, że może to pójść w obie strony - wersja zamknięta może umrzeć, jeśli wersja open source będzie nadal wprowadzać innowacje lub lepiej spełniać potrzeby społeczności.
Rzeczywistość będzie gdzieś pomiędzy tymi dwoma końcami spektrum.
Przykład
Red Hat ma dwie główne dystrybucje - Enterprise Linux i Fedora. EL jest ich „zamkniętą” licencjonowaną wersją, a Fedora jest ich wydaniem społecznościowym. Ze względu na GPL wiele, jeśli nie całość, edycji EL jest wydawana w formie źródłowej. Inny projekt niezwiązany z Red Hat o nazwie CentOS przejmuje zmiany w EL i dystrybuuje ten projekt po niewielkiej zmianie marki.
Były pewne narzekania, gdy Red Hat rozwidlił się na dwie oddzielne edycje, ale ogólnie rzecz biorąc, była to całkiem realna umowa. Społeczność Fedory chciała, aby funkcje pojawiły się w dystrybucji szybciej niż klienci firmy Red Hat czuli się komfortowo. Ulepszenia baz kodu przepływają w obu kierunkach.