unknown

Kampen om Java er ved at nå sin ende

Oracle og Google har i næsten 10 år kæmpet om Java – og det er nu ved at få sin ende om en måneds tid.

Det er den amerikanske højesteret der nu skal tage stilling til sagen og de to parter har nu netop indleveret begge deres synspunkter til sagen.

Dermed ser forløbet, der startede tilbage i 2010, ud til at være tæt på en konklusion om, hvorvidt Googles brug af Oracles Java hører under ”fair-use” eller ej.

Kernen i sagen er, at Google har udviklet deres egen udgave af Java og bruge den i Android, men samtidig har de bibehold hele miljøet – det vil sige at system, funktionskald og bytecode, fungerer  præcis som Oracles Java.

Oracle mener derfor at Google har forbrudt sig mod patenter og ophavsret, i forbindelse med udviklingen af Googles egen Java.

Googles forsvar skulle angiveligt være, at det bare er bedre når der er åbne standarder og at man jo skal tænke på udviklerne – og anklager Oracle for at ville gå efter monopolagtige tilstande.





Gå til bund
Gravatar

#1 antimate 17. feb. 2020 06:55

tænk. snart er de folk der satte dette igang gået på pension xD sikke noget rod.
Gravatar

#2 larsp 17. feb. 2020 07:15

Det er en kompliceret sag og hvad angår ophavsrettigheder, så er det ikke i orden hvis Google har planket closed source API ejet af SUN uden at betale. Men hvis APIen var open source er det selvfølgelig i orden. Det er svært at blive klog på præcis hvor sandheden ligger imellem de to punkter.

Hvad angår patenterne i sagen... burn the whole system down!! De skulle aldrig have eksisteret i første omgang. Fra https://en.wikipedia.org/wiki/Google_v._Oracle_Ame... :
By the time of trial, Oracle's patent case comprised claims from two patents, 6,061,520 (Method and system for performing static initialization),[27] and RE38104 (Method and apparatus for resolving data references in generated code)

Latterligt
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#3 EmilKampp 17. feb. 2020 07:24

Nogen gange er kompliecerede problemstillingere nemmere at forholde sig til, hvis man driver dem til ekstremer. En verden, hvor alt er patenteret, eller en verden, hvor intet kan patenteres.

CGP Grey har en video om copyright, men som man kan argumentere for er effektiv patent på kreativitet:

Personligt kommer jeg frem til en anden konklusion end CGP, og derved er jeg også absolut imod patenter.

Og, hvis man gerne vil diskutere nuanceret, så kan man så trække ekstremiseringen(?) tilbage. Personligt ankommer jeg til at jeg godt kan kompromitere på mange områder med patenter, men aldrig, når det kommer til sundhed og liv. Patenter på medicin, maskiner og andet designet til at redde liv er absolut ufatteligt at man må have patent på. Effektivt kan man slå folk ihjæl med patenter.
Gravatar

#4 larsp 17. feb. 2020 07:43

EmilKampp (3) skrev:
Patenter på medicin, maskiner og andet designet til at redde liv er absolut ufatteligt at man må have patent på. Effektivt kan man slå folk ihjæl med patenter.

Dem der forsvarer patenterne vil sige at de var medvirkende til at medicinen i det hele taget blev udviklet. Uden patenterne ville der ikke have været investeret i første omgang.

Jeg ved ikke om det er rigtigt. Hvis der ikke fantes patenter ville der stadig have været udviklet medicin, bare med en helt anden forretningsmodel end den der er i dag. Se bare på IT verdenen. Der blev innoveret og udviklet teknologi i rekord tempo i løbet af 30 - 40 år. Og det var IKKE pga. patenter.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#5 KimMadsen 17. feb. 2020 08:36

larsp (4) skrev:
Se bare på IT verdenen. Der blev innoveret og udviklet teknologi i rekord tempo i løbet af 30 - 40 år. Og det var IKKE pga. patenter.


Det er så ikke helt korrekt :)
Der er oceaner af patenter i IT, på software algoritmer, på hardware metoder, på silicium udvikling og meget mere.

Det er, efter medicinal industrien, nok een af de mest "regulerede" (i forhold til patenter og andre beskyttelser) områder.
Gravatar

#6 arne_v 17. feb. 2020 19:36

#0

Opsummeringen er ikke helt præcis. Men det er også en lidt kompleks sag.

Avarsel - den her post bliver lang.

Også bemærk at nedenfor vil Android blive brugt som term for app environment i Android ikke om hele Android.

Først skal vi lige have konteksten på plads.

Java

Java er flere ting:
* Java sproget
* Java compiler
* Java byte code
* Java virtual machine
* Java standard bibliotek

Udvikling består i at:
* udvikleren skriver sit program i Java sproget
* Java compileren oversætter til Java byte code
* Java virtual machine udfører Java byte code (vil normalt JIT compile den til native kode i memory og eksekvere den)
* programmet bruger Java standard bilbliotek (ca. 4000 klasser med ca. 110000 metoder)

Android

Android er anderledes.

Udviklerene starter med de samme to trin:
* udvikleren skriver sit program i Java sproget
* Java compileren oversætter til Java byte code

Men derefter er det anderledes:
* Java byte code oversættes til Android byte code [et fundamentalt andereldes format - JVM er en stak maskine, Android er en register maskine]
* næste trin er forskellig alt efter Android version:
- ældre Android versioner: Dalvik virtual machine udfører Android byute code (bruger også JIT compilering til native kode i memory)
- nyere Android versioner: Android byte code compiles til native kode som køres i ART miljøet

Android kommer med et standard bibliotek som består af ca. 2/3 af Java's standard bibliotek + en masse Android specifikke klasser og metoder.

Fordi Android ikke har en Java virtual machine og ikke implementerer hele Java standard bibliotek, så kan Android ikke certificeres som Java og er derfor ikke Java.

Og Google er da også meget omhyggelig med ikke at hævde at Android er Java.

Sagen

Oracle sagsøgte Google for 3 ting:
1) Krænkelse af ophavsret på nogle små stumper kode fra Java
2) Krænkelse af Oracle patenter
3) Krænkelse af ophavsret på API i Java standard bibliotek

Re 1)

Den del blev hurtigt ordnet.

Det drejede sig om nogle unit tests og et enkelt stykke runtime kode.

Google fjernede unit testene og det stykke kode og undskyldte.

Og runtime koden var altså det rene ingenting.

Joshua Bloch havde mens han var hos SUN skrevet 9 linier kode til SUN Java og OpenJDK og havde kopieret dem da han var hos Google.


private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");
if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);
if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);
}


Dommeren mente ikke at det var noget.

Og Oracle accepterede det.

Re 2)

Oracle startede med at anklage Google for at have krænket 10 patenter.

Og mens en certficeret Java implementation kan bruge disse patenter (det er et krav for at få noget ind i Java at der gives tilladelse til brug af nødvendige patenter), så kan Android ikek fordi det jo ikke er en certificeret Java.

For at ekspedere sagen bad dommeren Google udvælge de to "bedste" sager og så ville man fokusere på dem.

Det gjorde man men dommeren kom hurtigt frem til at der ikke var kød på den sag.

Og Oracle accepterede dette.

Re 3)

Resten af sagen har kørt på API.

Oracle og Google er sådan set enige om fakta:
* Android standard library har genbrugt store dele af Java API
* Genbruget er sket ved at kode til specifikation ikke ved at kopiere kode fra Java standard bibliotek

Faktisk havde Google slet ikke selv skrevet koden - de havde hapset kode fra et open source projekt Apache Harmony.

Forskellen er at:
* Google mener at API'er frit kan implementeres enten fordi de ikker er copyrightet eller fodi de falder ind under fair use
* Oracle mener at Google har krænket deres ophavsret og vil have 8 milliarder dollars i erstatning

Og den sag har kørt længe i retssystemet.

Først vurderede retten at API'er ikke var dækket af copyright.

Appel retten omstødte det og erklæerede at API'er dækket af copyright og sendte sagen tilbage til retten.

Retten vurderede så at brugen af API'er faldt ind under fair use.

Appel retten omstødte dette og erklærede at det ikke er fair use og sendte sagen tilbage til retten.

Og nu er både spørgsmålet om copyright og spørgsmålet om fair use på vej til højesteret.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#7 arne_v 17. feb. 2020 19:55

(fortsat)

Sagen hænger meget på kendskab til software versus regler der er vedtaget for helt andre ting end software.

Sådan lidt simplificeret går diskussionen som:

software person: hele ideen i API'er er at alle kan bruge dem for at sikre kompabilitet, så selvfølgelig er der ikke copyright på API'er

jurist: kravene til copyright er "creative work" og "tangible form" - er API'er dette?

software person: jo men ...

jurist: ingen men her

software person: hvis API'er er copyrighted så må det være fair use at bruge dem - det er jo hele meningen med dem

jurist: tjener Google penge på det her? er det en stor klump der er genbrugt?

software person, ja og ja, men ...

jurist: ingen men her

Nu må vi se om højesteret lytter til software personer eller udelukkende kigger på juridiske formuleringer fra længe før software blev opfundet.

Det har ingen umiddlebar betydning for Java.

Java har åbenlyst ret til at bruge Java API.

Det har ingen umiddlebar betydning for Android.

Android har for lang tid siden skiftet fra Apache Harmony som er en uafhængig implementering til OpenJDK som er under GPL licens fra Oracle.

Google og Oracle har 8 milliarder gode grund til at ønske at vinde.

Det meste af software verdenen støtter Google inkl. IBM, Redhat og MS.

De kan godt se at copyright på API'er med det formål at forhindre genbrug af API'er vil gøre det meget vanskeligere at udvikle software.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#8 larsp 18. feb. 2020 08:35

God udredning, tak for det, Arne.

Jeg hepper også på at Google/Android vinder denne sag, for alles bedste, og eneste grund til at heppe på Oracle er et morbidt ønske om at brænde hele copyright/patent/juristeri systemet ned inden for software.

Vil dog kommentere på én ting:
software person: hvis API'er er copyrighted så må det være fair use at bruge dem - det er jo hele meningen med dem

Forstår ikke denne. Det er APIer der definerer arkitekturen i et system og de er reelt resultatet af mange dybe overvejelser og trial and error indtil man rammer rigtigt. Det er en vægtig del af softwaren. At implementere en API er egentlig bare robot arbejde. Det svære er at udarbejde en god API.

Så hvis evil corporation X udvilker en genial API og vælger en licens der ikke tillader kopiering, så er kan jeg ikke se at man bare kan kopiere den og sige fair use.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#9 arne_v 18. feb. 2020 15:24

larsp (8) skrev:

Vil dog kommentere på én ting:
software person: hvis API'er er copyrighted så må det være fair use at bruge dem - det er jo hele meningen med dem

Forstår ikke denne. Det er APIer der definerer arkitekturen i et system og de er reelt resultatet af mange dybe overvejelser og trial and error indtil man rammer rigtigt. Det er en vægtig del af softwaren. At implementere en API er egentlig bare robot arbejde. Det svære er at udarbejde en god API.

Så hvis evil corporation X udvilker en genial API og vælger en licens der ikke tillader kopiering, så er kan jeg ikke se at man bare kan kopiere den og sige fair use.


Det er Oracle's pointe: API er intellektuel ejendom ligesom selve koden.

Men prøv og led efter eksempler på:
* licens på kode der ikke giver tilladelse til brug
* licens på kode der giver tilladelse til brug
* licens på API der ikke giver tilladelse til brug
* licens på API der giver tilladelse til brug

Jeg forventer at du finder millioner, millioner, ingen og ingen.

Copyright beskyttelse af API er en ny ting.

Og der er kendte eksempler på at det har været accepteret at genimplementere API.

Det mest kendte eksempel er genimplementeringen af BIOS API uden brug af IBM kode som tillod 3. part at bygge IBM kompatible PC'ere.

Og der er masser af eksempler indenfor software på genbrug af API for at gøre det nemmere for udviklere.

Formaterede strenge

For mange år siden introducerede C *printf funktionerne med en format streng og et variabelt antal argumenter. Der er ikke noget som helst magisk ved de valgte format direktiver: %d for integer, %s for string, %f for floating point - man kunne lige så godt have valgt #n, #t og #x. Men man valgte altså dem man valgte.

Og andre sprog har kopieret. Java PrintStream printf. PHP sprintf. Python funky % operator.

Og alle der har lært C printf kan finde ud af at bruge det.

Selv de lidt mere avancerede former som %08X og %10.2f.

.NET valgte at være anderledes og alle kan godt huske at {0} er første argument og {1} er andet argument. Men meget få (og ikke mig) kan huske at %08X er {0:X8} og %10.2f er {0,10:F2} uden at slå det op.

VMS FAO service valgte at være anderledes - %d er !SL, %s er !AS, %08X er !XL og der er (så vidt jeg ved) ingen ekvivalent for %10.2f og ingen kan huske det.

Genbrug af C format strenge gør det nemmere for udviklere. De kan genbruge hvad de en gang har lært om format strenge.

Og ISO C group har altså ikke sagsøgt alle de andre.

Tråd API

Diverse tråd API er forbløffende ens.

C POSIX: pthread_create, pthread_join
Java: new Thread, .start, .join
.NET: new Thread, .Start, .Join
C++ Boost & 11: new thread, ->join
Python: Thread, .start, .join

Igen nemt for udviklere. Brug for tråde i nyt sprog? Find tråd klassen og find start og join metoderne og du er klar.

OpenGroup har ikke sagsøgt alle de andre.

XML parsning med W3C DOM

Man opbygger et document og så:

Java: .getElementsByTagName/.getChildNodes/.getFirstChild
.NET: .GetElementsByTagName/.ChildNodes/.FirstChild
PHP: ->getElementsByTagName/->childNodes/->firstChild
Delphi: .GetElementsByTagName/.ChildNodes/.FirstChild
Python: .getElementsByTagName/.childNodes/.firstChild

Har man lært at navigere et XML dokument i et sprog, så kan man nemt gøre det samme i et andet sprog.

W3C har ikke sagsøgt nogen.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#10 arne_v 18. feb. 2020 15:30

#8

Problemet for Google og andre er at copyright regler er lavet for bøger og musik.

For kode er den traditionelle ekvivalens ret klar:

Kopiere foobar.c og bruge den i ens program svarer til at lave en fotokopi af en bog eller brænde en kopi af musik CD.

Det virker rimeligt logisk og er bredt accepteret.

Men hvad er det ekvivalente af et API for bøger og musik??

Kan man tage copyright på at have en krimi hvor den engelske godsejer er blevet myrdet i et lukket rum og det er butleren som har gjordt det??

:-)

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 arne_v 18. feb. 2020 15:36

larsp (8) skrev:

Det er APIer der definerer arkitekturen i et system og de er reelt resultatet af mange dybe overvejelser og trial and error indtil man rammer rigtigt. Det er en vægtig del af softwaren. At implementere en API er egentlig bare robot arbejde. Det svære er at udarbejde en god API.


Jeg er helt enig i at API er vigtig og at det er svært at lave gode API.

Jeg er ikke enig i at API definerer arkitekturen. Jeg vil hævde at et godt API er uafhængig af den bagvedliggende arkitektur.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 arne_v 18. feb. 2020 15:45

arne_v (7) skrev:

Android har for lang tid siden skiftet fra Apache Harmony som er en uafhængig implementering til OpenJDK som er under GPL licens fra Oracle.


Rettelse:

Nogle dele af OpenJDK er under GPL - andre dele af OpenJDK er under "GPL med classpath exception".

Og de relevante dele for den her diskussion er under "GPL med classpath exception".

Og ja - det gør en forskel.


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#13 arne_v 18. feb. 2020 17:18

#bil analogi

Lad os tage en bil analogi.

:-) :-) :-)

Copright på kode er ligesom beskyttelse af mekanisk design af gearkasse, hvilken tandhjul og hvordan de er sat sammen.

Copyright på API er ligesom beskyttelse af skifte mønster:

1 3 5
2 4 R
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#14 larsp 18. feb. 2020 18:15

arne_v (11) skrev:
Jeg er ikke enig i at API definerer arkitekturen. Jeg vil hævde at et godt API er uafhængig af den bagvedliggende arkitektur.

Det kommer vel an på hvad man præcis forstår ved et application programming _interface_. Mine tanker var hen af alle de interfaces der nu engang er i et system, inklusiv hvordan software moduler interfacer hinanden. Jeg vil mene at de vedtagede interfaces der er mellem komponenterne i et system er lig med arkitekturen. Den måde du beskriver API er kun det yderste lag af interfacing mellem et system og resten af verdenen. Men er Java library APIerne ikke mere end det, det er vel interne grænseflader i koden?

Som embedded udvikler tænker jeg også på alle hardware protokollerne. Det er jo elektriske interfaces man skal programmere op af... Er det APIer? Det er nok at vride termerne lidt men det minder om det, for det er grænseflader man skal arbejde op imod i følge en vedtaget specifikation.

Og der er bestemt både åbne elektriske protokoller (USB, PCI, sata etc etc) og lukkede. F.eks. I2C der var licensbegrænset i mange år selvom det er en ret enkel elektrisk grænseflade. Meget analogt til dine eksempler var de andre chip producenter nød til at kalde deres "I2C kompatible" noget andet end I2C, f.eks. Atmel kaldte det et "two wire interface" og så var de åbenbart fri for legale problemer.

Min personlige holdning er at ønsket om at lukke ned og beskytte den slags er kontraproduktivt og alene gør at ens produkt bliver bekrænset i anvendelse og success. Men jeg mener også at der er en plads i verden til closed source software, så... I'm on the fence...
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#15 arne_v 18. feb. 2020 18:26

#14

Jeg er en meget "soft" person.

:-)

Så ja jeg tænker meget på uafhængighed mellem API og implementation.

For call API'er tænker jeg API med kun interfaces, simple data klasser og factory klasser. Klient koden ser ikke noget af implementeringen. Og man kan totalt omskrive implementeringen uden ændringer i klient koden. Så man kan skifte fra at gemme data i XML filer til at gemme data i en database uden at klient koden opdager det.

For web service API'er tænker jeg domæne specifikke men implementations uafhængige service definitioner. Klient koden ved ikke om den service er implementeret i ASP.NET eller Java EE eller PHP. Og man kan skifte implementerings teknologi uden at klient koden opdager det.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#16 arne_v 18. feb. 2020 18:35

larsp (14) skrev:

Men er Java library APIerne ikke mere end det, det er vel interne grænseflader i koden?


Nu har jeg jo ikke checket al koden, men udfra Oracles juridiske strategi, så vil jeg formode at det kun er public API - public klasser og public metode signaturer og public felter der er genimplementeret men at alt non-public er implementeret fra scratch uden at kigge på anden kode aka "clean room implementation".

(bortset fra de tidligere omtalte 9 linier)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#17 arne_v 20. feb. 2020 19:01

En anden ting uden juridisk betydning men med en vis moralsk betydning er at Oracle ikke har lavet al arbejdet bag de API'er.

Det arbejde laves af arbejdsgrupper under JCP. Oracle deltager i disse, men det samme gør mange andre firmaer.

Copyrighten tildeles Oracle (tidligere SUN), fordi det gør det nemmere at håndtere krænkelser.

Det er der ikke noget specielt i. For GNU software tildeles copyrighten normalt tiL FSF af samme årsag.

Men hvis det ender med at Oracle får milliarder i erstatning for ulovlig brug af arbejde som Oracle kun har lavet måske 15-25% af, så vil de firmaer som har lavet de resterende 75-85% og som for manges vedkommende støtter Google nok føle sig lidt til grin.

Eksempler:

Java 14 (JSR 389):

Expert Group

Simon Ritter (Azul Systems)
Manoj Palat (Eclipse Foundation)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Iris Clark (Oracle)
Brian Goetz (Oracle)

Java 13 (JSR 388):

Expert Group

Simon Ritter (Azul Systems)
Manoj Palat (Eclipse Foundation)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Volker Simonis (SAP SE)
Iris Clark (Oracle)
Brian Goetz (Oracle)

Java 12 (JSR 386):

Expert Group

Simon Ritter (Azul Systems)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Volker Simonis (SAP SE)
Iris Clark (Oracle)
Brian Goetz (Oracle)

Java 11 (JSR 384):

Expert Group

Simon Ritter (Azul Systems)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Volker Simonis (SAP SE)
Iris Clark (Oracle)
Brian Goetz (Oracle)

Java 10 (JSR 383):

Expert Group

Simon Ritter (Azul Systems)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Volker Simonis (SAP SE)
Iris Clark (Oracle)
Brian Goetz (Oracle)

Java 9 (JSR 379):

Expert Group

Simon Ritter (Azul Systems)
Tim Ellison (IBM)
Andrew Haley (Red Hat)
Volker Simonis (SAP SE)
Iris Clark (Oracle)
Mark Reinhold (Oracle)

JPMS (JSR 376) [releaset med Java 9]:

Expert Group

Neil Bartlett (Paremus)
Wayne Beaton (Eclipse)
Hans Dockter (Gradleware)
Tim Ellison (IBM)
Rémi Forax
Bob Lee
David Lloyd (Red Hat)
Mark Reinhold (Oracle)
Robert Scholte


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#18 arne_v 20. feb. 2020 20:04

Og mens IBM og Microsoft som sagt støtter Google så har Oracle fået støtte fra justitsministeriet og musikindustrien.

Kilde:
https://thehill.com/policy/technology/483750-trump...

(og ganske vist har musikindustrien stor interesse i copyright, men spørgsmålet om hvorvidt API'er er copyrighted og ikke under fair use er lidt udenfor deres område)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#19 larsp 21. feb. 2020 08:38

arne_v (17) skrev:
Men hvis det ender med at Oracle får milliarder i erstatning for ulovlig brug af arbejde som Oracle kun har lavet måske 15-25% af, så vil de firmaer som har lavet de resterende 75-85% og som for manges vedkommende støtter Google nok føle sig lidt til grin.

God pointe.

#18 Det er meget sjovt at læse udtalelsen i den historie: https://www.supremecourt.gov/DocketPDF/18/18-956/1... der på typisk amerikansk vis er formatteret med så lidt tekst pr. side som muligt for at puste antallet af sider op, haha.

Når dommeren/dommerne skal vurdere en sag som denne går jeg ud fra at de kun skal vurdere sagen i sig selv isoleret set. Eller er det "okay" for dommere at tage i betragtning hvilke konsekvenser en dom måtte have for resten af industrien? Det forekommer mig at være noget de ikke bør tage med i vurderingen, eller hvad?
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#20 arne_v 21. feb. 2020 13:39

larsp (19) skrev:

Når dommeren/dommerne skal vurdere en sag som denne går jeg ud fra at de kun skal vurdere sagen i sig selv isoleret set. Eller er det "okay" for dommere at tage i betragtning hvilke konsekvenser en dom måtte have for resten af industrien? Det forekommer mig at være noget de ikke bør tage med i vurderingen, eller hvad?


USA's domstole er helt klart mere "kreative" end danske ditto.

Der er vel to juridiske retninger i den amerikanske højesteret:
* man kigger på lovens tekst og fortolker baseret på hvad dem som vedtog loven mente med de ord
* man kigger på lovens tekst og fortolker baseret på hvad ideen bag loven er

De første vil tænke som: hvis jeg rejste tilbage i tiden og forelagde problemstillingen for de de lovgivere som lige havde vedtaget de relevante love hvordan ville de mene at loven skulle anvendes.

De sidste vil tænke som: hvad er formålet med disse love og hvilken fortolkning af loven er bedst til at nå disse mål.

Mit gæt (men jeg er ikke jurist og slet ikke ekspert den her slags) er at den første gruppe sandsynligvis vil støtte Oracle mens den anden gruppe vil være meget i tvivl.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login