Red Hat opravdu ztěžuje práci Oraclu (diskuse)

[kkaarreell]

Tato změna vývoj podle Stevense...

[Tomáš Bžatek]

Jo ta veta je divna. Asi neumim cesky. (Ehm, mel bych priznat Moravskou narodnost, ne? )

[JoHnY2]

Neni to zrovna nejkrasnejsi reseni pod sluncem, ale kdyz jim Oracle docela seredne leze do zeli, tak chapu, proc to musej delat.

[Ivan]

Kdo vi jak se to bude vyvijet dal. Oracle koupil Solaris a RH vydal RHEL6. Certifikace OracleDB na RHEL6 nejenze jeste neni, ale ani se o ni nemluvi.

[Martin Mareš]

Zajímavé. GPLv2 říká:

The source code for a work means the preferred form of the work for making modifications to it.

Což něčeho, co je interně udržováno jako množina patchů oproti vanilla kernelu, jsou poměrně evidentně jednotlivé patche, nikoliv jejich slepenec.

[Bilbo]

To by pak mohlo znamenat, že pokud si tohohle všimnou i další lidi a začnou do redhatu šťouchat, že s tím holt redhat bude muset přestat.

[trekker.dk]

Což něčeho, co je interně udržováno jako množina patchů oproti vanilla kernelu, jsou poměrně evidentně jednotlivé patche, nikoliv jejich slepenec.

Tvoje evidentně chce hodně velký logický skok. GPL říká, že musíš dát zdrojáky ke svým změnám. To Red Hat dělá, protože zdrojáky k jejich jádru stáhnout jdou. Do způsobu, jakým došlo ke změně mezi vanilla jádrem a jejich jádrem, ti nic není.

Btw. nepracuješ náhodou pro Novell?

[Martin Mareš]

GPL říká, že musíš dát zdrojáky ke svým změnám.

To je jistě pravda, ale pravidlo, které jsem citoval, neříká pouze to. Například určitě zakazuje úmyslně zdrojáky zamlžovat (pokud by třeba někdo ze zdrojáků, které distribuuje, vyházel všechny mezery a vše slepil na jeden dlouhatánský řádek, nezáleželo by na tom, jestli to jde zkompilovat nebo ne – v případném soudním sporu by musel dokazovat, že program sám vyvíjí v této formě nebo že to je alespoň v jeho oboru činnosti běžné.) Není slepení patchů velice podobný druh zamlžení?

Btw. nepracuješ náhodou pro Novell?

Svatej tučňáku, proč bych to dělal???

[kavol]

v případném soudním sporu by musel dokazovat, že program sám vyvíjí v této formě nebo že to je alespoň v jeho oboru činnosti běžné

to není tak jednoduché - interní postupy zas spadají pod ochranu typu obchodní tajemství atd., a GPL v tomto nemůže jít nad zákon

krom toho, tebou citovaný kousek mluví o samotném zdrojovém kódu, nejsem si vůbec jist, jestli jej lze aplikovat na organizaci patchů - já jej chápu tak, že to, co se programátorovi objeví v jeho oblíbeném editoru, a co bude upravovat, musí být v preferované (čtu "neobfuskované") podobě, ale neříká nic o tom, co všechno má být mezi originálním a novým zdrojákem

Btw. nepracuješ náhodou pro Novell?

Svatej tučňáku, proč bych to dělal???

tak jsem si rozkliknul homepage, abych se ujistil, že stále děláš to nejlepší, co můžeš ... a koukám na nějaké novinky v osobním životě, chjo, k některým se ty drby holt ne a ne šířit, tož aspoň opožděně gratuluju, brum

[Mandarinka]

Řekl bych, že musíš dodat ten zdroj, z kterého byla zkompilována binárka, kterou jsi vydal.

[Bilbo]

Ne, ale pokud by někdo měl na výběr jestli vydá do svět nějak zamlžené zdrojáky, nebo je vydá nezamlžené ale obsahující obchodní tajemství, tak by je nemohl vydat vůbec. Zalžené proto, že by porušil GPL a tímpádem šířil nelegální kopie programů (zákon), nezamlžené proto, že obchodní tajemství (možná taky zákon)

IMHO obchodní tajemství v GPL softwaru se dá řešit tak, že se např. do komentáře místo textu obsahujícího tajemství šoupne text typu "Viz interní wiki, článek XYZ" a něktěré věci (dokumentace) jsou pak drženy mimo zdrojáky a nepublikovány.

Tipnul bych, že workflow redhatu zůstal stejný (někde mají git repozitář, na něm produkční větve které tam nalepují), akorát místo toho aby checkoutli vanilla kernel a přes git-format-patch tam přidali sérii patchů mezi vanilla a větví tak checkoutnou místo toho rovnou tu větev.

"Preferovaná forma modifikace" by pak byl asi konečný stav větve (na který se prostě nabalují další a další patche, následované commit a push), na druhou stranu při git-rebase dochází občas k modifikaci minulosti a jsou přepisovány (případně odebírány) patche mezi novou verzí vanilla a vývojovou větví, takže s uvážením tohohle by pak preferovaná forma modifikace byl prostě pouze a jedině celý .git repozitář.

[kavol]

Ne, ale pokud by někdo měl na výběr jestli vydá do svět nějak zamlžené zdrojáky, ...

ale ty zdrojáky samy o sobě nijak zamlžené nejsou - chybí (resp. je určitým způsobem znehodnocena) jenom informace, jak se z těch starých staly nové

"Preferovaná forma modifikace" by pak byl asi konečný stav větve (na který se prostě nabalují další a další patche, následované commit a push), na druhou stranu při git-rebase dochází občas k modifikaci minulosti a jsou přepisovány (případně odebírány) patche mezi novou verzí vanilla a vývojovou větví, takže s uvážením tohohle by pak preferovaná forma modifikace byl prostě pouze a jedině celý .git repozitář.

opravdu mi není jasné, z čeho toto odvozuješ ... proč tedy FSF nebo gpl-violations nežalují ty tisíce firem, co používají GPL software ve svých produktech, a zdrojáky mají zastrčené někde na webu "aby se neřeklo" jako jeden tarball bez jakékoliv VCS historie, přestože interně to mají v svn, v clearcase, atd.?

[Martin Mareš]

musí být v preferované (čtu "neobfuskované") podobě,

No právě. A jeden z poměrně smysluplných pohledů je, že splácnutí hromady patchů (což je podoba, v níž to spravuje Redhat) do jednoho velkého je forma obfuskace. Navíc se sami nechali slyšet, že je to jako obfuskace míněno ;)

[kavol]

A jeden z poměrně smysluplných pohledů je, že splácnutí hromady patchů (což je podoba, v níž to spravuje Redhat) do jednoho velkého je forma obfuskace. Navíc se sami nechali slyšet, že je to jako obfuskace míněno ;)

vo tom žádná - akorát mi schází ten logický krok, případně dovysvětlení mé neznalosti angličtiny, podle kterého se ta pasáž GPL vztahuje i na ty patche, a ne jenom na výsledný kód

[Martin Mareš]

Důležité je podle mého názoru to, v jaké formě je dílo vyvíjeno – pokud ho opravdu autoři udržují jako sadu patchů a kompilační proces obsahuje i automatické poskládání patchů, pak je preferovaná forma ta množina patchů, nikoliv zdroják vzniklý jejich složením (který v tom všem vystupuje pouze jako jeden z mezivýsledků, podobně jako výstup Céčkového preprocesoru).

Naproti tomu pokud si někdo udržuje historii v nějakém VCS, tak modifikuje pouze nejnovější verzi a zbytek je pouze záznam minulosti. Takže preferovanou formou je aktuální stav.

[Bluebear]

Řekl bych, že je to poněkud prasárna.

Na druhé straně na hrubý pytel hrubá záplata; Oracle jsou taky pěkné k***y.

[Michal Kubeček]

Bohužel to vypadá, že Oracle není jediný, komu to komplikuje práci.