Czy mogę używać wtyczek licencji Apache Software License, wersja 2.0 i GNU LGPL 3 w mojej komercyjnej aplikacji internetowej?


31

Mam dwie wtyczki. Jedna ma licencję GNU LGPL 3, a druga licencję na oprogramowanie Apache, wersja 2.0. Czy mogę ich używać w mojej aplikacji komercyjnej? A jeśli tak, jakie środki ostrożności powinienem podjąć?


17
Należy pamiętać, że NIGDY nie należy NIGDY stosować się do porad prawnych, które można uzyskać w Internecie, chyba że pochodzą one od prawnika. Najlepiej ten, który specjalizuje się w danej dziedzinie, w tym przypadku: licencje na oprogramowanie. Więc weź wszystkie odpowiedzi, które otrzymujesz z odrobiną soli, ponieważ w przeciwnym razie możesz narazić się na procesy sądowe (ponieważ Twoja aplikacja jest komercyjna).
Radu Murzea

Odpowiedzi:


34

Czy mogę ich używać w mojej aplikacji komercyjnej?

To zależy od tego, co zamierzasz zrobić z tworzonym oprogramowaniem.

Po pierwsze, ani ASL 1 , GPL ani LGPL nie nakładają żadnych ograniczeń na to, czego można używać do oprogramowania w organizacji. Wszystkie ograniczenia dotyczą kodu rozpowszechnianego poza organizacją.

  • W przypadku GPL ograniczenie polega na tym, że jeśli włączysz kod GPL do własnego oprogramowania ORAZ następnie rozpowszechnisz swoje oprogramowanie poza swoją organizacją, TO NASTĘPNIE musisz udostępnić kod źródłowy zgodnie z warunkami GPL lub zgodnej licencji typu open source.

    Więc jeśli używasz kodu GPL w swojej aplikacji i rozpowszechniasz go, to twoja aplikacja musi być open source ... w przeciwnym razie naruszasz licencję.

  • W przypadku LGPL ograniczenie (patrz wyżej) dotyczy tylko kodu źródłowego samej biblioteki LGPL; tzn. jeśli zmienisz bibliotekę. Jeśli korzystasz tylko z biblioteki, nie musisz udostępniać kodu źródłowego.

    Istnieje również ograniczenie, że kod LGPL w Twojej aplikacji musi zostać wymieniony przez użytkownika Twojego kodu. Oznacza to (w efekcie), że jeśli rozpowszechniasz swój kod tylko jako pliki binarne, nie możesz statycznie połączyć swojego kodu z tą biblioteką. Musisz użyć dynamicznego linkowania.

  • W przypadku ASL jedynym znaczącym ograniczeniem jest to, że musisz powiedzieć, jeśli zmieniłeś coś z oryginalnej wersji używanego kodu ASL.

Wreszcie, aby było jasne, ani GPL, LPGL, ani ASL nie nakładają żadnych ograniczeń na cel korzystania z oprogramowania. Obejmuje to, czy Twoim celem jest zarabianie pieniędzy. Ograniczają tylko sposób zarabiania pieniędzy ... a w przypadku LGPL i ASL ograniczenie jest dość minimalne.

A jeśli tak, jakie środki ostrożności powinienem podjąć?

W przypadku LGPL i ASL nie są konieczne żadne środki ostrożności.

IANAL - Nie jestem prawnikiem. Jeśli chcesz się upewnić, zapytaj prawdziwego, wykwalifikowanego eksperta; tj. prawnik specjalizujący się w prawie własności intelektualnej oprogramowania.


1 - Na potrzeby tej odpowiedzi ASL == Licencja oprogramowania Apache wersja 2.


Czy dotyczy to aplikacji internetowej? mam na myśli, że klient otrzyma tylko plik wojenny zawierający pliki .class i .JAR. Jeśli wszystko jest nadal w porządku?
Java,

Jeśli nie modyfikujesz bibliotek LGPL, możesz dołączyć je do kodu aplikacji w pliku WAR. Ale musisz to zrobić w taki sposób, aby osoba, do której rozpowszechniasz swój kod, mogła zastąpić kod LBPL inną wersją. „Uber-JAR” to prawdopodobnie naruszenie. Zaciemnianie bibliotek LGPL wraz z kodem jest zdecydowanie naruszeniem. (IANAL)
Stephen C

Istnieje folder o nazwie lib, w którym umieszczam wszystkie pliki jar. Więc może zamienić dowolny plik Jar z jego inną wersją. Ale nie gwarantuję, że zawsze będzie działać. Czy to nadal w porządku?
Java,

Zapytaj swojego prawnika :-)
Stephen C

To tylko zwykła aplikacja internetowa działająca na tomcat. Jeśli możesz pomóc, będzie dobrze. W każdym razie dziękuję za wyjaśnienie, które naprawdę pomaga.
Java,

5

Licencja Apache nie nakłada żadnych ograniczeń na oprogramowanie, które łączy się z wtyczką lub biblioteką dystrybuowaną na licencji Apache. Z drugiej strony, licencja LGPL wymaga, aby biblioteka LGPL łączyła się dynamicznie (i może być zastąpiona przez użytkownika) lub cała praca musi być wydana na podstawie licencji open source zgodnej z GPL.

W przypadku zastosowania w aplikacji o zamkniętym źródle oznacza to skutecznie, że można korzystać z licencjonowanej wtyczki Apache bez ograniczeń i że licencjonowana wtyczka LGPL musi być dynamicznie łączona.

Jeśli rozpowszechniasz którąkolwiek z wtyczek wraz z aplikacją, musisz także podać źródła wtyczek lub poinformować użytkowników, gdzie mogą je uzyskać.


BartvanIngenSchenau co rozumiesz przez aplikację „zamkniętego źródła”? Czy masz na myśli rozwiązanie pakietowe (nie dystrybuujące kodu źródłowego), czy też odnosisz się do jego dystrybucji w organizacji w porównaniu z dystrybucją komercyjną?
Rachael

1
@Rachael: „Zamknięte źródło” jest zwykle używane w odniesieniu do oprogramowania, dla którego kod źródłowy nie jest rozpowszechniany. Dystrybucja w organizacji jest trochę szczególnym przypadku, gdy chodzi o licencjonowanie praw autorskich, ponieważ dostarczanie kopii oprogramowania do ludzi w organizacji nie jest uważany dystrybucja dla większości prawami autorskimi (to jest uważane za kopiowanie).
Bart van Ingen Schenau

-4

Przede wszystkim nie jest to porada prawna.

Oprogramowanie GPL nie może być łączone (w tym przez sieć), kompilowane ani dostarczane z oprogramowaniem innym niż GPL dowolnej formy. LGPL nieco to rozluźnia, aby umożliwić obsługę stron trzecich poza GPL, w tym w przypadku produktów komercyjnych. Ważną częścią tutaj jest to, że musi to być strona trzecia (że tak powiem), co tworzy małą pętlę.

Krótko mówiąc, łączysz się z istniejącą biblioteką LGPL (nazywaj to pierwszą firmą), ale oprogramowanie, które tworzy to łącze, musi być LGPL. Nazwij to oprogramowanie drugą stroną. Chociaż oprogramowanie drugiej strony musi zostać wydane jako LGPL, jako właściciel oprogramowania drugiej strony możesz zezwolić, aby inne oprogramowanie korzystało z niego poza LGPL (o ile oprogramowanie drugiej strony pozostaje również dostępne na licencji LGPL). Innymi słowy, oprogramowanie drugiej strony musi zostać udostępnione jako LGPL, ale nie jest wymaganedo licencjonowania go jako LGPL we wszystkich przypadkach. Każdy użytkownik oprogramowania musi posiadać licencję na korzystanie z tego oprogramowania zgodnie z prawem. Mówię o tym, że tak długo, jak każdy użytkownik ma dostęp do oprogramowania jak LGPL, możesz także licencjonować go na warunkach innych niż wirusowe. Możesz również utworzyć oprogramowanie innych firm, w efekcie licencjonując sobie oprogramowanie zewnętrzne, do korzystania przez niego z oprogramowania na warunkach innych niż LGPL. Słyszałem nawet o ludziach, którzy sami piszą umowę i licencję na używanie własnego oprogramowania. Prawo może być dziwne! Oprogramowanie innych firm nie musi w żadnym wypadku być licencją LGPL.

Więc tworzysz bibliotekę łączącą się z biblioteką LGPL jako tylko opakowanie, i uwalniasz opakowanie jako LGPL. Następnie możesz utworzyć łącze do tego opakowania ( swojego opakowania) w oprogramowaniu innym niż LGPL, o ile opakowanie jest dostępne jako LGPL.

Nie mogę wypowiadać się w sprawie licencji na oprogramowanie Apache, ponieważ nie znam jej.


Zauważ, że używam terminu „link” bardzo ogólnie, ponieważ dotyczy to nie tylko skompilowanych języków i może również obejmować „w tym” oprogramowanie LGPL (z lokalizacji lokalnej lub sieci, np. PHP lub JavaScript), lub w inny sposób „łączenie” z oprogramowaniem w sieci, takim jak Java RMI itp.
JSON

1
„Oprogramowanie GPL nie może być łączone (w tym za pośrednictwem sieci), kompilowane ani dostarczane z oprogramowaniem innym niż GPL w dowolnej formie.” . „Lub” powinno być „i”. Możesz używać oprogramowania GPL w oprogramowaniu innym niż GPL, pod warunkiem, że go nie „wysyłasz”.
Stephen C

2
Ta odpowiedź jest błędna na tak wielu poziomach. Pytanie nie dotyczy GPL, ale LGPL. Kod ASL może być zintegrowany z kodem na prawie każdej innej licencji, co oznacza także LGPL, a nawet GPL (nawet jeśli zabronione jest odwrotnie). Możesz go nawet używać w oprogramowaniu o zamkniętym źródle. I, jak zauważył Stephen C., możesz robić, co chcesz, dopóki go nie opublikujesz lub nie udostępnisz publicznie.
Alexis Dufrenoy,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.