Az Ortur lézervágó gyártója megnyitná a firmware-e forráskódját, miután felhívták a figyelmét a GPL sértésre

FSF/GNU/GPL

A régi nóta: az Ortur a GPL licencű grbl-t használja lézervágója firmware-éhez. Egy ügyfél kérte a firmware forráskódját a gyártótól több alkalommal, de elhajtották azzal, hogy a firmware "üzleti titok". Nem hagyták annyiban, megszületett a fenti videó. A nyilvánosság hatására az Ortur meggondolta magát és megnyitná a firmware-e forráskódját. Jelenleg tanácsokat kér a közösségtől, hogy hogyan tudná ezt minél hatékonyabban megtenni.

( marcabru | 2022. 07. 19., k – 13:46 )

Szerkesztve: 2022. 07. 19., k – 13:54

van egy termek, ahol a szoftver akar a termek ertekenek felet is kepezheti. ezek utan annyira se kepesek, hogy kovessek az ingyen talalt kod licenszet. pofa leszakad.  

az ilyeneknek a pokolban csiklandozhatnak az erzekenyebb testreszeiket lezervagoval... 

( locsemege v | 2022. 07. 19., k – 22:50 )

Ez hogyan van? Ha használok GPL kódot, például egy libet, akkor meg kell nyitnom az általam írt kód forrását is? Vagy ha érintetlenül hagyom az eredeti libet, akkor nem, csak ha változtatok GPL kódon, akkor a változásokat publikálnom kell?

A kód megnyitásának etikusnak kell lennie, vagy lehet bfuszkált is? :) (Gondolom, nem, de mi van, ha csak trágya módon ír valaki kódot?)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem vagyok jogász, de két GPL-szerű licensz van, a GPL és az LGPL. A GPL esetén mindennek meg kell nyitni a kódját, ami linkel hozzá (és ebbe a runtime linkelést is beleértik, tehát elvileg a kernelmodulra is vonatkozik, mag a shared libet használó programra is). Az LGPL esetén ha csak linkelsz hozzá, akkor nem kell megnyitni. Pl. a glibc az LGPL, nem kell minden C-ben írt program forrását megnyitni. GNU-ék akkor javasolják az LGPL használatát, ha úgy gondolod, hogy azt a libet inkább nem használná valaki, minthogy emiatt nyissa meg a kódját (pl. inkább MSVC-vel fordítana csak windowsra, és nem csinálna linuxos binárist, mint hogy megnyissa a kódot, ha GPL-es lenne a libc), és ha van egy teljesen új funkcionalitású libed, akkor arra javasolják a GPL-t.

Azt nem tudom, hogy mi van, ha obfuszkálod a kódod, de biztos volt már rá precedens. Szerk.: megnéztem, a GPL definiálja a forrást, az a forrásnak az a változata, amit te használsz, ha módosítani kell ("the preferred form for making modifications to the work"); szóval obfuszkálás nem okés, szarul kódolni viszont megengedett.

Kell csinálni a GPL kód és a kódom közé egy LGPL licencű wrapper réteget, s akkor nem kell megnyitnom a kódomat, ha jól értem, csak a wrappert.

A kernel GPLv2. Ha egy syscall hívásom van, akkor máris ki kell nyitnom a forrásomat?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem ha csak linkeled a kódot, akkor nem kell kinyitni a forrást. Csak akkor, ha a kódot átemelted a kódodba, vagy megváltoztatva használod.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A témát itt elég szépen kifejtik, röviden nem:

https://opensource.stackexchange.com/questions/10223/should-i-publish-e…

The linux kernel has a couple of exceptions from GPLv2. Namely the exception to not treat a syscall to the kernel as linking and the exception to allow non-GPL code to link to kernel-related services exposed via libc..

Igen, de az LGLP wrapper nem linkelhet a GPL kódhoz, mert akkor nem lehet LGPL, hanem pl system() hívásokkal kell rángatnia. A kernel syscall-okra van valami kikötés, hogy az nem linkelés, különben nem kockáztatnák meg sokan, hogy Linuxra írjanak commercial alkalmazást: https://www.kernel.org/doc/html/v4.18/process/license-rules.html .

Nekem csak az nem világos, hogy miért ilyen fontos kifundálni, hogy hogy lehet kijátszani a GPL-t. Van egy csapat ember, megegyeztek, hogy kódot adnak kódért, ha használni akarod, neked is kódot kell érte adnod. Ha nem tetszik vehetsz helyette másikat, amiért nem kell kódot adni, csak zsozsót. Vagy kereshetsz olyat, amiért nem kell semmit adni, mert az illető csak azért írta, hogy megmutassa, hogy tud olyat (BSD).

Egyrészt embedded hardware-re ipari környezetben nincs, vagy csak nagyon korlátozottan Windows CE, másrészt annak minősége vitatható, harmadrészt egy értékes műszer software megoldásait, évtizedes távlatban kialakult know-how-ját nem igazán adnád a konkurenciának.

Nem a GPL kijátszása a cél, de szerintem nincs mindenféle problémára mindenféle licencű alternatíva. Grafikus megjelenítésben a X.org-ot megkerülhetetlennek gondolom. GUI fejlesztésre talán a Python jó választás lenne. Kernel, glibc, shell megkerülhetetlenek. Ha valami csilingelést le kell játszani, mert hiba történt, máris ott a pipewire, wireplumber. A systemd hasonlóképp kikerülhetetlen. Nincs baj, ha ezek licencelése olyan, hogy lehet zárt kódot használni, de ha nem lehet, akkor matt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem nincs matt, ezeknek a nagy részét használhatod (nem GPL, ill. nem kell hozzá linkelni). De ha nem így lenne, akkor azt a "matt"-ot igazából úgy hívnák, hogy aki megcsinálta ezt a sok infrastruktúrát neked, az a műszered source-át kéri cserébe. Ha úgy gondolod, hogy nem érnek annyit, írj sajátot (pont ezért javasolja az FSF az új funkcionalitást megvalósító - tehát nem valami meglevővel versenybe szálló - libekhez a GPL-t, hogy kelljen valamit adni cserébe).

Az attól függ, hogy publikálod-e. Ha igen, akkor jól érted, ki kell nyitnod a kódod GPL alatt, hogy a közösség visszakapja, amit építettél rá. Akkor is érvényes ez, ha változtattál rajta, akkor is, ha változatlan libnek használtad az eredeti GPL kódot. Ha ez zavar (sok céget zavar, a MS is ezért nem nyúl hozzá GPL-hez szívesen), építs BSD, MIT, Apache, stb. licences kódra, ott nem kell ilyennel foglalkozni. Továbbá igen, ha kód megnyitása nem lehet obfuszkált a GPL szerint.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez a helyes válasz egyébként. Ha saját terméket fejlesztesz az első hogy csinálsz egy OS clearing process-t, mely szabványos folyamat segítségével megvizsgálod hogy egy használni tervezett könyvtárnak mi a licence-e, és csak akkor lehet használni, ha ezt kifejezetten engedélyezik. Könnyítés szokott lenni, hogy valamilyen licence-eket kapásból engedélyeznek (tipikus BSD, Apache, stb.) Fontos, hogy ettől függetlenül a release során lehet hogy még plusz licence fájlokat is bele kell rakni a csomagba, erre is figyelni kell.

Azért kérdezem, mert lehet, hogy a későbbiekben embedded Linux alapú lenne a műszerünk, és nagyon sok munka, know-how van benne ahhoz, hogy teljességgel kizártnak tartom azt, hogy a cég meg akarná nyitni a forrását. A jogsértést is kizártnak tartom. Már csak az a kérdés, egyáltalán lehet-e megfelelő licencű környezetet találni a nyílt forrású ökoszisztémában ahhoz, hogy zárt kódot lehessen fejleszteni. Például mi van akkor, ha Python kódot szeretnének írni a kollégák? Nem néztem meg a Python licencét.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Meg fog kelleni nézni. Ugyanúgy, ahogy a zárt forrású eszközeid licenszét is meg kell nézni, abban is lehet valami kellemetlen kikötés. Hogy nem lehetetlen zárt forráskódú cuccot fejleszteni, az szinte biztos, mert elég sokan csinálják, és legalább az ellenszenvesebbeket valaki csak felnyomta volna, ha van miért.

 és legalább az ellenszenvesebbeket valaki csak felnyomta volna, ha van miért.

Ezt ugye akkor lehet megtenni, ha nyilvanvalo, hogy mit hasznalnak, mert lathato helyen van, pl itt a soros porton valaszolgat a felhasznalt opensource program. De azert lehet, hogy van, ahol nehezebb kihamozni (firmware-t kidumpolni egy beagyazott eszkoz memoriajabol, binarisban stringeket keresgelni), hogy pontosan mit hasznaltak fel, nyilvan nem lehetetlen, ha meg van valami belsos szivarogtatas, akkor foleg. 

Elég sok eszközhöz kell firmware update, abban lehet sztringeket keresgélni. Nem mondom, hogy könnyű, de nyilván van, akinek megéri a 15 perc hírnévért. Vagy csak csinált már valamit, és dühös rájuk (pl. ócska a termék, nem lehet kipasszírozni belőlük a garanciát, stb.).

Ha csak a cég használja, akinek írod, akkor az még nem publikáció, az még mindig a saját felhasználásomra írom kategória. Akkor nem kell kinyitnotok semmit, csak használni, saját magatoknak úgy gányoltok össze bármit, ami jólesik, abba nem szólhat bele senki. Ez a licenckérdés akkor jön elő, ha elkezditek publikálni, árulni, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Akkor az viszont megnyitási kötelezettséggel fog járni, ha áruljátok is. Mindenképp konzultáljatok olyan ügyvéddel, aki erre a szoftverlicences-szerzői jogi kérdésekre van rászakosodva.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Gondolom, hogy így lesz. A folyamat elején járunk. Jelenleg Windows CE van, de ez az embedded PC elavult, az új hardware-ekre pedig elsősorban linuxos támogatás van. Nekem tetszik, mert elfogult vagyok, a software-es kollégákban is van nyitottság, úgy vannak vele, tanulni jó, növeli az értéküket, ha újabb dologhoz fognak érteni. Már nem az eladási folyamat elején járunk, hanem a platformváltás folyományaként a software jogok, s efféle problémák elején. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE