Red Hat: "A kód egyszerű újraépítése hozzáadott érték vagy anélkül, hogy bármilyen módon megváltoztatná azt, valódi fenyegetést jelent a nyílt forráskódú vállalatok számára mindenhol"

A Red Hat részéről Mike McGrath, a vállalat egyik alelnöke válaszolt a feléjük özönlő kritikákra:

We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL.

[...]

Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.

Részletek a blogbejegyzésben.

Hozzászólások

Ahogy megírtam nemrég, nem az open source nyerte meg a világot, hanem a corporate controlled open source. Már ez sem az open source-ról szó - még akkor sem ha most éppen az a járulékos veszteség - hanem a corporate controlról, és ezt be is vallják: "Ha nem adtok több pénzt, a végén még elveszik a corporate control amin annyi évig dolgoztunk, és mehetünk vissza a balettba ugrálni hálószobahackernek!" - értem, ez a jó hír, és akkor mi a rossz hír, tisztelt McGrath... úr?

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Azért nem teljesen igaz, hogy nem tudnak semmit tenni. Meg tudják nehezíteni a forráskódhoz való hozzáférést, a GPL nem határozza meg, hogy hogyan kell elérhetővé tenni a kódot. Elvileg az is megfelel a GPL követelményeinek, hogy csak kérésre adják oda a kódot azoknak, akik használják a terméket. Innentől ha akarják meg tudják csinálni, hogy ne lehessen automatikusan (vagy csak nagyon nehezen) kívülről újrabuildelni a teljes kódbázist.

Ha pedig ezt "sikeresen" meglépik, akkor ez például szolgálhat más projekteknek, hogy hogy lehet ellehetetleníteni a forráskódhoz való hozzáférést.

a GPL nem határozza meg, hogy hogyan kell elérhetővé tenni a kódot

Kereteket azért ad hozzá, tehát nem lehet akárhogy; lásd GPLv3 6. szakasza, azon belül is pl. a d) pont. (A 6.szakasz címe "Conveying Non-Source Forms", ehhez képest leírja, hogyan lehet/kell a nemszósz mellé tálalni a szószt.)

hogy ne lehessen automatikusan (vagy csak nagyon nehezen) kívülről újrabuildelni a teljes kódbázist.

Nem tudom, itt mit értesz "automatikusan" alatt, de legalábbis az egyszerű újrafordíthatóság az követelmény:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

Ezzel együtt én sem kételkedem benne, hogy igyekeznek kijátszani a szabályokat; mintha már most is azt tennék. (És még az is lehet, hogy egy bíróság mindezt majd elfogadhatónak találja.)

Nem tudom, itt mit értesz "automatikusan" alatt, de legalábbis az egyszerű újrafordíthatóság az követelmény:

Azt értem ez alatt, hogy jelenleg gyakorlatilag egy publikus repóban érhető el a teljes RHEL forráskód, ami alapján minden commit után le lehet buildelni minden package-et automatikusan, ezáltal minden RHEL verzió előállítható automatikusan. Ezt el lehet lehetetleníteni azzal, ha csak kérésre teszik elérhetővé és olyan módon, hogy mindenképp manuális lépés kelljen a letöltéshez (pl. CAPTCHA).

A GPL alapvetően arról szól, hogy egy termék felhasználójának legyen joga az adott termék forráskódjához hozzáférni, és ha módosítani akar rajta, akkor ezt egyszerűen meg tudja tenni. Igazából ez nem ugyanaz, mint amit a Rocky/Alma linux csinál, hogy automatikusan minden módosítást lebuildelnek és elérhetővé teszik az így előállított binárisokat. Ugyanis ők sem használni nem akarják, sem módosítani azt. Szóval igen, tartok tőle, hogy elég kétesélyes lenne, ha megtámadnák ezt a gyakorlatot bíróságon, bár kérdés, hogy melyik eredmény a rosszabb, ugyanis az sem jó, ha a RedHat és más cégek munkája fenntarthatatlanná válik, mert a linux ecosystem fejlődése leginkább tényleg rajtuk múlik.

Azt értem, hogy nem kell mindenkinek elérhetővé tenni a forrást (viszont akinek binárist adtak, annak igen). Hogy ez a CAPTCHÁ-s dolog hogy férne vagy nem férne bele, azt nem tudom. Simán beleférhet, bár én azért titokban bokán rúgnám érte őket. :D

Ugyanis ők sem használni nem akarják, sem módosítani azt.

Ezt nem értem, ez miért szempont? A továbbadásnak nem feltétele, hogy használd vagy módosítsd.

Nem válik fenntarthatatlanná, eddig sem vált azzá. Most épp az extraprofitjukért sírnak, amit a kinyírt CentOS felhasználóitól akarnak bezsebelni. Mert azt gondolják, hogy minden egyes korábbi CentOS felhasználó fizetőképes kereslet a RHEL-ra.

Mielőtt véletlenül megsajnálnád őket, nézz majd utána, hogy a CentOS kinyírása előtt, CentOS=RHEL időkben, amikor ők terjesztették a saját Linuxukat módosítás nélkül, mennyi profitot termelt a Red Hat. Profitot! Nem veszteséget, nem nullszaldósan kijövést, hanem profitot. Egyszerűen arról van szó, hogy az IBM többet akar kisajtolni a cégből, mint amit a tisztességes üzleti modell lehetővé tett. Ezért most átkapcsolnak egy tisztességtelen üzleti modellre, akár a GPL megsértésével. Fenntarthatatlannak a legalább nullszaldós vagy veszteséges ágazatokat nevezzük.

Ha nem akarod hogy egy versenytárs a termékeid forrására építsen, ne legyél az Open Source bizniszben. Ha meg eddig abban voltál, és megváltoztatod az álláspontod, akkor ne lepődj meg, hogy akik eddig az Open Source miatt használtak, elküldenek a picsába.

De ez mind csak szájtépés, mert ahogy írtam az egész Open Source csak járulékos veszteség ebben a csatában - az ok hasonló, ami miatt az Oracle szétcseszte a Sun Microsystemst és a komplett Java-t - a cél az volt, hogy valahogy pénzt szedjen érte a Google-től az Android miatt. Következmény - épeszű ember már nem épít megoldást Java-ra mert a jogtulajdonos nem megbízható. Itt is ugyanez van és lesz. Az IBM pénzt akar szedni az Oracle-től, ha már megvette a Red Hatet. Ez a cél. Minden más csak járulékos veszteség. Nincs "némi igazság", csak vállalati kapzsiság és profitnövelési igény. Minden más csak porhintés.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A kérdés csak, hogy ez kit érdekel. Senkit. Abban az értelemben, hogy én még emlékszem azokra az évekre, amikor a Java volt a "cool" nyelv, amiben mindenki írni akart valamit. Ma meg a legtöbben csak odébb akarják lökni egy bottal. A "modern" PHP-k is sokkal jobbak mint a 20 évvel ezelőttiek, amiben akkor mindent írtak, csak ez kb. senkit sem érdekel azokat leszámítva, akik elég szerencsétlenek hozzá, hogy legyen benne valami legacy kódjuk. (De mondhatnám akár a Pascal-t is, mert nekem meg az a hobbim, a mai Pascal fordítók ezerszer jobbak mint bármi korábban, és vannak benne írt projektek bőven, de a nyilvánosság megragad a "LOL, paszkál" szintjén. A minta ugyanaz.)

Amit mondani akarok - a szétcseszés ezekben az esetekben nem technológiai, hanem a technológia nagy nyilvánosság előtti megítélésének szétcseszése.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A Java nem cool meg nem fancy meg shiny. A Java egy igásló, amiben nem kell fancy dolgokat csinálni, hanem olyanokat, amelyek megbízhatóan működnek. 

Lehet, hogy számodra csak az számít valaki által érdekelt nyelvnek, ami fancy meg shiny, de baromira nincs így. Javaban készül rengeteg dolog, olyanok, amikről nem is tudsz, mert belső szoftverek.

Én pont azt szeretem a Javaban, hogy boring és nem shiny.

 A Java egy igásló, amiben nem kell fancy dolgokat csinálni

+1

nálunk megpróbálkoztak pár nodejs-es mágiával az utóbbi években, akiknek tetszik a JS, de a vége mindig az lett, hogy a spring bootban defaultból van sokkal kulturáltabb logging, bármi monitoringot bekapcsolni ~pillanatok (http request logging; sql logging; stb), mindenre van kész eszköz (random db - kész; prometheus integráció - kész; stb), így visszatértünk oda, ahol ~4-5 éve is voltunk: új projektet leginkább spring boot-ban, mert az just works

Igazból ez ma már igaz a javascriptre, a pythonra, dotnetre, golangra is (és még biztosan másokra is). A legnagyobb különbség, hogy milyen csapatod van, ők mihez értenek, illetve, hogy milyen tooling van kiépítve már. Nyilván ha már van egy "bejáratott" tech stack, amihez vannak hozzáértő fejlesztők, akkor sok értelme nincs másikra átváltani. De hidd el, hogy máshol ugyenez le tud játszódni fordítva is akár, mert ott mondjuk a javascript az, ami "just works".

Az JAVA-nak igenis az Oracle a baja. Ilyen licenc változás egyik napról a másikra azt okozza, hogy aki gondolkodik Oracle-től csak menekül: https://www.oracle.com/java/technologies/java-se-subscription-faq.html és a probélma: https://houseofbrick.com/blog/oracle-java-pricing/

 

Lehet, hogy a nyelv boring, de az Oracle mögötte az elmúlt években izgalmassá tette a licenc kérdéseket.

The numbers will get more staggering with larger companies. Even Oracle’s Pricing Example shows the large company (28,000 employees and agents) will have an annual subscription bill of $2,268,000!

 a mai Pascal fordítók ezerszer jobbak mint bármi korábban, és vannak benne írt projektek bőven, de a nyilvánosság megragad a "LOL, paszkál" szintjén.

A mai Java runtimeokat is a Java-ban fejlesztőknek csinálják, nem pedig a shiny-fancy ninja guru fejlesztőknek. Akiknek készülnek az új runtime képességek, tudják, hogy mi miért készül és mire jó (pl. Loom, CRaC, Panama, Valhalla, stb.). Ezekkel nem fognak megfogni rakat új tinédzsert, de nem is cél.

Egyetértek, a java nem ezen bukott el, hanem hogy iszonyat lassú. Amit javaban megírsz, 10 gépen futogat, azt normális nyelven egy gép lazán viszi. Az oracle vs google per csak ráirányította a figyelmet arra, hogy lehetne ehhez értelmes gépigényű megoldást is adni

Ezt nem kell megkérdezni. Nyugodtan jöhetnek az enterprise™ tapasztalatok™, ahol a 128 magos 1 kW-ot fogyasztó monstrumon jobban skálázódik a Java kód, mint a C-ben írt megfelelője.

Aztán ha ezek a kötelező körök megvoltak, mutathatsz olyan tömegek számára is elérhető, napi használatra írt alkalmazást, amiből a Java-bloat gyorsabb és kevesebb memóriát zabál, mint a C/C++ megfelelője. Mutathatsz ilyen Torrent klienst például. Mutathatsz ilyen szövegszerkesztőt vagy Office-t. Mutathatsz olyan Android alkalmazásokat, ahol a Java-bloat-ban megírt megfelelő kevesebb CPU-t és memóriát zabál fel, mint az NDK-ban megírt.

Én nem akarlak C-re kényszeríteni, csupán arra hívtam fel a figyelmet, hogy attól még, hogy egyes fősodratú elemek itt hatékonyabb™ kódot írnak Java-ban, mint C-ben (általában J2EE-vel, meg a 128-magos skálázódásával példálózva), a Java (J2SE) ugyanakkora erőforráspazarló, memóriazabáló bloat marad a kliensgépeken futó, felhasználói alkalmazásokat tekintve. Hasonlíts össze egy Javaban írt torrent klienst egy C++-ban írttal és szólj ha találtál olyan Java-ban írtat, ami megveri az összes C++-ban írtat CPU-ban és memóriában, azonos funkcionalitás szolgáltatása mellett.

az a baj, hogy egy szavad sem hisszuk, ugyanis 0 szakmai tartalmat mutattal itt be az evek alatt, azon kivul, hogy csak frocsogsz az alusapkad alol. minden szakmai kerdeset kerulsz (milyen diplomad van? milyen munkakorben dolgozol? mikor irtal Java kodot utoljara, es mennyit?), igy sajnos ugyanannyira hitelt erdemlo minden postod mint barmelyik random posternek. csak o nem frocsog, szoval meg tobbet is er a szava.

Egyszerűen csak arról van szó, smartbirkám, hogy megint túl sokat képzelsz magadról.

Nem StackOverflow-n vagyunk, hogy reputation alapján legyen értékes vagy értéktelen valakinek a hozzászólása. Emellett szabad véleménynyilvánítás van a fórumon. Csak te játszod itt az önjelölt elitista véleménycsendőrt, meg beszélsz a nagyközönség nevében, miközben csak egy vagy a sok közül.  Ahogy elnézem a korábbi hozzászólásaidat bármilyen témához, 0 szakmaisággal osztod az észt már évek óta, ugyanazon az elit lovon ülve, pöcsfej stílusban, amiben a nekem címzett kommentet is írtad. Ha neked jogod van ehhez, akkor nekem is jogom van a diplomám, a munkahelyem, a napi aktuális feladataim és egyéb személyes dolgaim, magánügyeim közzététele nélkül véleményt nyilvánítani.

Nem mindenki gondol annak, maximum néhány szélsőségesen idealista, fősodratú mérnök úr.

Az alusapkás jelzőre pedig semmiféle okot nem adtam, mert nem foglalkoztatnak olyan témák, amiket a valódi alusapkások feszegetnek (chemtrail, HAARP stb.). Szóval ez csak egy szitokszó, amivel az eltérő véleményűeket szeretnéd megbélyegezni, mert kognitív disszonanciát okoz, hogy nem mindenki akkora smartbirka, mint te.

WAT!

Nem tudom honnan veszed ezt. A java már 10+ évvel ezelőtt is gcc -O2 vel fordított C kód szintjét hozta a legtöbb algoritmusban. Próbáld meg python-ban vagy ruby-ban... Ha már a 10 gépet idekommentelted: a mai trendy GIL-es programnyelvekben írt alkalmazást ténylegesen 10 példányban kell futtatnod (10x memóriafoglalással), hogy 10 bejövő request-et ki tudjon szolgálni. Eközben a java meg lazán kezel 3000+ aktív threadet (üzemeltetek ilyen service-t aminél 3600-as thread limit van beállítva, és előfordult, hogy ki is volt használva).

Régóta vágyok én, az androidok mezonkincsére már!

Tudnék ezen kívül még felsorolni vagy tucatnyi workaroundot "megoldást", amit a python interpreter GIL-je miatt találtak ki az elmúlt kb 15 évben. Azzal nem vitatkozom, hogy az async io és az arra épülő ASGI, lényegesen kulturáltabb, mint pl az eventlet/greenthreads volt. De az alap problémát nem oldja meg, csak próbálja kevésbé fájdalmassá tenni. És persze vannak 3rd party python runtime-ok, amikben GIL nincs vagy kikapcsolható (jython volt ez első ilyen, ami ...wait for it... java runtime felett fut :D). Végül eljutottuk odáig, hogy már a CPythonosok is szemezgetnek az ötlettel. Csak a kód hordozhatóságával vannak kis alattomos bajok a GIL-es és a GIL-nélküli környezet között...

Régóta vágyok én, az androidok mezonkincsére már!

egy csomo io intenziv dolog elengedi a GIL-t (nem tudom a releasere mi a jobb szo), gondolom ezt tudod, innentol mindent is meg lehet irni pythonban (99%-at a cuccoknak)

 Ha már a 10 gépet idekommentelted: a mai trendy GIL-es programnyelvekben írt alkalmazást ténylegesen 10 példányban kell futtatnod (10x memóriafoglalással), hogy 10 bejövő request-et ki tudjon szolgálni.

ezt az allitasodat cafoltam mert boduletes hulyeseg, ennyi tortent, a tobbi mosdatas reszedrol.

Igazad van, valoban nem kezdtem el minden reszletet kifejteni. Hogy HA a 10 requesttel valamit csinalnia is kell az alkalmazasnak, nemcsak a nyitva tartott socketen varakozni, HA kifejezetten uj pythont hasznalsz (az async io eleg nagyokat valtozott a python minor verziok kozott, nem olyan regota lett stabil), HA kifejezetten uj, async io-enabled web frameworkkel dolgozol, AKKOR valoban nem igaz amit irtam.

mert boduletes hulyeseg

Beirhatsz egy pirospontot magadnak :)

Régóta vágyok én, az androidok mezonkincsére már!

En ugy olvastam 3.7-nel meg jottek uj dolgok bele, kb azutan kezdett stabilnak szamitani. A doksi is kifejezetten irja, hogy a regi verzioknal javasolt patternek az ujabbaknal mar ellenjavalltak. Az ASGI spec mostani verzioja is 2019-es. Szoval en nagyjabol ugy szamoltam, hogy 2019 lehet, amiota komolyan merhetsz raepiteni.

Régóta vágyok én, az androidok mezonkincsére már!

Hát még 25 év (vagy mennyi ideje van java és képes valódi többszálúságra)...

Amúgy erre a 4 évre csak annyit tudok mondani, hogy minden az átírandó kód mennyiségén múlik. Ha majd például Openstack-et lehet ASGI-re deployolni, akkor majd beszélgessünk megint erről a témáról.

Régóta vágyok én, az androidok mezonkincsére már!

> Az Oracle amúgy nem cseszte szét a komplett Java-t. A Java mint nyelv és mint runtime iszonyatos ütemben fejlődik, és nyíltabb, mint valaha.

Hát ez nagyon nem igaz, sem a Java bytecode-ra, sem a JDK-ra. A 17-es verzió (2021) óta ráadásul már nem is minősül szabad szoftvernek, olvasd csak el a licenszét!
https://www.oracle.com/downloads/licenses/no-fee-license.html
https://www.oracle.com/downloads/licenses/binary-code-license.html

Sehol senki nem beszélt az Oracle JDK-ról és az Oracle Java-ról. Ezek támgoatási termékek.

A Java fejlesztése az OpenJDK projekt keretében történik, az a referenciaimplementációja a Javanak. A Java mint nyelv és mint runtime fejlődése során senkit nem érdekel, hogy milyen fizetős terméket építenek ki belőle mások (pl. Oracle JDK, Azul Zuul stb.).

A Java mint nyelv és runtime tök más, mint az Oracle JDK és Oracle Java SE, azok támogatott termékek Javara építve. Mint amikor te fogod magad és csinálsz egy LibreOfffice disztribúciót, amit támogatsz (pl. ezt csinálja a Collabora). Ettől még a LibreOffice ugyanúgy nyílt marad.

A Java fejlesztőket kurvára nem érdekli az Oracle JDK meg Oracle Java.

Amióta az Oracle megvette a Sun-t, jobban fejlődik a nyelv és a runtime, mint előtte.

> (gyk mert abbol sok van itt: openjdk gpl2 licenszu)

Gyengébbek kedvéért, az OpenJDK-nak ki is a jogtulajdonosa, hmmm?

És méghogy GPL... Egy kis olvasnivaló, csak Neked: https://github.com/openjdk/jdk/blob/master/ADDITIONAL_LICENSE_INFO
"Note that Oracle includes multiple, independent programs in this software
package. Some of those programs are provided under licenses deemed
incompatible with the GPLv2 by the Free Software Foundation and others."

Abba most inkább bele se menjünk, hogy ez úgy ahogy van, a GPL durva megsértése, lásd GPL2 section 2.b
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
Magyarán ha akár egy része is GPL-es, akkor az egésznek GPL-esnek kellene lennie. De ez az Oracle saját bevallása szerint sem teljesül.

És kivel kötelező leszerződnöd, ha csatlakozni szeretnél az OpenJDK közösséghez? Nahát, nahát, micsoda meglepetés, csak nem az Oracle-el?
https://openjdk.org/legal/OCTLA-JDK9+.pdf
Akárhogy is nézzük, az igazság az, hogy ez alapján az OpenJDK-s fejlesztők szerződéses viszonyban állnak az Oracle-el.

Jó lenne megnézni, hogy az a licenc mire is vonatkozik, és mi az OpenJDK licence.

Az OpenJDK továbbra is GPL + classpath exception licencű. https://openjdk.org/legal/gplv2+ce.html

Az Oracle Java SE és Oracle JDK egy OpenJDK alapú terméke az Oracle-nek, támogatással - gyakorlatilag supportot adnak egy open-source termékhez és hozzátesznek pár deployment komponenst.

Nagyon könnyű összekeverni az Oracle JDK-t (ami egy fizetős termék) az Oracle OpenJDK-val (az OpenJDK Oracle buildje, elérhető innen: https://jdk.java.net/).

Ha nem tetszik az OpenJDK Oracle buildje (ami nem ugyanaz, mint az Oracle JDK), akkor helyette pedig használhatsz:

  • Eclipse Termurin-t, Azul Zulut, Amazon Correttot, Microsoft OpenJDK-t, Huawei BIShenget, Alibaba Dragonwellt, OpenLogic OpenJDK-t, SAP SapMachine-t, Jetbrains Runtime-ot, BellSoft Libericat (ezek mind brandelt OpenJDK buildek),
  • Eclipse OpenJ9-et/IBM Semeru-t (OpenJ9 buildek, ami OpenJDK alapú, IBM által patchelt, teljesen kompatibilis JDK)
  • legvégül magadnak is buildelheted az OpenJDK-t

Szóval miért is nem szabad szoftvert az OpenJDK?
Az, hogy az Oracle ad hozzá pénzért támogatást Oracle JDK néven, attól még azt OpenJDK projekt nem változik meg, és a Java nem lesz zárt.

Veled ellentétben, én elolvastsam a licencét.

A Java bytecode az Oracle tulajdona

Jó lenne érteni, hogy mit is olvasol. Az Oracle által készített bináris az Oracle tulajdona, nem a Java bytecode maga (a bytecode egy szóval nem szerepel a licencben). Ha ezen Oracle által készített binárisokat felhasználod, és tovább akarod terjeszteni, akkor arra vannak korlátozások. De te bármikor bármilyen Java bytecode-ot használhatsz, ami nem az Oracle-től származik, nem vonatkozik rá ez a licenc (nem is tudna vonatkozni). Nagyon könnyen félre lehet érteni (neked is sikerült) azt a részt, hogy ha Oracle által buildelt JDK-ból építesz a programoddal jlink-kel külön JRE-t, akkor bizony ez a licenc arra is vonatkozik. Nyilván, hiszen Oracle által buildelt bináris lesz benne, ezért. De nem, nem igaz, hogy minden Java bytecode proprietary lett, ez teljes félreértése a dolgoknak.

és a licenszfeltételei az OpenJDK-ra is vonatkoznak

Nem. Az egész licenc nem vonatkozik másra, mint az Oracle Java SE binárisokra, amit az Oracle buildel, valamint azokra a custom JRE-kre, amiket te ezekből a binárisokból összeállítász. Semmilyen más OpenJDK buildre nem vonatkozik ez a licenc.

> Jó lenne érteni, hogy mit is olvasol. Az Oracle által készített bináris az Oracle tulajdona, nem a Java bytecode maga

Ez az, ahol rohadtul tévedsz. Nemcsak az Oracle által készített bináris az Oracle tulajdona, hanem maga a Java bytecode, VM technológiástul, API-stul, egész platformostul, tokkal-vonóval. És még a szabadalom is az Oracle tulajdona, lásd többek között U.S. patent 14/468,016, U.S. patent 11/753,519, U.S. patent 8,819,673 a copyrighton túl.

Az Amerikai Legfelsőbb Bíróság kétség kívül így tudja, akármit is mondasz. https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
"Oracle America, Inc., owns a copyright in Java SE, a computer platform that uses the popular Java computer programming language."

Érdemes elvolasni. Részeletesen leírja, hogy a Gugli csakis azért úszta meg a pert, mert nem lopta el az egész Java platformot (az Android appok Davlik-on futnak), és töménytelen mennyiségű dollárt öltek a jogi csatározásba 10 éven át, hogy a bíró csakis annyit nézzen, az API lopás önmagában jogsértő-e.

1. A szoftverszabadalmakkal nem tudom, miért jössz, Európában nem érvényesek.

2. A copyright az nem tulajdonjog, hanme szerzői jog. A Linux kernel felett is van sok-sok személynek meg cégnek copyrightja, mégsem tekintjük azon cégek tulajdonának. Copyrighos például a Linux név is. A Microsoftnak is copyrightja van a dotnetre, a PHP Groupnak a PHP-ra. Ettől még ugyanúgy nyílt licencűek (eleve a copyright holder az, aki a terjesztési licencet meghatározhatja és senki más).

3. A Google vs Oracle per 2005-ről szól, amikor a Java még nem volt nyílt, totál irreleváns ma már. Az pedig, hogy szoftverinterfészek és specifikációk copyright-olhatók-e, az teljesen természetes. A POSIX, Single UNIX Specification is copyright-olt API, mégsem hőbörög senki, hogy milyen gonosz az Open Group, amikor fenntartja a jogait a Single UNIX Specification kapcsán. Például: https://www.opengroup.org/austin/papers/single_unix_faq.html 
 

Q10. How do I get permission to excerpt materials from the standard for reuse in my product?

All queries regarding permission to reproduce sections of the standard should be sent to austin-group-permissions at The Open Group . Permission needs to be granted by both copyright holders, The IEEE and The Open Group.

Nagyon komoly ködszurkálásba kezdtél, jöttél bytecode-dal (az USA SC által eldöntött pernek ehhez semmi köze), jöttél Oracle JDK licenccel, jöttél szerzői joggal (ami mindenkit megillet, szinte minden nyílt szoftver copyrightos - kivéve azt, ami public domain, de ez elenyésző), csak egyiknek sincs semmi köze az OpenJDK szabad felhasználásához. Nem is értem, miért hoztad ide a copyrightot. Az egész "copyleft" és nyílt szoftver legalitását a szerzői jogi törvény engedi, hiszen az engedi meg a szerzőknek, (ami lehet az FSF, Linus, Microsoft, Oracle, Stallman, a GNU projekt, bárki) hogy eldönthessék a licencet, ami mentén közzéteszik a művüket. Ha nem lenne létező fogalom a szerzői jog (copyright), nem létezhetne szabad szoftver sem.

> Ha nem akarod hogy egy versenytárs a termékeid forrására építsen

> Simply rebuilding code, without adding value or changing it in any way

Ha nagyon szó szerint veszem, akkor épp arról beszél, hogy nem ráépít, hanem csak használja. Azaz élősködik és ezzel gyakorlatilag visszaél.

Se visszaélés nincs itt (ez éppen hogy a jogaiddal való élés), se élősködés. A szabad szoftver ilyen, szabadon terjesztheted, pénzér' vagy ingyér'. Változatlan formában ("no added value"; lol, éljen az üzleti lárifári), vagy változtatásokkal. (Azt most hagyjuk is, hogy a RH is azzal kezdte, hogy "elősködő" módjára üzletet épített egy rakás szabad szoftverre -- amit  a szabad szoftver meg is enged. Most meg ők hivatkoznak élősködésre, meg rossz kifogásokkal jönnek.)

Ugye nem engem akarsz meggyőzni? Mert engem hiába, semmi közöm hozzá.

Csak arra írtam, h az én értelmezésemben mi a baja.

 

Azzal pedig lehet vitatkozni, hogy mennyire 'szabad' az RH, mint  sw disztribúcio (szubjektiv) és hogy mit jelent a visszaélés (szintén szubjektív).

Mindenesetre a figura deklarálta, hogya a hozzáadott érték hiánya az, ami bántja a csőrét. Az RH-n ak van hozzáadott értéke ahhoz képest, hogy van egy szoftver és annak a github repo-ja, ezzel szerintem nem lehet vitatkozni.

 

Ismétlem, ez az én értelmezésem és szívesen veszem, h vki megvilágítja máshogy.

 

ps.: Kerülöm az RH-t ahol csak tudom, nem kedveltem a céget és a distrot sem igazán.

Így van. Ez a copyleft licenc lényege, hogy senki nem zárhatja be a kódot, teljesen mindegy, hogy milyen hozzáadott értéke van (hiszen az eredeti kódra épülő munkáknak is GPL-esnek kell maradniuk) vagy nincs, a kód örökre szabad marad. Ezt kéne megérteni a Red Hat-nek. Azért meg ők nagyok, meg speciálisak, attól nem bújhatnak ki ez alól. Pont ezért van, hogy a MS nem nagyon meri piszkálni a GPL-es kódokat, meg sok nagy cégóriás ezért épít BSD-licences kódra inkább, mert azt nyugodtan bezárhatják, lásd Apple, Netflix, Sony Playstation, stb..

Ez a videó már borúsabb képet fest, a fószer idézi benne, hogy ma már a OSS projektek többsége nem GPL vagy egyéb copyleft licences, hanem nem copyleft Apache, MIT, stb. licences, és emiatt a RH megteheti a bezárást. Nekem viszont továbbra sem ez a véleményem, mert ha egy adott csomagnak a licence megengedőbb, de mondjuk dependel egy GPL-es libre (kernel, glibc, akármi) a csomag, akkor megint nem lehet bezárni a kódját, derivative work alá tartozik. Azért a GNU-sokat és a kerneleseket ne nézzük már le, nem hülyék ők sem, nem ma jöttek le a falvédőről, tökéletesen látták ezt előre, hogy nagy cégek ezzel próbálkozhatnak, előre bevédték magukat ez ellen.

The world runs on Excel spreadsheets. (Dylan Beattie)

> Azért a GNU-sokat és a kerneleseket ne nézzük már le, nem hülyék ők sem, nem ma jöttek le a falvédőről, tökéletesen látták ezt előre, hogy nagy cégek ezzel próbálkozhatnak, előre bevédték magukat ez ellen.

Én nem lennék ebben azért olyan biztos. Egyáltalán nem úgy néz ki, mintha be lennének védve, sőt, a GNU nyíltan bevallja, hogy az a sok binary firmware blob, amivel mostanában tele van a Linux kernel, meg a 3rd party előrefordított kernel modulok (nvidia és vulkan driverek főként) egyértelműen sértik a GPL-t, mégsem tesznek (tudnak vagy akarnak tenni) ellene semmit.
https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux

> Ez a copyleft licenc lényege, hogy senki nem zárhatja be a kódot, teljesen mindegy, hogy milyen hozzáadott értéke van (hiszen az eredeti kódra épülő munkáknak is GPL-esnek kell maradniuk) vagy nincs, a kód örökre szabad marad. Ezt kéne megérteni a Red Hat-nek.

Az, hogy az RH letiltással fenyegeti azokat a feliratkozóit, akik terjeszteni merészelik a tőlük letöltött anyagokat, na az szerintem is minden kétséget kizáróan megsérti a GPL feltételeit. A section 7 külön kiemeli, hogy semmilyen plusz megszorítás ("further restriction") nem adható a GPL-hez, és ha egy disztribútor ezt mégis megpróbálná megtenni - hozzáadott érték ide vagy oda -, akkor a felhasználók legálisan fel vannak hatalmazva, hogy szarjanak rá. Konkrétan ez szerepel a GPL-ben.

Ügyes, elismerem, de majd a RH elzárja ezt az UBI image-ezős utat is, mondjuk valami licenc- vagy szerződési feltétellel, és akkor újra bukta. Itt azt kell érteni, hogy a Red Hat klónoknak annyi, mindenképp el fogja őket lehetetleníteni az IBM/RH, ez már most látszik, hogy eltökéltek, végigviszik. Ezt nem lehet megakadályozni, max. csak azzal, ha az ember átvált nem RHEL-alapú, lehetőleg community megoldásokra, és nem hagyja, hogy ilyen nagy cégóriások fizetős megoldásokra zsarolják rá.

Remélem ezzel olyan csúnyán megégeti magát az RH, mint legutóbb a Reddit az API bezárással.

The world runs on Excel spreadsheets. (Dylan Beattie)

A Red Hat médiakampányban és az influenszerein keresztül indított lejáratókampányt és kereszteshadjáratot azok ellen, akik a stabil Enterprise Linux-ot újracsomagolják és terjesztik. Tucatnyi ilyen fork van, de a leghíresebb nyilvánvalóan az Alma Linux és a Rocky Linux. Hangsúlyozom, hogy arról az Enterprise Linuxról beszélek, ami alapvetően verzióvisszatartott csomagok karbantartására és folyamatos támogatására, javításokkal való ellátásáról szól. Ez képvisel értéket. A stabilitás a manapság már össznépileg elfogadott minőséginek távolról sem nevezhető, instabil upstream szarkatyvaszokkal szemben. A maradandóság az állandó változtatgatás, a refaktor-kényszerbetegség és az API-törögetési mániával szemben. Ezt a Red Hat is nagyon jól tudja, ezért lázad és lázít célzottan a stabil ágait újracsomagolók ellen.

Egy kérdés, hogy a Red Hat-nak erre semmiféle jogi alapja nincs, a GPL garantálja mindenkinek a szabad hozzáférést a forráskódokhoz és azok felhasználhatóságához. Más kérdés, hogy erkölcsi alapja sincs rá, sőt üzleti etikai alapja sincs. Tekintettel arra, hogy a megosztott forráskódok, az open-source közösség több évtizedes ingyen és bérmentve elvégzett munkája az, ami a Red Hat-ot odáig emelte, hogy egy IBM felvásárolja. Az összes forráskódot tekintve egy Linux disztribúcióban még mindig több munka van a közösség által, mint a Red Hat által, közösség alatt értve itt minden olyan konkurens multit is, akik szintén bedolgoznak az open-source világba, csak kevésbé arrogáns módon.

Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.

Sok szempontból szebb volt a Linux-világ, amíg hobbisták és hackerek és nem Red Hat-féle multik világa volt. Sok szempontból egyszerűbb, szabadabb és kiszámíthatóbb volt és ez a világ sok szempontból nagyon hiányzik. Viszont továbbra sem szabad elfelejteni, hogy ők kezdetben ezekre a hobbikódokra és hacker-kódokra építve lettek azok, amik. Nélküle semmik lennének most. Az pedig undorító, hogy ez a klisé a GNU-nak intézett burkolt beszólás is volt egyben. Mindazzal együtt, amit anno felépítettek.

A Red Hat jelen formájában GPL kódok nélkül nem létezne és nem is épült volna fel. Kezdetben ők is csak újracsomagoltak, eladták mások munkáját, amiért ezek az emberek egy büdös fillért nem láttak a Red Hat-tól. Később már kinőtték magukat akkorára, hogy fejleszteni is tudtak is bele. Most pedig már ők akarnak diktálni, ráadásul velejéig arrogáns módon. Másként szólva, a Red Hat eljutott oda, hogy már megvan egy érett piaca és nem tud nagyságrendileg növekedni. Az IBM viszont nem dísztárgynak vette a céget, hanem növekedést akar. Minden multi előbb-utóbb eljut ehhez a ponthoz, hogy értékteremtéssel már kevésbé tud profitot szerezni, és ekkor fordul a piac manipulálása felé.  Az IBM profitot akar és ha tisztességes profitot nem lehet többet kisajtolni a piacból, akkor a felforgató tevékenység következik.

  • Lesz itt még Red Hat által módosított GPL licenc, amin a kilóra megvásárolt open-source fejlesztők majd újralicencelik a kódbázisaikat. Ez már a közeljövőben valószínű.
  • Lesz itt még kartellszerű lobbizgatás a multiktól az amerikai kongresszusnál, hogy GPL-típusú licencek DMCA-ellenesek legyenek, így szoktatva le mindent és mindenkit az open-source-ról. Ez persze csak a távoli jövőben.
  • Folytatódik a Red Hat felforgató tevékenysége a Linux-világban. Systemd, pulseaudio, pipewire, gtk3, gtk4 után itt a Wayland, amit még le kell nyomni a torkokon, hogy az egész kibaszott desktop Linux ökoszisztéma rajtuk dependáljon. Indul majd a FUD kampány az X11 ellen és az IBM-milliárdokból bőven tudnak elég bértollnokot és influenszert fizetni, akik elintézik, hogy néhány év múlva az X11 szitokszó legyen szakmai kökzösségekben. Nagyjából úgy, mint most a PHP vagy a Windows XP.
  • Persze, az is lehet, hogy valami csoda folytán a konkurencia (SuSE, Oracle, Amazon, esetleg Microsoft) összeszedi magát, növeszt magának tököt, és együttes erővel nekimegy a Red Hat-nak legalább annyira, hogy az IBM meg akarjon szabadulni tőle. Néhány GPL class-action per milliárdos kártérítésekkel megtenné a magáét.

No de mit tehet most az open-source közösség? Leginkább azt, hogy csakazértis a derivatív RHEL-ek felé fordul, ha enterprise linuxot szeretne. Csakazért is Rocky vagy Alma Linuxot használ és csakazért sem veszi meg pénzért az RHEL-t. Így láttatva multiékkal, hogy ez a velejéig arrogáns, "oda szarok ahonnan mások esznek" üzletstratégia nem fog bejönni. Aztán persze ha az Enterprise Linux konkurenciája lennék, én biztosan elhappolnám a legjobb fejlesztőket és maintainereket, ha nem is a Red Hat-tól, de a Red Hat vonzáskörzetéből. Végül magukra maradnak.

Az influenszerek egy jelentős részét az idén elküldték. Videók és podcastek állandó szereplői írták be egyszer csak a chat-be, hogy "bocsi, már nem vagyok Red Hat munkatárs".

A növekedésre pedig ott van a Continuously Certified Linux Platform for Road Vehicles és a General Motors-nak készülő In-vehicle software systems projekt systemd(hirte) + podman alapokon.

"Mistakenly accepted conclusion that a downstream rebuild of rhel generates rhel experts and generates rhel sales. And the fact is when it plays out we have not actually found that."

Az ismerőseim közül mindenki (és én is) CentOS-t használva került közelebb, majd később javasolta prod-ba a Red Hat-et. Az általam hallgatott kurzusok/tanfolyamok is mind CentOS, majd Rocky Linux-on történtek.

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Alapvetően egyetértek. Néhány pontosítás: a Wayland azonban nem RH fejlesztés, persze ők is fejlesztenek ilyen alapon cuccokat, de a protokollt nem ők írják. A másik, hogy a Linux világa mindig működik hobbista/hacker, szabadhippi, nem corporate, nem Red Hat alapon, el lehet elvileg kerülni a systemd-t, pulseaudio-t, pipewire-t, Gtk-akárhányat, bár elég nehéz, meg kell dolgozni vele, meg kompromisszumot kell kötni. Amiről te beszélsz, az a normiknak készített mainstream Linux, de az nem feltétlen egyenlő a teljes linuxos világgal.

A Rockyval, Almával az a baj, hogy ha tényleg működik a RH-nál a bezárás, akkor ellehetetlenülnek ezek. Persze akármilyen Linuxot lehet használni, nem csak RH alap van, de ugye a Rocky/Alma (és Oracle plusz Euro Linux) mellett az szólt, hogy RHEL klón, most hogy majd nem lehet az, miért választaná akárki is ezeket a többi, nem céges disztró ellenében?

A PHP amúgy nem szitokszó, inkább csak a babzsákfejlesztők váltottak más hájpvonatra, mert a PHP-ül tul sokan tudnak, és kellett ugye valami, amivel új állásokat, megrendeléseket lehet szerezni, a trendhajtóknak ki lehet tűnni, mint különlegeseknek. Az XP se szitokszó szerintem, csak muzeális retró cucc, nem releváns már csak. Az X11-et meg hiába próbálják kinyírni, nem fog menni. Túl univerzális, túl sok unix/unixlike rendszer és szoftver használja, azokra nincs befolyása a Red Hat-nek.

The world runs on Excel spreadsheets. (Dylan Beattie)

a Wayland azonban nem RH fejlesztés, persze ők is fejlesztenek ilyen alapon cuccokat, de a protokollt nem ők írják

Igen, tudjuk, a Wayland csak™ egy™ protokoll™, véletlenül sem a Red Hat új trójai falova, amivel igyekszik menthetetlenül megfertőzni a desktop Linux világot.

A Rockyval, Almával az a baj, hogy ha tényleg működik a RH-nál a bezárás, akkor ellehetetlenülnek ezek.

Kérdés, hogy tényleg működik-e a bezárás. Mert jelen állás szerint jogellenes.

A PHP amúgy nem szitokszó, inkább csak a babzsákfejlesztők váltottak más hájpvonatra, mert a PHP-ül tul sokan tudnak, és kellett ugye valami, amivel új állásokat, megrendeléseket lehet szerezni, a trendhajtóknak ki lehet tűnni, mint különlegeseknek.

Igen, de mindeközben a PHP-ból szitokszót csináltak a babzsákinfluenszerek, hogy értékesebbnek tűnjön az instabil, éretlen szar újrafeltalált kerék, legalább az által, hogy a PHP értéktelenebbnek tűnik nála.

Az XP se szitokszó

De igen, az, és konkrétan a Microsoft FUD kampánya csinált belőle szitokszót. Különben nem lenne hírértéke annak, hogy egy ATM-en még mindig Windows XP fut, és ezért™ törték meg (ja nem, csak a Windows XP-re rá lehet fogni).

Az X11-et meg hiába próbálják kinyírni, nem fog menni. Túl univerzális, túl sok unix/unixlike rendszer és szoftver használja, azokra nincs befolyása a Red Hat-nek.

Úgy értettem, a mainstream Linux világból kiirtani. Nyilván, FreeBSD-n sincs systemd.

Szerintem rosszul ítéled meg. A Waylandet neked különösen ajánlom, hogy az ablak és görgetősáv tekergetés a mániád, meg hogy mi hány ms alatt rajzol ki. Abban tényleg jobb, és veri az X-et. Viszont ahol elhibázzák, hogy a Wayland félkész, nem minden gépre, felhasználási típusra a legjobb (a mi egyszerű desktop felhasználásunkat persze bőven lefedi), vannak annak is korlátai, és az X-es ökoszisztéma túl erős ahhoz, hogy néhány ilyen Red hat-es öltönyös nyakkendős trenddiktátor ki tudja nyírni.

Az XP-vel az a baj, mint írtam, hogy régi, és nem tud előnyt nyújtani. Minimalista rendszert modernebb OS-ből is tudsz építeni. Desktopra meg nem a legjobb, sőt, a legtöbb modern hardverhez használhatatlan, mert nincs hozzá driver. Az AMD az AM3-ig támogatta talán, illetve prohardveres hobbista csinált chipset drivert Ryzen 1-2. genhez is. Intel vonalon a Core i 4-5. generáció támogatta utoljára, de már az se teljesen, a teljes támogatás megállt a 3. gennel, illetve 8-10 évvel ezelőtti GPU-knál. Nagyon régi hardvert meg már azért sem mindig éri meg venni, mert 1) nem mindig annyival olcsóbb, hogy megérje, főleg ár/teljesítmény arányban, 2) általában a fogyasztása sem olyan gazdaságos. Be lehet vállalni, de egy XP nem nyújt akkora előnyöket, hogy megérje csak azért. XP-t arra kell használni, amire való, tipikusan retró gamerek tolják még, meg retró overclockerek, mert itt még van haszna, van jó pár olyan játék, ami csak XP alatt fut jól, és ugyan trükkökkel elindítható újabb Windowsokon, de valami feature, textura, intró, stb. nem fog stimmelni. Meg egyes kórházak meg ipari gyártósorok, ahol az orvosi felszerelésekhez, meg vezérlőgépekhez, amik sok évesek, nincs driver újabb OS-ekre.

Igen, FreeBSD-n nincs systemd, pont ezek azok a pontok, ahol egy hagyományos, konzervatív, szigorúbban POSIX kompatibilis rendszer ki tud tűnni előnnyel, hogy nincs ez a sok sytemd, pulseaudio, pipewire, egyéb corporate bloat szutyok. Gtk3 az van, meg elvileg a wayland-es megoldás is beröffenthető rajta, de hát minek, azokat nem muszáj feltenni. Vagyis egy dologhoz muszáj a Gtk3, a legtöbb böngésző azt használja, hacsak az ember nem akar kompromisszumozni valami QtWebkit-alapú alternatív megoldással (surf, qutebrowser, vieb, nyxt, stb.). Viszont a FreeBSD-nek van hátránya is, hogy hardvertámogatásban lényegesen gyengébb, szűkebb körét támogatja a hardvereknek (lehet persze trükközni, hogy átportolt linuxos kernelmodulokkal tolni, de ez is le van benne maradva), meg van már néhány népszerű szoftveres megoldás, ami Linuxon megy, BSD-ken még nem.

The world runs on Excel spreadsheets. (Dylan Beattie)

Élmény volt olvasni, milyen gyorsan áttértek a kommentek a poszt megvitatásáról a "java jó vagy nem" kérdésére. Nem baj, legalább gyorsan végigpörgettem a topicot

http://www.micros~1
Rekurzió: lásd rekurzió.

Ellenben a Rocky él és virul és eltökélt maradt.

https://rockylinux.org/news/keeping-open-source-open/

Sőt, azóta csatlakozott az alapítványuk igazgatótanácsához Theodore Ts'o is.

https://rockylinux.org/news/2023-07-RESF-names-new-board-member/

Tekintve, hogy a Google-nél dolgozik és nagy múltra tekint vissza, talán vannak elég jó kapcsolatai, amivel segítheti a Rocky Linux fennmaradását az önző, mohó Red Hat-tól érkező esetleges támadások esetén.