Dlaczego NIE otwierać kodu non-profit typu open source? [Zamknięte]

Jestem wielkim fanem kodu open source. Myślę, że rozumiem większość zalet korzystania z oprogramowania typu open source. Jestem studentem nauk ścisłych i muszę pracować z dość zaskakującą ilością oprogramowania i kodu, które nie są oprogramowaniem typu open source (albo jest zastrzeżone, albo nie jest publiczne). Naprawdę nie widzę dobrego powodu i widzę, że kod i ludzie, którzy go używają, z pewnością skorzystaliby na upublicznieniu (jeśli nic innego, w nauce ważne jest, aby w razie potrzeby można było powielić wyniki, i jest to o wiele trudniejsze, jeśli inni nie mają dostępu do Twojego kodu).

Zanim wyjdę i zacznę prozelityzm, chcę wiedzieć: czy istnieją jakieś dobre argumenty za tym, aby nie publikować publicznie kodu organizacji non-profit i mieć licencję zgodną z OSI?

(Zdaję sobie sprawę, że wokół jest kilka podobnych pytań , ale większość skupia się na sytuacjach, w których kod służy przede wszystkim do zarabiania pieniędzy, a odpowiedzi nie były zbyt istotne).

Wyjaśnienie: „ Nienastawione na zysk” włączam motywy związane z zyskiem, takie jak rozpoznawalność marki firmy macierzystej i oczekiwania zysku inwestorów. Innymi słowy, pytanie dotyczy tylko oprogramowania, dla którego nie ma ŻADNEGO motywu zysku związanego z oprogramowaniem.

Musisz wziąć pod uwagę, że otwarty dostęp do kodu może wymagać dodatkowego wysiłku.

Jako przykład, w tym wpisie na blogu inżynier Sun / Oracle opisuje wysiłki, jakie musieli podjąć, gdy open source pozyskiwał swój kod: Open Source czy Dirty Laundry?

Gdy przygotowujemy się do nurkowania w świecie open source, jednym z wielu działań, które mają miejsce, jest przygotowanie kodu do otwartego dostępu. Jest kilka oczywistych rzeczy, które należy zrobić. Na przykład nasz kod źródłowy zawiera mieszankę kodu, który napisaliśmy, oraz kodu, na który mamy licencję od innych. Będziemy musieli wyodrębnić ten ostatni i open source tylko odpowiednie fragmenty kodu.

Kolejnym działaniem przygotowawczym jest „szorowanie” kodu zastrzeżonych informacji, wzmianki o konkretnych klientach, programistach, technologiach itp. Jest to nieco mniej oczywiste, ale rozważ następujący przykład:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Chociaż wszystkie powyższe kwestie mogą być prawdziwe, prawdopodobnie mamy jakiś związek z Intertrode Tech, a umieszczanie takich komentarzy w kodzie może w jakiś sposób zaszkodzić naszej działalności i dlatego należy ją usunąć. Prawdopodobnie nie powinien był tam być, ale teraz nadszedł czas, aby go wyjąć.

Inną częścią działania „szorowania” jest usuwanie wulgaryzmów i innych „niepożądanych” słów ...

Zauważ, że wszystkie powyższe zmiany musiały zostać wprowadzone w kodzie, który został uznany za całkowicie OK jako zamknięte źródło - co sprawia, że ​​jest to dodatkowy wysiłek .

Bezpieczeństwo.

Załóżmy na przykład, że budujesz framework internetowy i sam go używasz.

Jako projekt non-profit nie miałeś czasu poświęcić na sprawdzenie każdego fragmentu kodu pod kątem podatności na taki lub inny atak:

• CSRF
• XSS
• Wstrzyknięcie SQL
• Utrwalanie sesji
• Korzystanie z błędnych bibliotek stron trzecich, a nawet języków

Teraz, mając projekt open source, pozwalasz przyjaznym oczom wnieść swój wkład, ale również pozwalasz złośliwym oczom na pełny wgląd w twoją pracę, a jeśli znajdą serwer, na którym działa twój kod, wyeliminowałeś możliwość ukrywania swojego niedoskonałości w zaciemnieniu.

Oczywiście może to nie dotyczyć rodzaju oprogramowania, nad którym pracujesz; i jak zawsze niejasność nie usprawiedliwia lenistwa w bezpieczeństwie.

Jednak, tak jak znalazłem na kilku poziomach, przez które przeszedłem w grze Stripe capture the flag game , wiedząc, że kod jest jednym z najłatwiejszych sposobów na znalezienie luk (i czasami może to być jedyny sposób).

Dobrym powodem, aby nie otwierać źródła, jest to, że niektóre z Twoich źródeł mogą być chronione prawami autorskimi. Jak często nie przeszukujesz sieci w celu szybkiego rozwiązania problemu i po prostu weź znaleziony fragment kodu?

Cóż, mogą być chronione prawem autorskim i nie wiem, czy autor chciałby znaleźć licencję na swój kod na innej licencji.

Musisz ostrożnie wybierać licencję, aby uniknąć potencjalnych problemów z odpowiedzialnością.

Prawnik może być lepszą osobą, z którą można porozmawiać na ten temat, ale ogólną ideą jest to, co się stanie, jeśli ktoś użyje (lub niewłaściwie użyje) aplikacji i spowoduje to pewne szkody? Jesteś odpowiedzialny? Oczywiście będzie to zależeć od rodzaju oprogramowania, które piszesz, ale zawsze musisz uważać na to, co mówi licencja na temat twojej odpowiedzialności. To może być trudna rzecz, aby zrobić to dobrze, więc może być łatwiej po prostu nie zwolnić kodu źródłowego.

Ostrzeżenie: nie jestem prawnikiem .

Cóż, jeśli jest to organizacja non-profit, a jej własność intelektualna jest silnie związana z kodem oprogramowania, niektórzy mogą chcieć zabezpieczyć go przed komercyjnym ponownym wykorzystaniem, a nawet nadużyciem w celu stworzenia kopii oprogramowania.

Niektóre inne powody - które prawdopodobnie są głęboko zakorzenione w pierwszym - są takie, że w twoim przypadku wiele wysokiej klasy badań odbywa się przy prywatnym finansowaniu i zwykle inwestorzy chcą zobaczyć ROI. Jak dotąd nie wszyscy aktorzy branży oprogramowania (lub nowicjusze) zostali w pełni przekonani o opłacalności modelu open source (najprawdopodobniej z powodu braku wiedzy i zrozumienia licencjonowania lub po prostu z obawy, że licencjonowanie nie zapobiegnie złośliwym używa i kopiuje).

Dodatkowo, firmy te nie chcą zostać pozwane przez tych, którzy próbowali zarobić na swoich plecach, a licencjonowanie jest również postrzegane jako zabezpieczenie w tym względzie, bez uzasadnionego powodu.

Może się tak nie wydawać, ale być może organizacje non-profit są opłacalne dla ich założycieli lub inwestorów. Korzyści po prostu nie są bezpośrednie. Są więc bardzo zainteresowani silnymi punktami NFP i brakiem możliwości bicia ich przez konkurencję (nawet jeśli często nie myślisz o „konkurentach” na rynku non-profit) i chcą zachować swoje Własność intelektualna, nawet jeśli kosztem nie jest uzyskanie więcej darmowych gałek ocznych, aby przejrzeć kod, aby znaleźć problemy i poprawić go na wczesnym etapie.

Pamiętaj również, że prawa autorskie różnią się w poszczególnych krajach. Wiele krajów europejskich uważa na przykład amerykańskie przepisy dotyczące praw autorskich i amerykański system patentowy za raczej głupie, więc trudno jest zrzucić kulturowe pochodzenie i wagę.

Po prostu moje 2 centy na ten temat.

(Dużo współpracowałem z uniwersytetami, a ostatnio w bioinformatyce i opiece zdrowotnej ... To powtarzające się pytanie dla mnie i moich kolegów :))

Istnieją co najmniej dwa różne rodzaje otwartego oprogramowania.

Jeśli twoje podejście jest „tutaj jest coś użytecznego, skończyłem z tym” (a to okazuje się być trafne), to ma to niewielką wadę.

Z drugiej strony, jeśli twoja postawa brzmi: „Jestem naprawdę podekscytowana i chcę, aby niektórzy prawdziwi użytkownicy pomogli w rozwoju w przyszłości”, pomyśl bardzo ostrożnie. Będziesz musiał poświęcić czas na wspieranie użytkowników, z których wielu nie ma pojęcia. Będziesz musiał rozważyć sprzeczne żądania dotyczące funkcji i ulepszeń. Coraz trudniej będzie wprowadzać zmiany, aby zachować kompatybilność wsteczną.