Vlákno názorů k článku
Microsoft vydělává dvě miliardy dolarů ročně na poplatcích za Android
od Lael Ophir - Výrobci mobilů licencují řadu patentů. U GSM technologií...
-
Lael Ophir (neregistrovaný)
Výrobci mobilů licencují řadu patentů. U GSM technologií jsou to firmy jako finská Nokia, americká Motorola, švédský Ericsson, americký Qualcomm, japonská Toshiba, německý Siemens, kanadský Nortel atd. Za jiné věci platí MS, za další Applu atd.
BTW Apple žaloval Samsung za porušování patentů, a soud mu přiklepnul $1.05 miliardy. Samsung se podle všeho odvolá. Jak vidíte, tak samotný Apple zřejmě dokáže dostat miliardu od jediného výrobce, plus ho nejspíš donutit i k budoucímu licencování patentů. Výrobci smartphonů prostě nesmí patenty porušovat. Musí za ně platit, jako kdokoliv jiný.
http://news.cnet.com/8301-13579_3-57500159-37/jury-awards-apple-more-than-$1b-finds-samsung-infringed/ -
j (neregistrovaný)
Aaaa nas oblibeny kecalista ... kdybys neplkal hovadiny, tak oni neplati za HW patenty, ale za (nikdy nepredlozene) SW patenty, ktere "pry", "mohou" porusovat. Kdyby ovsem takove patenty existovaly, platil by jiste i google ... coz je na tom nejzajimavejsi, ze google neplati NIC ... nejde totiz ty negramote o patenty za mobily ale za android, ale to si nekdo jako ty samozrejme nemuze umet precist.
-
Lael Ophir (neregistrovaný)
Rozdělení patentů na "HW" a "SW" je u smartphonů tak trochu mimo. Například řada patentů v GSM a GPS technologiích se dá realizovat pouze za pomoci CPU, takže jde o "SW" patenty.
Výrobci platí buď proto že dobrovolně licencují, nebo na základě jednání mezi firmami, případně na základě rozhodnutí soudu. V případě MS firmy samozřejmě dobře vědí za co platí. A že to nevíte vy? Vy to vědět nemusíte, protože nejste jednací stranou.
Google neplatí z jediného důvodu: pouze publikuje kód, na což patenty nepotřebuje, protože jde o autorskou činnost. Na kód se vztahuje copyright; tam se zase vedl (a dál vede) spor o Javu s Oraclem. Google totiž podle všeho prohnal JDK decompilerem a výsledný kód opsal.
-
Lael Ophir (neregistrovaný)
Tak se koukněte na výsledky dekompilace JDK srovnané s kódem Googlu. "Kupodivu" je tam shoda 1:1, ve 43 případech. Zřejmě náhoda :D
http://www.fosspatents.com/2011/01/new-evidence-supports-oracles-case.html
http://www.fosspatents.com/2011/01/android-device-makers-distribute-oracle.html -
Lael Ophir (neregistrovaný)
1. Soudní proces Oracle v Google není u konce.
2. Tyhle materiály přišly až po zahájení soudního procesu, takže nebyly jeho součástí.
3. Pokud vám ideologická zaslepenost brání projít si linkované materiály a udělat si vlastní názor, je problém na vaší straně.S pozdravem, Lael
-
Lol Phirae (neregistrovaný)
Jo, přišly... zpadly z Marsu, asi. :-D Ale nejhorší je, že ty ani nevíš, co vlastně odkazuješ. Zpátky na školení, a zkuste to znova.
This quote here is also remarkable: "It's worth noting that this particular new evidence supplied by Mueller isn't at issue in the litigation between Oracle and Google." Either the author has never read Oracle's complaint against Google, or he doesn't interpret it correctly. In paragraph 40, Oracle says: "In at least several instances, Android computer program code also was directly copied from copyrighted Oracle America code. For example, as may be readily seen in Exhibit J, [...]" So the copyright infringement allegation is by no means limited to only one file (PolicyNodeImpl, which was presented in that Exhibit J). There will now be a comprehensive discovery process involving everything, and I have no doubt that at least some (if not all) of the files I presented will come up at that stage, even if Ars Technica may still believe that this material "isn't at issue".
-
Ja by som kusok toho kodu odcitoval...
public class PermissionImpl implements Permission { public PermissionImpl(String s) { permission = s; } public boolean equals(Object obj) { if(obj instanceof Permission) { Permission permission1 = (Permission)obj; return permission.equals(permission1.toString()); } else { return false; } } public String toString() { return permission; } public int hashCode() { return toString().hashCode(); } private String permission; }Predpokladam, ze tutok Lael nema prilis predstavu, ale kazdy, kto sa niekedy stretol s Javou a zvykmi, ktore programatori pri nej prevazne dodrzuju iste vidi, ze sa toto proste inak napisat neda.
Az sa divim, ze na to MS este nema patent :P
-
Lael Ophir (neregistrovaný)
OK. Na prvním místě ty zdrojáky od Googlu mají importy ve stejném pořadí jako ty od Sunu. To bude jistě náhoda, že? A že mají metody ve stejném pořadí; to se jistě také stalo náhodou. A když se kouknete na dokument číslo 2, stranu 2, uvidíte public aclImpl, kde pořadí operací není důležité, ale autor to napsal zrovna náááhodou úplně stejně jako Sun Microsystems. O stránku dále vidíme getPermissions. Wow, nááádohou se autor strefil do pořadí enumeration2, enumeration3, enumeration, enumeration1, enumeration4, enumeration5, i když na pořadí nijak nezáleží.
http://www.docstoc.com/docs/69702409/2-AclImpl-synopsisMyslím že je to nad slunce jasné: ty zdrojáky jsou ukradené. Někdo prohnal JDK dekompilátorem, výsledek použil, a myslel si, že mu to projde.
-
Lael Ophir (neregistrovaný)
Ještě k tomu proč soud rozhodl jak rozhodl: tahle analýza před soudem vůbec nebyla, protože se objevila až po zahájení procesu. Navíc u soudu rozhodovala o vině porota. Ta byla složená losem ze základoškolských učitelů a střihačů živých plotů, a odpůrce z ní navíc nechal vyhodit všechny lidi s technickým povědomím nebo vyšším vzděláním.
Můj názor je jasný: Android je postavený na ukradené Javě - a nejde o popis API, ale o přímé kopírování kódu. Důkazy jsou jasné.
-
Lol Phirae (neregistrovaný)
Můj názor je jasný: Android je postavený na ukradené Javě - a nejde o popis API, ale o přímé kopírování kódu.
Tak si běž zaplakat Ballmerovi na rameno.
Důkazy jsou jasné.
Ovšem. Taky ty soudy jsou úplně k ničemu, vždyť by přece mohli najmou podobného "experta", jako jseš ty, a bylo by vyřešeno.
-
Lael Ophir (neregistrovaný)
Pokud je to váš komentář k zjištěním která linkoval, tak je to na pomezí tuposti a trapnosti. Zkuste spíš vysvětlit, proč zdrojáky od Googlu mají stejné pořadí importů, metod, a vlastní kód metod má stejnou funkci i pořadí operací, i když to pořadí není pro funkci důležité. Zatím ze sebe jen děláte trotla, který se tváří že nevidí, i když jsou fakta zjevná.
-
Lol Phirae (neregistrovaný)
Pokud něco soud neřešil, tak je to problém soudruha Ellisona. Asi měl zrovna moc napilno s nákupem další soutěžní jachty, tak neměl čas posílat důkazy. Pááá, brouku. :-P
P.S. Ani tvůj mindrák z toho, že tě nepřizvali do poroty jako génia v oboru tady nevyřešíme. (Mimochodem, od toho tam porota není, běž to nastudovat.)
-
Sten (neregistrovaný)
Na prvním místě ty zdrojáky od Googlu mají importy ve stejném pořadí jako ty od Sunu. To bude jistě náhoda, že?
Ano, většina UI importy automaticky řadí podle abecedy, pak jsou celkem logicky i stejně seřazené.
A že mají metody ve stejném pořadí; to se jistě také stalo náhodou
Ano, neboť to akorát znamená, že implementovali nějaký interface v UI. Opět to UI automaticky řadí stejně, jako je to v interfacu deklarované.
A když se kouknete na dokument číslo 2, stranu 2, uvidíte public aclImpl, kde pořadí operací není důležité, ale autor to napsal zrovna náááhodou úplně stejně jako Sun Microsystems.
Co se tam v tom konstruktoru dělá? Inicializují se členské proměnné v pořadí, v jakém jsou deklarované, a poté se volá metoda. Nic, co by bylo mezi dobrými programátory nějak neobvyklé a co by UI automaticky nepředgenerovalo.
O stránku dále vidíme getPermissions. Wow, nááádohou se autor strefil do pořadí enumeration2, enumeration3, enumeration, enumeration1, enumeration4, enumeration5, i když na pořadí nijak nezáleží.
Na pořadí u
enumeration4aenumeration5samozřejmě záleží, protože se počítají z předchozích, to ostatní je celkem běžné řazení, jaké by udělal každý normální programátor. Jediné, co je trochu podivné, jsou jména těch proměnných, ale protože to levé je dekompilované, tak tam ta jména proměnných někdo při dekompilaci dopisoval. Někdo ze Sunu. NavícAclImpl.javapochází z Apache Harmony, ne od Googlu.TL;DR: Lael Ophir zřejmě nikdy neprogramoval v Javě, jinak by sem nedával „důkazy“, které velmi podobně vytvoří Eclipse nebo IntelliJ i bez dekompilace.
-
Lael Ophir (neregistrovaný)
Pořadí importů hraje roli. Ale souhlas, v obou případech jsou abecedně řazené (nedošlo mi, že malá písmena řadí za velká).
Pokud by šlo o clean room reimplementaci, nemá tam deklarace interface od Sunu co dělat.
Na vzájemném pořadí enumeration4 a enumeration5 záleží, na zbytku ne, na jménech také ne. Shodné pořadí operací tam, kde na něm nezáleží, zjevně indikuje krádež zdrojáku.
Ad Jediné, co je trochu podivné, jsou jména těch proměnných, ale protože to levé je dekompilované, tak tam ta jména proměnných někdo při dekompilaci dopisoval - omyl. To vlevo je přímo výsledek dekompilace nástrojem jad. Právě jsem si stáhnul JDK 1.5.0.22 a jad, a vylezla z toho přesně tahle jména proměnných. Že by se do nich někdo náhodou strefil? :)
Shrnuto, podtrženo: nedal jste si dost práce to ověřit.
Resources:
JDK 1.5.0.22:
http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase5-419410.html
jad:
http://web.archive.org/web/20080214075546/http://www.kpdus.com/jad.html#download
Rozbalte si kompletně JRE. Soubor ...\core2\lib\rt.pack rozbalte pomocí unpack200.exe, klidně z recentní verze Javy, formát se neměnil. Výsledný soubor ...\core2\lib\rt\sun\security\aclAclImpl.class sjeďte decompilerem jad. -
Lael Ophir (neregistrovaný)
Google má zjevně dodnes ve zdrojácích Androidu ukradený kód. Jestli je nebo není nainstalovaný na tom či onom telefonu, to je přece úplně jedno. Nebo myslíte že je OK prostě dekompilovat cizí bytecode a zahrnout ho do svého projektu?
https://android.googlesource.com/platform/libcore/+/a0881d052ee72e3f7e773374e9b1aa75fbd6be4c/support/src/test/java/org/apache/harmony/security/tests/support/acl/AclImpl.javaMimochodem podle Apache Software Foundation soubor PolicyNodeImpl.java nepochází z projektu Harmony (v době jejich vyjádření ještě nešlo o AclImpl.java, ale nejspíš by prohlásili totéž).
http://blogs.apache.org/foundation/entry/read_beyond_the_headers
