Zalecenia i doświadczenia dotyczące wyboru licencji na oprogramowanie?

Twórcy oprogramowania mogą wybrać odpowiednią licencję zgodnie z celem (celami) pracy.

Czy ktoś może podać jakieś rekomendacje / doświadczenia dotyczące licencji na oprogramowanie?

Jakie są zalety / wady „rozdawania” całej zakodowanej pracy jako kodów open source?

Jak radzić sobie z graczami przemysłowymi, którzy chcieliby skorzystać z kodu badań?

Czy ktoś może podać jakieś rekomendacje / doświadczenia dotyczące licencji na oprogramowanie?

To, którą licencję wybierzesz, będzie zależeć od tego, jak wolny chcesz mieć kod, ale wolny oznacza różne rzeczy dla różnych osób.

• Zwolennicy zezwoleń na korzystanie z bezpłatnych licencji oznaczają , że ludzie mogą teraz korzystać z oprogramowania w sposób, w jaki chcą teraz , nie martwiąc się o to, jak wolne są przyszłe pochodne.
• Dla zwolenników licencji copyleft , darmowe oznacza zagwarantowanie, że oprogramowanie i wszelkie jego pochodne pozostają wolne , będąc przygotowanym na poświęcenie niektórych bezpośrednich wolności, aby to zapewnić.

Im bardziej liberalna jest licencja, tym więcej osób będzie mogło z niej korzystać, ale tym mniej masz nad nią kontroli. Im bardziej restrykcyjne, tym bardziej prawdopodobne jest, że zniechęcisz ludzi do korzystania z twojego oprogramowania.

Istnieje wiele bezpłatnych i otwartych licencji, w tym GPL <= 2, GPL 3 , LGPL , BSD , Eclipse i tak dalej. Każdy ma wady i zalety, więc przeczytaj, jakie ograniczenia nakładają na kod i zdecyduj, komu chcesz go użyć. Ostrzeżenie , cokolwiek wybierzesz, ktoś narzeka - jest to terytorium świętej wojny .

Ogólnie rzecz biorąc, jest to subtelna czynność równoważąca i zależy bardzo od docelowej grupy odbiorców twojego oprogramowania.

• Świetnym źródłem informacji o tym, która licencja jest dla Ciebie odpowiednia, jest bardzo wszechstronny, interaktywny wyróżnik licencji z Oxford University OSS Watch .

Moim zdaniem, zarówno licencje permissive , jak i copyleft są odpowiednie dla kodu naukowego - najważniejsze jest to, że kod jest przede wszystkim open source. Uważam, że nauka powinna być otwarta, podobnie jak kod wykorzystywany do wspierania tej nauki.

Jakie są zalety / wady „rozdawania” całej zakodowanej pracy jako kodów open source?

Ideą oddawania oprogramowania jest to, że jeśli inni uznają to za przydatne, będą go używać.

Jeśli z niego skorzystają, znajdą, zgłaszają i często naprawiają błędy, oszczędzając twojego wysiłku.

Jeśli im się podoba, a twoje oprogramowanie robi prawie to, czego chcą, mogą ulepszyć twoje oprogramowanie i wesprzeć te ulepszenia.

To dużo FI chociaż.

Jak radzić sobie z graczami przemysłowymi, którzy chcieliby skorzystać z kodu badań?

Po pierwsze, jeśli chcesz zabronić komercyjnego wykorzystania swojego kodu, możesz wybrać licencję bez klauzuli ponownego komercyjnego wykorzystania.

Po drugie, jeśli uważasz, że ktoś może użyć twojego oprogramowania do zasilania usługi, bez faktycznego rozpowszechniania kodu innym osobom, możesz rozważyć Affero GPL, która blokuje tę konkretną lukę copyleft.

Po trzecie, możesz zrobić powyższe i zaoferować opcję podwójnej licencji. Oferowanie licencji GPL lub AGPL do publicznego pobrania oraz licencje komercyjne za opłatą dają najlepsze z obu światów i oznaczają, że możesz nawet być w stanie wygenerować przychody ze sprzedaży komercyjnej oprogramowania, które mogą pomóc w działalności naukowej.

Uwaga: jeśli masz zamiar to zrobić, zaoferuj to od samego początku - może to spowodować mniejsze tarcie ze strony współpracowników Open Source niż późniejsze oferowanie licencji komercyjnych. Jeśli Twoja społeczność stanie się popularna, nie chcesz, aby ludzie zarzucali Ci, że się sprzedałeś, jeśli nie miałeś racji co do możliwości komercyjnego wykorzystania. Najlepiej, zanim zaczniesz akceptować wkłady osób trzecich do swojej bazy kodu, najlepiej zawrzeć odpowiednią Umowę Licencyjną Współtwórcy .

Ta odpowiedź na to pytanie zawiera również dobre informacje na temat tej opcji.

PETSc korzysta z tej licencji , która jest mniej restrykcyjną formą BSD . Zasadnicza różnica w stosunku do GPLoznacza to, że oprogramowania można używać komercyjnie. Wiele osób ma zasadniczy sprzeciw wobec zamkniętego oprogramowania, jednak z mojego doświadczenia wynika, że ​​żadna firma nie zbliży się do twojego kodu, jeśli ma licencję GPL. Ponadto użytkownicy przemysłowi PETSc byli niezwykle cenni. Mają zwykle dość skomplikowane problemy, które dla większości naukowców byłyby trudniejsze niż uzasadnione dla publikacji. Wnieśli także dużo kodu z powrotem do PETSc, aby mógł on wejść do normalnego łańcucha wsparcia. Odradzałbym każdą licencję nieposiadającą potencjału komercyjnego i faktycznie zalecałbym jak najmniej restrykcyjną licencję (zdecydowanie możesz nagrać PETSc na płytę CD i spróbować sprzedać ją łatwowiernemu).

Korzystam z GPL, głównie z powodu sentymentu do oryginalnego ruchu open source (i dlatego mam nadzieję, że pomoże on w rozprzestrzenianiu się). Co więcej, jest to paradoksalnie najlepszy sposób na ochronę twoich możliwych zarobków przed niemoralnymi kapitalistami - jako autor zawsze możesz równolegle rozpowszechniać kod na innej licencji, a tym samym zachować zastrzeżoną wersję na użytek białej firmy.
Jednak może to być również oszustwo - Twoje źródło finansowania może zrzec się, że cała twoja praca powinna stać się własnością publiczną, co wykracza poza tę licencję.

W każdym razie najważniejszą rzeczą w tym temacie jest to, że każda licencja jest lepsza niż żadna, co niestety dość często występuje w świecie rozwoju naukowego - a ja po prostu nienawidzę tych wszystkich / * Skradzionych z programu Johna Smitha, którego nigdy nie publikował * / lub Myślę, że widziałem to w poście Jane Smith na jakiejś grupie w 1995 roku ... a może 1993?

Po pierwsze, zalety / wady przejścia na open source:

Pro: więcej osób będzie używać Twojego kodu, przekaże opinie, poprawki, ulepszenia itp. W końcu będziesz mieć lepszy kod i więcej osób, które mu zaufają.

Przeciw: jeśli kiedykolwiek chcesz oprzeć firmę na kodzie, masz mniej opcji (ale wciąż jest kilka takich, jak sprzedaż usług doradczych)

Jeśli chodzi o wybór licencji, postąpiłbym w następującej kolejności:

1. Czy Twój pracodawca / agencja grantowa coś narzuca? Więc nie masz wyboru. Zaznacz to dla wszystkich autorów kodu.
2. Czy ponownie używasz kodu, który ma określoną licencję, która ogranicza Twój wybór? Zatem twoje wybory są również ograniczone. W praktyce integracja fragmentów kodu na licencji GPL jest najczęstszym źródłem takich ograniczeń.
3. Zdecyduj, co bardziej cenisz: filozofia „wszystko, co powinno być otwarte”, stojąca za GPL i podobnymi licencjami, lub filozofia zachęcania do jak najszerszego możliwego zastosowania, stojąca za licencją BSD.
4. W ramach każdej z dwóch dużych rodzin licencji Open Source wybierz zgodnie z tym, co jest najczęściej / akceptowane w Twojej społeczności.

Większość moich badań jest finansowana ze środków publicznych, dlatego czuję się zobowiązany do korzystania z możliwie najmniej restrykcyjnej licencji. Jeśli inne osoby w moim kraju pomagają zapłacić za te badania, czy naprawdę mam prawo powiedzieć im, że nie mogą zintegrować mojego kodu z zamkniętym źródłem i / lub komercyjną dystrybucją oprogramowania? Oczekuję, że większość osób, które używają mojego kodu, będą naukowcami akademickimi, ale nie mam filozoficznych problemów z firmami, które ulepszają moje oprogramowanie, integrując je z innym (prawdopodobnie komercyjnym) oprogramowaniem, umieszczając na nim GUI itp. W celu dostarczenia produktu który pomaga im zarobić.

To powiedziawszy, staram się używać licencji, które wymagają prawidłowej identyfikacji. Na przykład, jeśli firma ma złożyć mój kod do większego komercyjnego produktu, chcę, aby było jasne, że mój kod można uzyskać dowolnie ze mną. Ale poza tym chcę stawiać jak najmniej wymagań użytkownikom mojego kodu.

Rozumiem, że w przypadku rozwoju oprogramowania, które nie jest finansowane z dolarów podatników, bardziej odpowiednie mogą być inne licencje.

Nikt tego nie przeliterował, więc myślę, że warto powiedzieć:

Niektóre licencje typu open source (w szczególności: GPL) są „wirusowe” w tym sensie, że ilekroć kod jest używany w nowym projekcie, nowy projekt musi być licencjonowany w ten sam sposób. Ponadto kodu nie można powiązać z (pod pewnymi względami) kodem odmiennie licencjonowanym.

Jedną praktyczną konsekwencją jest:

• Jeśli zaimplementujesz nową metodę numeryczną w C, licencja nie pozwoli na wywołanie jej z tak powszechnego oprogramowania, jak MATLAB lub Mathematica

• Jeśli zaimplementujesz nowy algorytm przetwarzania obrazu, licencja nie zezwoli na tworzenie z niego wtyczki Photoshop

• i tak dalej ...

Zapobiegnie to nie tylko ponownemu wykorzystaniu w celach komercyjnych, ale także wygodnemu ponownemu wykorzystaniu przez innych pracowników naukowych (jeśli używają zamkniętego oprogramowania), a jeśli ktoś zbuduje na twoim kodzie, uniemożliwi mu to oddanie swojej pracy w „do” -jak-z-tym-z-tym-sposobem.

Jest to coś, co należy wziąć pod uwagę przed zakończeniem formułowania licencji.

Mówię to w ten sposób, ponieważ spotkałem ludzi (niezbyt dobrze zaznajomionych z licencjami typu open source), którzy nie byli tego świadomi lub nie zastanawiali się nad tym z tej perspektywy.

^{(To jest tylko osobista opinia, ale uważam, że stosowanie takich ograniczeń do pracy wywodzącej się z (finansowanych ze środków publicznych) środowisk akademickich jest niewłaściwe. Więc albo zachowuję kod, albo go rozdaję.)}

Niezależnie od tego, z jaką licencją zdecydujesz się skorzystać, pamiętaj o uważnym sprawdzeniu wszystkich umów o finansowaniu, aby upewnić się, że nie zawierają w nich klauzul, które dyktują lub ograniczają sposób licencjonowania oprogramowania.

Wiem, że w moim przypadku wiele moich projektów powstało z kilku poziomów finansowania, trochę tutaj i trochę tam, i śledzę, w jaki sposób wolno mi licencjonować moje rzeczy przez ludzi, którzy zapalają światła i działające maszyny są dość złożone.

W przypadku dużych fragmentów kodu wybieram jedną z licencji opisanych w innych odpowiedziach i zwykle LGPL. Jednak, choć nie jest to zwykle zalecane w przypadku oprogramowania , w przypadku małych samodzielnych skryptów, które mogę wysyłać do współpracowników w branży, często wybieram licencję Creative Commons . Wynika to z tego, że są one bardziej zrozumiałe dla osoby, do której wysyłam kod, co zapobiega potencjalnym problemom z nieporozumieniami. W przeszłości dobrze mi to działało.

W przeciwieństwie do większości osób udzielających odpowiedzi (pracujących w organizacjach akademickich i / lub publicznych), pracuję w sferze komercyjnej.

W przypadku moich produktów kod jest zamknięty i nadal zapewnia to znaczne korzyści biznesowe. Ale są oczywiście inne sposoby na zrobienie tego (np. Jak wykazał między innymi MySQL). Często widzę komercyjne podejście do licencji LGPL + na biblioteki. Takiej biblioteki muszę jeszcze używać w systemie komercyjnym, ale nie wykluczałbym jej (do tej pory korzystałem tylko z takich bibliotek, np. ALGLIB, na poziomie badań i rozwoju). Kontrastuje to z produktem GPL - którego mógłbym używać wewnętrznie, ale nigdy nie użyłbym go w produkcie, głównie ze względu na wirusową naturę.

Kiedy publikuję kod źródłowy (samouczki, darmowe programy itp.), Zwykle używam licencji Berkeley. Wydaje się, że jest to o wiele bardziej w duchu „wolnego” kodu, z przypisaniem, ale bez ciągów GPL i polityki. Być może właśnie dlatego (lub podobne licencje, takie jak licencja MIT) są tak popularne wśród uniwersytetów i organizacji publicznych. Kod źródłowy jest rozdawany w prawdziwym znaczeniu „darmowy” (oto kod, rób z nim, co chcesz), ale autor wciąż otrzymuje kredyt / uznanie.

To stare pytanie, ale myślę, że publiczna licencja Mozilli jest warta wspomnienia jako pośredni środek między pozwoleniami dozwolonymi (BSD, MIT) a silnymi licencjami copyleft (GPL). Kod MPL może być używany i rozpowszechniany, ale kod MPL i wszelkie jego modyfikacje muszą być dostępne. Na przykład firma może pobrać kod MPL, wprowadzić w nim własne ulepszenia i rozpowszechnić go w zastrzeżonym pakiecie oprogramowania zamkniętego, o ile udostępni zmodyfikowaną wersję oryginalnego kodu MPL. Nie są zobowiązani do wydania całego własnego kodu źródłowego, tak jak w przypadku GPL.

Dzięki licencji BSD istnieje obawa, że ​​korporacja może wziąć Twój kod i ulepszyć go bez zwracania tych wkładów tobie lub całej społeczności, pod warunkiem, że wprowadzone przez niego ulepszenia zapewniają przewagę konkurencyjną. (Odpowiedź Matta Knepleya sugeruje, że nie każdy zachowuje się w ten sposób). Z drugiej strony wiele osób może całkowicie uniknąć kodu GPL. MPL unika obu tych potencjalnych pułapek, przynajmniej w zasadzie.