Temat: Łączenie licencji GPL2 z BSD
Jako, że zarabiam na pisaniu zamkniętego (pod klucz) softu, który korzysta z rozwiązań GPLowych, swego czasu "przeorałem" temat. Wiele przemyśleń zawarłem w
tym temacie (grupa
Programiści .NET).
Postaram się streścić te kilkanaście postów w wątku. Niestety, prawnicy, których tam cytowałem, różnili się znacznie w swoich opiniach, zastrzegając, że interpretacji i tak dokona sąd :) Tu nigdy nie będziesz "w 100% pewien wygranej". Można jednak podać kilka zasadniczych punktów:
1.
komunikacja z modułem GPL musi odbywać się w specyficzny sposób - "at arm's length" (tak to ujęto w FAQ). Onacza to, że:
a)
wolno Ci forkować/exekować aplikację na licencji GPL2, podając jej parametry i odczytując jej "wyjście"
b)
wolno Ci komunikować się z tą aplikacją za pomocą różnych "mediów", jak: webserwis (
Long live the web services loophole), pliki wymiany, potoki, OLE COM, DDE, TCP itp. Oznacza to, że możesz sobie np. zbudować "komunikator", który rozdzieli obie aplikacje - wtedy jedna jego "strona" musi być na GPL (bo będzie "mocno sprzężona" z aplikacją) i jej źródła musisz udostępnić na życzenie
b)
nie wolno Ci "linkować" - ani statycznie, ani dynamicznie do bibliotek. To właśnie powoduje "przeniesienie" GPLa na Twoją aplikację.
Tu uwaga na licencję ewentualnych
skryptów! Co prawda skrypty, chociaż wykonywane w przestrzeni adresowej aplikacji nie są zwykle objęte GPLem, ale jeśli tylko będą do tej samej przestrzeni ładować dodatkowo komponenty GPLowe (np. sterownik do bazy danych), to masz dynamiczne linkowanie - i po ptokach :)
2.
wymiana informacji musi być "prosta" - żadnych "complex data structures". Co to znaczy "complex"? Nie zdefiniowano :) Raczej powinny "przejść":
a) komendy (w rodzaju "SEND XXXX, COPY AAA, BBB, READ YYYY")
b) nazwy skryptów zawierających polecenia do wykonania
c) pliki z wynikami (XML, HTML, CSV). CSV ma relatywnie najprostszą strukturę, na XMLe trzeba uważać (na ich złożoność)
d) wartości liczbowe/tekstowe zwracane przez w/w komunikator.
e) zapisy/odczyty do/z bazy danych
Binarne, złożone formaty i duże ilości (???) danych są już dyskusyjne.
3. Twoja aplikacja powinna się
"budować" i uruchamiać bez modułu na licencji GPL.
Możesz to osiągnąć za pomocą interfejsów i "mocków" aplikacji GPLowej.
Innymi słowy - chodzi o to, że Twoja aplikacja nie może być uzależniona od aplikacji GPLowej. Musisz dać userowi wybór korzystania z Twojej lub innej aplikacji.
A przynajmniej Twoja aplikacja musi się samodzielnie uruchomić i "robić coś sensownego" ("nie tylko wyświetlić okienko "zainstaluj phpBB" :) )
3a. Niektórzy prawnicy wskazują na to, że Twoja aplikacja (zamknięta) nie powinna być jedynie "ozdobnikiem", "skromną nadbudówką" modułu GPL, tylko samodzielnym produktem, który zaledwie "rozszerza oferowane możliwości o to, co oferuje moduł GPL". Tutaj jest problem tzw. "derivative work". U Ciebie to IMHO nie występuje.
4.
Nie możesz dystrybuować (to convey) modułu GPL razem z Twoją aplikacją (o ile chcesz zamknąć jej źródła). Możesz jednak:
a) pozostawić kwestię instalacji użytkownikowi (niech sam zainstaluje MySQL, phpBB)
b) zrobić to za niego. W tym przypadku wolno Ci policzyć sobie za to jako za usługę wdrożeniową (licencja GPL nie zabrania zarabiania na programach GPL!)
4a. Jeśli nie ma dystrybucji softu, bo znajduje się na serwerze (jako usługa - SAAS), to nie masz problemu, bo GPL2 tego nie dotyczy. Są na to jednak inne licencje, np. "Affero" :)
Na koniec chciałbym przypomnieć, że WOLNO CI zarabiać na programach GPL - nikt nigdy tego nie zabraniał i nie zabrania. Nie wolno jedynie ograniczać userowi dostępu do źródeł.
Oczywiście oznacza to, że z chwilą, gdy je otrzymał, może wystawić je na swojej stronie za free :) I nie wolno Ci wówczas wymusić na nim w żaden sposób "poufności źródeł". To jest jego własność ("wolność do dowolnego rozporządzania").
Podsumowując - wydaje mi się, że u Ciebie nie będzie większego problemu, bo CMS raczej na pewno będzie pracował samodzielnie, a forum będzie jedynie dodatkiem. Zależy tylko, jak je połączysz... Dystrybucję lepiej porzuć, albo daj na swojej stronie link do ściągnięcia. Alternatywnie możesz też napisać własny prosty instalator (taki "web installer"), który zautomatyzuje cały proces pobierania i instalacji softu GPL, sprowadzając go do klikania "Next, next, next". Wtedy user bardzo tego nie odczuje. Wydaje mi się, że to jest właśnie rozwiązanie dla Ciebie.
Oczywiście żaden prawnik nie da Ci 100% pewności, albo ograniczy się do "do not do it" (przerabiałem już to). W razie czego - sąd przyjrzy się Twoim "intencjom". Zawsze też możesz napisać do autora GPLa i zapytać o licencję komercyjną, ale w przypadku softu OpenSource często jest to wiele komponentów na różnych licencjach. No i nie liczyłbym na to... - jak ktoś w tamtym wątku wspomniał - "GPL powstało by chronić kod, nie wasze interesy" :)
Są komercyjne rozwiązania oparte bądź związane z GPL, np.:
1. Pakiet statystyczny Statistica oraz SPSS współpracują z GNU R. R może pracować sam. Statistica/SPSS mogą pracować same. R jest GPL, zaś Statistica kosztuje kilka ładnych kpln/stanowisko.
2. Inne przykłady:
http://r.789695.n4.nabble.com/R-and-Commercial-applica...
EDIT: Ostatnia sprawa - jeśli byś kiedyś pisał soft "pod klucz", a w dodatku były w nim zawarte jakieś "tajemnice klienta", to nie musisz się zbytnio martwić o otwarte źródła, gdyż:
a) klient raczej nie odda za free konkurencji tego, za co Ci słono zapłacił :)
b) ... i nie ujawni jej swoich tajemnic
c) nikt Ci nie zabrania użyć tych źródeł w innych aplikacjach
d) możesz dowolnie skomplikować proces instalacji tak, że nawet gdy ktoś ma źródła, to będzie wolał kupić usługę wdrożenia.
To wszystko dotyczy GPL2. GPL3, AFAIR, ma kilka ograniczeń. Zawsze zwracaj uwagę na wersję licencji.
Adrian Olszewski edytował(a) ten post dnia 15.01.13 o godzinie 03:12
пропозиції роботи
