Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source:
Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów ?otwartych?, ?wolnych?, a więc dostępnych wraz z kodem źródłowym i udostępnianych na bardzo liberalnych zasadach. (źr. https://www.linkedin.com/pulse/open-source-troch%C4%99-d%C5%82u%C5%BCsza-analiza-cz%C4%99%C5%9B%C4%87-pierwsza-marcin-maruta/?trk=eml-email_series_follow_newsletter_01-hero-2-image_link&midToken=AQGclyvMpy8duA&fromEmail=fromEmail&ut=1_MX1Tf6F-W9I1).
Powyższe to tylko fragment na zachętę, gorąco polecam lekturę całego tego tekstu zanim zaczniecie Państwo czytać mój. Poniżej mój komentarz, jaki umieściłem pod powyższym tekstem.
Świetny tekst, cieszę się także że padło słowa „Oprogramowanie komputerowe jest przede wszystkim chronione prawem autorskim (niestety). „.
Po lekturze tego tekstu, z którym zgadzam sie w całości, ciśnie mi sie na ustal kilka koniecznych, chyba „inżynierskich”, uzupełnień. Od końca.
Prawo autorskie to prawa osobiste i majątkowe. Tezę o pracy za satysfakcję traktuję jako tezę tępiącą bierne przychody z licencji i monopol, które moim zdaniem niszczą rynek i budują barierę korzystania z nowych technologii. W moim odczuciu prawo autorskie osobiste to silna ochrona przez plagiatami (i lubię te ochronę nie tylko w nauce), prawa majątkowe mają moim zdaniem sens, gdy utwór (informacja jaką niesie) stanowi zarazem czyjeś chronione know-how, i moim zdaniem tylko wtedy. Ideałem dla mnie jest pobranie programu za darmo, i gdy uznam, że jest przydatny płacę „ludziom” wyłącznie za wykonaną pracę, np. prace nad dalszym rozwojem tego produktu, pracę typu help desk itp.. Ale tu ostrożnie, bo pracę nad dostosowaniem do moich potrzeb można nie raz uznać za rozbudowę mechanizmu realizowanej logiki, i tu może sie pojawić kwestia mojego know-how (należy wydzielić w umowie tez część projektu).
Prawo autorskie zostało w moich oczach w IT wynaturzone, ale nie dlatego że jest stosowane, a dlatego nie są tworzone pośrednie projekty mechanizmów (abstrakcja kodu). W efekcie chronione są miliony linii kodu jako „tekst”, co praktycznie blokuje rozwój tego kodu poza osobą jego autora. Gdyby przed kodem powstawał projekt (np. takie jakie znamy z dokumentacji patentów), kod programu byłby utworem zależnym z wszystkimi wadami i zaletami, tu: open source’owy projekt mechanizmu (logika i architektura systemu) pozwala na powstawanie dowolnej liczby implementacji, czyli mamy zarazem i konkurencję i ochronę dorobku ludzi. I projekty takie powstają, ale twórcy oprogramowania open source w zasadzie nigdy tego nie robią!
Drugi poważny problem to teza, że „mając kod wiem co mam”. Niestety w latach 70-tych być może. Ale dzisiejsze aplikacje to miliony linii kodu i ich audyt w akceptowalnym czasie jest realnie niemożliwy. Odkrycia bugów „post factum” w systemach open source przeczą tezie, że „otwarty kod znaczy bezpieczny, bo każdy go może audytować i znajdować błędy”. To (te audyty) się nie dzieje, dzieją za to się skutki błędów tego kodu. Co możemy zrobić? Zacząć traktować oprogramowanie (określone moduły czy komponenty) jak czarne skrzynki dokumentowane tylko na poziomie mechanizmu jaki realizują (patrz dokumentacja patentów: opisują mechanizm a nie implementację). Wtedy: 1. pracujemy nie z milionami linii kodu a z kilkunastoma, góra kilkudziesięcioma, stronami technicznego opisu mechanizmu działania i architektury pomysłu (abstrakcja systemu). 2. zostawiamy inżynierom pełną swobodę implementacji, czyli pozwalamy konkurować jakością, doborem technologii, mówiąc inaczej otwieramy drogę do postępu technologii, prawnoautorska „ochrona kodu” betonuje zawarty w nim dług technologiczny: nie raz dużo lepszym rozwiązaniem jest wykonanie nowej implementacji danego mechanizmu, niż rozbudowa czy naprawa starej implementacji.
Krótkie i otwarte opracowanie obalające tezy, że kodu nie da się dokumentować na wyższym, abstrakcyjnym poziomie (fragment):
Programowanie nie polega wyłącznie na tworzeniu oprogramowania – programowanie polega na projektowaniu oprogramowania. Myślenie o kodzie źródłowym jako o projekcie nie oznacza, że nie należy projektować, tylko kodować. Dobra architektura i abstrakcje są niezbędne. Podobnie, architektura nie jest wyłącznie o projektowaniu oprogramowania, architektura jest o konstruowaniu oprogramowania. Inżynierowie oprogramowania coraz częściej potrzebują języków programowania wysokiego poziomu, które są bliższe temu, jak inżynierowie oprogramowania myślą i projektują oprogramowanie, a także języków modelowania, które są bliższe temu, jak szczegółowe projekty mogą być realizowane w kodzie. (Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3?5. https://doi.org/10.1109/MS.2019.2959049)
