Na stro­nach por­ta­lu LindekIn uka­zał sie bar­dzo dobry arty­kuł autor­stwa Marcina Maruty z kan­ce­la­rii Maruta Wachta sp.j., na temat opro­gra­mo­wa­nia open source: 

Barierą tech­no­lo­gicz­ną jest brak dostę­pu do kodu źró­dło­we­go, nie­zbęd­ne­go dla wpro­wa­dza­nia zmian i roz­wo­ju opro­gra­mo­wa­nia. Barierą praw­ną jest nato­miast bar­dzo sze­ro­ki zakres ochro­ny pro­gra­mów kom­pu­te­ro­wych, któ­ry spra­wia że jaka­kol­wiek for­ma korzy­sta­nia z pro­gra­mu, w tym jego mody­fi­ko­wa­nie, wyma­ga­ją uzy­ska­nia zgo­dy upraw­nio­ne­go. Ruch Open Source, wyrósł ze sprze­ci­wu wobec takie­go sta­nu rze­czy, sta­wia sobie za cel two­rze­nie i popu­la­ry­zo­wa­nie pro­gra­mów ?otwar­tych?, ?wol­nych?, a więc dostęp­nych wraz z kodem źró­dło­wym i udo­stęp­nia­nych na bar­dzo libe­ral­nych zasa­dach. (ź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 tyl­ko frag­ment na zachę­tę, gorą­co pole­cam lek­tu­rę całe­go tego tek­stu zanim zacznie­cie Państwo czy­tać mój. Poniżej mój komen­tarz, jaki umie­ści­łem pod powyż­szym tekstem. 

Świetny tekst, cie­szę się tak­że że padło sło­wa ​„Oprogramowanie kom­pu­te­ro­we jest przede wszyst­kim chro­nio­ne pra­wem autor­skim (nie­ste­ty). „.

Po lek­tu­rze tego tek­stu, z któ­rym zga­dzam sie w cało­ści, ciśnie mi sie na ustal kil­ka koniecz­nych, chy­ba ​„inży­nier­skich”, uzu­peł­nień. Od końca.

Prawo autor­skie to pra­wa oso­bi­ste i mająt­ko­we. Tezę o pra­cy za satys­fak­cję trak­tu­ję jako tezę tępią­cą bier­ne przy­cho­dy z licen­cji i mono­pol, któ­re moim zda­niem nisz­czą rynek i budu­ją barie­rę korzy­sta­nia z nowych tech­no­lo­gii. W moim odczu­ciu pra­wo autor­skie oso­bi­ste to sil­na ochro­na przez pla­gia­ta­mi (i lubię te ochro­nę nie tyl­ko w nauce), pra­wa mająt­ko­we mają moim zda­niem sens, gdy utwór (infor­ma­cja jaką nie­sie) sta­no­wi zara­zem czy­jeś chro­nio­ne know-how, i moim zda­niem tyl­ko wte­dy. Ideałem dla mnie jest pobra­nie pro­gra­mu za dar­mo, i gdy uznam, że jest przy­dat­ny pła­cę ​„ludziom” wyłącz­nie za wyko­na­ną pra­cę, np. pra­ce nad dal­szym roz­wo­jem tego pro­duk­tu, pra­cę typu help desk itp.. Ale tu ostroż­nie, bo pra­cę nad dosto­so­wa­niem do moich potrzeb moż­na nie raz uznać za roz­bu­do­wę mecha­ni­zmu reali­zo­wa­nej logi­ki, i tu może sie poja­wić kwe­stia moje­go know-how (nale­ży wydzie­lić w umo­wie tez część projektu).

Prawo autor­skie zosta­ło w moich oczach w IT wyna­tu­rzo­ne, ale nie dla­te­go że jest sto­so­wa­ne, a dla­te­go nie są two­rzo­ne pośred­nie pro­jek­ty mecha­ni­zmów (abs­trak­cja kodu). W efek­cie chro­nio­ne są milio­ny linii kodu jako ​„tekst”, co prak­tycz­nie blo­ku­je roz­wój tego kodu poza oso­bą jego auto­ra. Gdyby przed kodem powsta­wał pro­jekt (np. takie jakie zna­my z doku­men­ta­cji paten­tów), kod pro­gra­mu był­by utwo­rem zależ­nym z wszyst­ki­mi wada­mi i zale­ta­mi, tu: open sour­ce­’o­wy pro­jekt mecha­ni­zmu (logi­ka i archi­tek­tu­ra sys­te­mu) pozwa­la na powsta­wa­nie dowol­nej licz­by imple­men­ta­cji, czy­li mamy zara­zem i kon­ku­ren­cję i ochro­nę dorob­ku ludzi. I pro­jek­ty takie powsta­ją, ale twór­cy opro­gra­mo­wa­nia open sour­ce w zasa­dzie nigdy tego nie robią!

Drugi poważ­ny pro­blem to teza, że ​„mając kod wiem co mam”. Niestety w latach 70-tych być może. Ale dzi­siej­sze apli­ka­cje to milio­ny linii kodu i ich audyt w akcep­to­wal­nym cza­sie jest real­nie nie­moż­li­wy. Odkrycia bugów ​„post fac­tum” w sys­te­mach open sour­ce prze­czą tezie, że ​„otwar­ty kod zna­czy bez­piecz­ny, bo każ­dy go może audy­to­wać i znaj­do­wać błę­dy”. To (te audy­ty) się nie dzie­je, dzie­ją za to się skut­ki błę­dów tego kodu. Co może­my zro­bić? Zacząć trak­to­wać opro­gra­mo­wa­nie (okre­ślo­ne modu­ły czy kom­po­nen­ty) jak czar­ne skrzyn­ki doku­men­to­wa­ne tyl­ko na pozio­mie mecha­ni­zmu jaki reali­zu­ją (patrz doku­men­ta­cja paten­tów: opi­su­ją mecha­nizm a nie imple­men­ta­cję). Wtedy: 1. pra­cu­je­my nie z milio­na­mi linii kodu a z kil­ku­na­sto­ma, góra kil­ku­dzie­się­cio­ma, stro­na­mi tech­nicz­ne­go opi­su mecha­ni­zmu dzia­ła­nia i archi­tek­tu­ry pomy­słu (abs­trak­cja sys­te­mu). 2. zosta­wia­my inży­nie­rom peł­ną swo­bo­dę imple­men­ta­cji, czy­li pozwa­la­my kon­ku­ro­wać jako­ścią, dobo­rem tech­no­lo­gii, mówiąc ina­czej otwie­ra­my dro­gę do postę­pu tech­no­lo­gii, praw­no­au­tor­ska ​„ochro­na kodu” beto­nu­je zawar­ty w nim dług tech­no­lo­gicz­ny: nie raz dużo lep­szym roz­wią­za­niem jest wyko­na­nie nowej imple­men­ta­cji dane­go mecha­ni­zmu, niż roz­bu­do­wa czy napra­wa sta­rej implementacji.

Krótkie i otwar­te opra­co­wa­nie oba­la­ją­ce tezy, że kodu nie da się doku­men­to­wać na wyż­szym, abs­trak­cyj­nym pozio­mie (frag­ment):

Programowanie nie pole­ga wyłącz­nie na two­rze­niu opro­gra­mo­wa­nia – pro­gra­mo­wa­nie pole­ga na pro­jek­to­wa­niu opro­gra­mo­wa­nia. Myślenie o kodzie źró­dło­wym jako o pro­jek­cie nie ozna­cza, że nie nale­ży pro­jek­to­wać, tyl­ko kodo­wać. Dobra archi­tek­tu­ra i abs­trak­cje są nie­zbęd­ne. Podobnie, archi­tek­tu­ra nie jest wyłącz­nie o pro­jek­to­wa­niu opro­gra­mo­wa­nia, archi­tek­tu­ra jest o kon­stru­owa­niu opro­gra­mo­wa­nia. Inżynierowie opro­gra­mo­wa­nia coraz czę­ściej potrze­bu­ją języ­ków pro­gra­mo­wa­nia wyso­kie­go pozio­mu, któ­re są bliż­sze temu, jak inży­nie­ro­wie opro­gra­mo­wa­nia myślą i pro­jek­tu­ją opro­gra­mo­wa­nie, a tak­że języ­ków mode­lo­wa­nia, któ­re są bliż­sze temu, jak szcze­gó­ło­we pro­jek­ty mogą być reali­zo­wa­ne w kodzie. (Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3?5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049)