mboost-dp1

- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Her skal det så lige siges at manden bag FOSS Patents bestemt ikke er en Google fanboy, men nærmere det modsatte (hvad det så end hedder). Og selv om han virker dygtig og har en masse erfaring inden for emnet er han altid ude med riven efter google af en eller anden grund. Har har ikke lige en række links klar, men der har allerede været flere episoder hvor han påstår ting som er direkte lodret forkerte.
Det betyder ikke han ikke har ret her - det er jeg ikke uddannet nok til at udtale mig om, men man skal lige have det i baghovedet inden man lytter til ham
Det betyder ikke han ikke har ret her - det er jeg ikke uddannet nok til at udtale mig om, men man skal lige have det i baghovedet inden man lytter til ham
#2; jeg skulle mene at den officielle term for det modsatte af en fanboy er en "hater" ;-)
#2 - Florian Müller er ham som forklarede os tidligere, at Google bryder nogle licensregler vedr. Linux kernelen og Android. Problematiken døde så fuldstændigt hen så vidt jeg husker...
Det her lyder som det samme...
Nu kender jeg ikke præcist systemet, når det gælder fratagelse af licensrettighederne, men for mig lyder det rigtigt underligt, at man "let" får frataget retten til at videredistribuere Linux, men at det skulle være utroligt svært at få retten igen... Skal alle bidragsydere ikke sige ja til, at et firma må videredistribuere til at starte med? Og desuden, hvad hvis et af de firmaer, der bruger Android, er bidragsyder?
Det her lyder som det samme...
Nu kender jeg ikke præcist systemet, når det gælder fratagelse af licensrettighederne, men for mig lyder det rigtigt underligt, at man "let" får frataget retten til at videredistribuere Linux, men at det skulle være utroligt svært at få retten igen... Skal alle bidragsydere ikke sige ja til, at et firma må videredistribuere til at starte med? Og desuden, hvad hvis et af de firmaer, der bruger Android, er bidragsyder?
Synes jeg kan huske at de har været ude i det her før og viste det sig ikke dengang at Google hellere end gerne ville dele kildekoden til Android styresystemet, men at HTC ikke var interesserede i at dele deres kildekode til Sense og lignende? Eller er det mig der husker forkert?
Der er jo heller ikke et krav om at hvis du installere et program på en linux distribution, så skal producenten af programmet frigøre sin kildekode.
Der er jo heller ikke et krav om at hvis du installere et program på en linux distribution, så skal producenten af programmet frigøre sin kildekode.
Lad mig citere hvad licensen siger.Darwind (5) skrev:Nu kender jeg ikke præcist systemet, når det gælder fratagelse af licensrettighederne, men for mig lyder det rigtigt underligt, at man "let" får frataget retten til at videredistribuere Linux
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
Så hvis du en gang har distribueret Linux uden at overholde alle licensens krav, så har du i princippet allerede mistet retten til at distribuere koden i fremtiden.
Ja alle bidragsydere skal give dig lov til at distribuere koden. Men det har de allerede gjort ved at publicere deres kode under GPL licensen. Men dette gælder kun så længe du overholder licensen. Har du overtrådt licensen og dermed mistet rettighederne må du først distribuere koden igen når du igen har erhvervet dig tilladelse fra alle bidragsydere. Generhvervelse af denne ret efter et brud på licensen står der til gengæld intet om, så det får du ikke per automatik, og du skal derfor selv gøre arbejdet med at få tilladelse fra hver enkelt rettighedshaver. Sidstnævnte er der ingen der realistisk kan gennemføre.Darwind (5) skrev:det skulle være utroligt svært at få retten igen... Skal alle bidragsydere ikke sige ja til, at et firma må videredistribuere til at starte med?
Der er et par andre veje du måske kan få licens til at distribuere igen. Hvis der i mellemtiden er blevet ændret tilstrækkeligt på koden kan det måske fortolkes som et nyt produkt og ikke det samme gamle produkt som du mistede retten til at distribuere. Præcist hvor grænsen for det går er ikke helt klart for mig, men det er næppe noget man har lyst til at vente på.
Derudover gælder fratagelse af retten til at distribuere selvfølgelig kun den part der overtrådte licensen. Der står vist ikke noget om hvilke parter der kan være licenshavere. Så muligvis kunne en virksomhed generhverve retten til at distribuere ved at sige at overtrædelsen blev begået af en underafdeling af virksomheden uden accept oppefra og dermed sige at det kun var den underafdeling der mistede retten. Derefter er det jo nemt at nedlægge den underafdeling og så oprette en ny til at overtage arbejdet. Om den holder i retten er ikke til at sige.
Indtil nu har udviklerne af GPL software været meget large overfor overtrædelser. Der er stort set aldrig nogen virksomhed som er blevet trukket i retten for overtrædelser. Og dem som har begået overtrædelser bliver som regel ikke stillet til ansvar for det hvis blot de efterfølgende retter sig ind.
Man kan hente kernel kildekoden til samtlige HTC, LG, bla bla bla telefoner på deres hjemmeside. Der er altså kun linux kernel der er omfattet af GPL.
Resten af android (framework, UI osv) er under apache og dermed kan de selv bestemme om de vil frigive deres tilpasninger eller ej.
Resten af android (framework, UI osv) er under apache og dermed kan de selv bestemme om de vil frigive deres tilpasninger eller ej.
gensplejs (11) skrev:Man kan hente kernel kildekoden til samtlige HTC, LG, bla bla bla telefoner på deres hjemmeside. Der er altså kun linux kernel der er omfattet af GPL.
Resten af android (framework, UI osv) er under apache og dermed kan de selv bestemme om de vil frigive deres tilpasninger eller ej.
Nemlig, det har jo slet ikke noget at gøre med den licens der omtales i artiklen. Ellers måtte man jo heller ikke levere computere med Linux præinstalleret. Den GPL er jo skrevet for at beskytte udviklerne.
debichu (8) skrev:Jeg forstår ikke problemet? Google frigiver jo Android via Apache licensen og ikke GPLv2.
Hm.
Android OS kerne er under GPL. Da den er baseret på Linux som bruger GPL skal den være under GPL.
Android en hel masse andet som Google har lavet fra bunden af er under Apache licens.
debichu (8) skrev:Kom nu ind i kampen, Florian Müller... Suk!
Og hvorfor mener du at licensen for de dele af Android som ikke er Linux skal anvendes på de dele af Android som er Linux?
#0 skrev:
Sker dette ikke, kan firmaet blive frataget retten til at distribuere Linux.
Sker dette, vil det være meget svært at få sin licens igen, da alle som bidrager til Linux-kernen skal give deres accept.
kasperd (10) skrev:Har du overtrådt licensen og dermed mistet rettighederne må du først distribuere koden igen når du igen har erhvervet dig tilladelse fra alle bidragsydere.
Det er jo en ret væsentlig juridisk påstand.
Men er der noget belæg for den?
kasperd (10) skrev:Generhvervelse af denne ret efter et brud på licensen står der til gengæld intet om, så det får du ikke per automatik, og du skal derfor selv gøre arbejdet med at få tilladelse fra hver enkelt rettighedshaver.
Det er ikke indlysende for mig at det at der ikke står noget om generhvervelse i licensen gør at man aldrig kan generhverve licensen fremfor at man generhverver licens når man er i compliance.
Når der ikke står noget kan det selvfølgelig blive rettens afgørelse.
Men jeg vil tro at der er stor præcedens for at rettigheder ikke permanent er tabt ved brug på betingelserne men kun er tabt så længe man ikke overholder betingelserne.
Der mig bekendt aldrig været en retssag på det område. Der har blot endnu ikke været nogen udviklere som har haft lyst til at gå så vidt. Målet er at få virksomhederne til at rette sig ind, og derfor giver det ikke mening for udviklerne at håndhæve denne ophævelse af rettighederne hvis virksomheden gør et ærligt forsøg på at rette op på deres fejltrin.arne_v (14) skrev:Men jeg vil tro at der er stor præcedens for at rettigheder ikke permanent er tabt ved brug på betingelserne men kun er tabt så længe man ikke overholder betingelserne.
Men jeg mener formuleringen "will automatically terminate your rights under this License." er ret klar. Rettighederne er ophørt, og der står intet om at få dem igen.
Nogle mener virksomhederne hidtil er sluppet lidt for let. Men på den anden side er der vist ingen udviklere af GPL software som ønsker de helt skal miste retten til at anvende softwaren.
Personligt mener jeg et passende krav er at de retter op på deres fejl og frigiver den kildekode de skulle have frigivet i første omgang, plus at de betaler et mindre beløb som kompensation, som passende kan finansiere udvikling af mere opensource software. Dog er sådan en kompensation svær at beskrive i licensen.
kasperd (16) skrev:Men jeg mener formuleringen "will automatically terminate your rights under this License." er ret klar. Rettighederne er ophørt, og der står intet om at få dem igen.
Korrekt.
Men hvorfor skulle det betyde at man ikke får licensen tilbage når man er compliant?
Der må være tonsvis af retslige afgørelser omkring ulovlige forhold der er gjordt lovlige senere.
Banalt eksempel: jeg stiller et brændeskur op for tæt på naboen, kommunen siget at det ikke er lovligt, jeg flytter brændeskuret - så er det lovligt - jeg er ikke dårligere stillet fordi brændeskuret har stået ulovligt.
Jeg har svært ved at tro at det for GPL skulle gælde at man er ringere stillet ved engang i fortiden at have overtrådt den.
Windcape (17) skrev:Denne gang handler de om at de har distributeret Honeycomb, som closed-source, til trods for at der benyttes GPL kode.
Ja.
Men den kendsgerning at Florian tidligere har været ude med en bogus påstand (jeg vil mene at Linus er autoritativ kilde) giver jo anledning til en del skepsis omkring nye påstande.
For at følge arne_v's eksempel med relevante posts, så er her lidt information omkring kernel ift. Florian's krav:
Google udgiver pænt ALT GPL kode så Google har intet problem som sådan.
Problemet er bare at når vi snakker embedded devices (som android telefoner og tablets nu om dage praktisk talt er), er det ikke bare liiige nok at Google udgiver kildekoden.
Hver gang en ny vendor laver f.eks. en ny tegra2 tablet (Motorola, Toshiba, LG, ASUS osv), så skal der meget væsentlige ændringer til i koden for at linux kernen overhovedet kan starte op på systemet.
Det er disse ændringer der er meget relevant i denne sammenhæng. Motorola,LG og ASUS har i denne sammenhæng været rigtigt gode til at give kode rimeligt hurtigt, mens f.eks. Toshiba med deres thrive tablet stadigvæk ikke har udgivet nogen koder og pænt bare henviser til en japansk email adresse som aldrig svarer....
Desværre er der en del af den slags vendors der bare udskyder i en uendelighed og nægter at følge licensen.
Hvorvidt Florian så rent faktisk har ret har jeg så ingen idé om...
Google udgiver pænt ALT GPL kode så Google har intet problem som sådan.
Problemet er bare at når vi snakker embedded devices (som android telefoner og tablets nu om dage praktisk talt er), er det ikke bare liiige nok at Google udgiver kildekoden.
Hver gang en ny vendor laver f.eks. en ny tegra2 tablet (Motorola, Toshiba, LG, ASUS osv), så skal der meget væsentlige ændringer til i koden for at linux kernen overhovedet kan starte op på systemet.
Det er disse ændringer der er meget relevant i denne sammenhæng. Motorola,LG og ASUS har i denne sammenhæng været rigtigt gode til at give kode rimeligt hurtigt, mens f.eks. Toshiba med deres thrive tablet stadigvæk ikke har udgivet nogen koder og pænt bare henviser til en japansk email adresse som aldrig svarer....
Desværre er der en del af den slags vendors der bare udskyder i en uendelighed og nægter at følge licensen.
Hvorvidt Florian så rent faktisk har ret har jeg så ingen idé om...
#21
Ah.
Så det er ikke et Google Honeycomb problem, men et problem med device producenterne som ikke frigiver deres hardware specifikke kode (drivere)?
Medmindre de laver nogle workarounds så vil device drivere inkludere Linux kode og derfor falde under GPL.
Workarounds eksisterer dog.
Ah.
Så det er ikke et Google Honeycomb problem, men et problem med device producenterne som ikke frigiver deres hardware specifikke kode (drivere)?
Medmindre de laver nogle workarounds så vil device drivere inkludere Linux kode og derfor falde under GPL.
Workarounds eksisterer dog.
Windcape (17) skrev:Denne gang handler de om at de har distributeret Honeycomb, som closed-source, til trods for at der benyttes GPL kode.
Nej.
Google har distribueret alt kode som er under GPL licensen. Også til HC 3.2. (Dog er der stadigvæk lidt rumlen omkring hvorvidt Bionic er dækket af GPL eller ej. Det er det Florian's sidste angreb drejer sig om).
Problemet her er de enkelte android vendorer der højt og flot skider på GPL licensen og gør hvad der passer dem. Bevares, de fleste vendors får da før eller siden udgivet koden, men det er bare ikke godt nok når licensen kræver de slet ikke må distribuere deres produkt før koden er frigivet.
Hvad er det folk ikke forstår?
HTC:
http://htcdev.com/
Kom dog med noget konkret, hvilke producenter er det der mangler at lade deres kernel source være open source?
Samsung (HTC Tab 10.1 Honeycomb):
http://www.androidpolice.com/2011/06/21/download-s...
Utroligt hvordan folk prøver at blæse en storm op i et glas vand. Men hvis i kan påvise at der er producenter som har lavet om på Android kernel uden at lade deres source code være tilgængelig, så kom dog med eksempler på det.
HTC:
http://htcdev.com/
Kom dog med noget konkret, hvilke producenter er det der mangler at lade deres kernel source være open source?
Samsung (HTC Tab 10.1 Honeycomb):
http://www.androidpolice.com/2011/06/21/download-s...
Utroligt hvordan folk prøver at blæse en storm op i et glas vand. Men hvis i kan påvise at der er producenter som har lavet om på Android kernel uden at lade deres source code være tilgængelig, så kom dog med eksempler på det.
kblood (26) skrev:Hvad er det folk ikke forstår?
HTC:
http://htcdev.com/
Kom dog med noget konkret, hvilke producenter er det der mangler at lade deres kernel source være open source?
Samsung (HTC Tab 10.1 Honeycomb):
http://www.androidpolice.com/2011/06/21/download-s...
Utroligt hvordan folk prøver at blæse en storm op i et glas vand. Men hvis i kan påvise at der er producenter som har lavet om på Android kernel uden at lade deres source code være tilgængelig, så kom dog med eksempler på det.
Som nævnt mangler minimum Toshiba at udgive koden til deres Thrive tablet.
Udover det så er stort set alle producenter utroligt langsomme om at udgive koden. F.eks. gik der over en måned fra ASUS leverede 3.2 opdateringen til kildekoden til kernen kom ud. Og for god ordens skyld: Ja, det gør en forskel. 3.2 bootede IKKE ordentligt med en tidligere udgivet version af kernen.
HTC som du selv nævner udgiver for det meste koden, men IGEN går der urimeligt lang tid. For at følge GPL og loven SKAL koden være udgivet når produktet kommer i forbrugerens hænder. Det er ikke godt nok lige at vente op til flere måneder med at udgive den.
XorpiZ (27) skrev:#26
Ifølge #21, så gælder det f.eks. Toshiba. Det er tilladt at læse tråden :)
True, men det var en ret stor tråd efterhånden, og argumentet i selve nyheden er ret tvetydig.
http://forums.toshiba.com/t5/THRiVE-Tablet-Discuss...
Ser dog ud til at Toshiba er blevet gjort opmærksom på det. Ikke så heldigt at de ikke kender til det. Eller ikke har fået gjort noget ved det tidligere, men jeg vidste slet ikke de havde noget med Android at gøre.
http://androidcommunity.com/asus-transformer-sourc...
Asus var tidligt ude med source til deres transformer. Det sker en del inden for Android, så 30 dage er ikke lang tid at give, men det så længe virksomheden får det ind i deres procedure, så skulle det da helst ikke være svært at overholde.
Hvis nogen af dem bliver sagsøgt, eller hvordan det nu sker, så er de da selv ude om det.
At der er mange indlæg er et dårligt argument for at poste uden at læse dem. Når der bliver postet uden at læse tråden først resulterer det i gentagelser og spørgsmål som for længst er besvaret. Og den slags postings er en kraftigt medvirkende årsag til at trådene bliver så uoverskuelige.kblood (33) skrev:men det var en ret stor tråd efterhånden
Nogle gange tænker jeg at det kunne være smart om der var en feature til blot at angive at svaret til post #93 kunne læses i post #57 uden at man skulle oprette endnu en post for at fortælle det.
#32
Ja, de burde da helt klart gøre hvad de kan for at overholde de 30 dage. Men hvis man undersøgte dette så tror jeg der er rigtigt mange der ikke for overholdt dette inden for GPL licensen, og jeg har ikke hørt om sager hvor der er gjort noget ved det.
Men derfor skal man jo ikke bare være ligeglad med det.
#34
True, jeg burde måske have skrevet at jeg egentlig bare besvarede #0.
Men som jeg kan læse mig til så er det ved at være en gammel nyhed, da de fleste er ved at komme efter det, men de burde være på forkant med det istedet.
Ja, de burde da helt klart gøre hvad de kan for at overholde de 30 dage. Men hvis man undersøgte dette så tror jeg der er rigtigt mange der ikke for overholdt dette inden for GPL licensen, og jeg har ikke hørt om sager hvor der er gjort noget ved det.
Men derfor skal man jo ikke bare være ligeglad med det.
#34
True, jeg burde måske have skrevet at jeg egentlig bare besvarede #0.
Men som jeg kan læse mig til så er det ved at være en gammel nyhed, da de fleste er ved at komme efter det, men de burde være på forkant med det istedet.
EnJens (24) skrev:(Dog er der stadigvæk lidt rumlen omkring hvorvidt Bionic er dækket af GPL eller ej. Det er det Florian's sidste angreb drejer sig om).
Det var hans påstand i marts.
Den som Linus kaldte bogus.
Hvilket jeg godt kan forstå - de andre C libs til Linux er heller ikke under GPL.
#substans
Jeg vil konkludere at Florian er på meget meget tynd is.
Han forsøger at give Android et problem baseret på at nogle mindre Android device producenter ikke er gode til at leve op til GPL og postulerer nogle konsekvenser udfra manglende beskrivelse af konsekvenser i licensen som strider mod retspraksis uden for software licenser.
Ja - og så genbruger han et argument for licens krænkelse som licens indehaverne allerede har afvist som ubegrundet.
Jeg vil konkludere at Florian er på meget meget tynd is.
Han forsøger at give Android et problem baseret på at nogle mindre Android device producenter ikke er gode til at leve op til GPL og postulerer nogle konsekvenser udfra manglende beskrivelse af konsekvenser i licensen som strider mod retspraksis uden for software licenser.
Ja - og så genbruger han et argument for licens krænkelse som licens indehaverne allerede har afvist som ubegrundet.
Det er da rigtig nok. Men hvis du ikke gør kildekoden tilgængelig med det samme, så skal du i stedet for give modtageren af programmet et skrifteligt tilbud om at levere kildekoden til hvem som helst der måtte spørge efter den.arne_v (37) skrev:Strengt taget skal den vel først være tilgængelig når nogen ønsker den.
kasperd (39) skrev:Det er da rigtig nok. Men hvis du ikke gør kildekoden tilgængelig med det samme, så skal du i stedet for give modtageren af programmet et skrifteligt tilbud om at levere kildekoden til hvem som helst der måtte spørge efter den.
Hvis jeg tager et stykke gpl licenseret kode og arbejder videre på det skal hele mit projekt udgives under gpl'en. Sælger jeg det så til et firma er det vel strengt taget kun det firma der har krav på at få koden og ikke dig og andre der synes det kunne værer rart. Eller har jeg misforstået det helt?
Du har misforstået det en lille smule. Licensen giver dig tre valgmuligheder.Hubert (40) skrev:Sælger jeg det så til et firma er det vel strengt taget kun det firma der har krav på at få koden og ikke dig og andre der synes det kunne værer rart. Eller har jeg misforstået det helt?
a) Lever kildekoden med med det samme. Det er den nemmeste løsning, og du har levet op til din forpligtelse, og det er modtagerens ansvar hvad de gør med koden efterfølgende.
b) Lad være med at give kildekoden med, men giv i stedet et skrifteligt tilbud om at levere kildekoden til hvem som helst der måtte bede om den indenfor de næste tre år. Hvis du vælger løsning b er du de næste tre år forpligtet til at levere kildekoden til hvem som helst der måtte efterspørge den.
c) Hvis du har modtaget et program som beskrevet i b har du lov til at videregive umodificerede udgaver af programfilerne sammen med en kopi af det skriftlige tilbud. Mulighed c må ikke anvendes kommercielt. (Det skal forstås på den måde at selve distributionen som beskrevet i c ikke må foregå kommercielt, men parterne som udvekslede softwaren må stadig gerne anvende softwaren kommercielt.)
Fordi kravene i b og c er så komplicerede og fordi a er nemt at leve op til anbefaler jeg altid at man holder sig til a, blot fordi det er det nemmeste. Hvis man holder sig til a er der ingen andre der får krav på at modtage kildekoden som en konsekvens af overdragelsen. Det betyder selvfølgelig stadigvæk at begge parter har lov til at videregive kildekoden, hvis de ønsker, men de er ikke forpligtet til det.
Den gængse fortolkning er at hvis du f.eks. lægger programfiler og kildekode tilgængelig for download på den samme server og linker til begge filer fra den samme side, så har du levet op til krav a, og det er modtagerens ansvar at downloade begge filer hvis han er interesseret.
At mulighed b og c overhovedet eksisterer i GPL er nok mest af alt et levn fra en tid hvor vi ikke havde den nemme måde at overføre kildekode på som Internettet giver os i dag. Det kunne muligvis stadig være relevant hvis softwaren overdrages i form af et fysisk stykke hardware indeholdende kompileret software. I det tilfælde er det muligvis nemmere at levere det skrevne tilbud. Dog har jeg svært ved at se det svære i at trykke en mini CD med kildekoden og levere den med hardwaren.
kasperd (41) skrev:Du har misforstået det en lille smule. Licensen giver dig tre valgmuligheder.
a) Lever kildekoden med med det samme. Det er den nemmeste løsning, og du har levet op til din forpligtelse, og det er modtagerens ansvar hvad de gør med koden efterfølgende.
b) Lad være med at give kildekoden med, men giv i stedet et skrifteligt tilbud om at levere kildekoden til hvem som helst der måtte bede om den indenfor de næste tre år. Hvis du vælger løsning b er du de næste tre år forpligtet til at levere kildekoden til hvem som helst der måtte efterspørge den.
c) Hvis du har modtaget et program som beskrevet i b har du lov til at videregive umodificerede udgaver af programfilerne sammen med en kopi af det skriftlige tilbud. Mulighed c må ikke anvendes kommercielt. (Det skal forstås på den måde at selve distributionen som beskrevet i c ikke må foregå kommercielt, men parterne som udvekslede softwaren må stadig gerne anvende softwaren kommercielt.)
Fordi kravene i b og c er så komplicerede og fordi a er nemt at leve op til anbefaler jeg altid at man holder sig til a, blot fordi det er det nemmeste. Hvis man holder sig til a er der ingen andre der får krav på at modtage kildekoden som en konsekvens af overdragelsen. Det betyder selvfølgelig stadigvæk at begge parter har lov til at videregive kildekoden, hvis de ønsker, men de er ikke forpligtet til det.
Den gængse fortolkning er at hvis du f.eks. lægger programfiler og kildekode tilgængelig for download på den samme server og linker til begge filer fra den samme side, så har du levet op til krav a, og det er modtagerens ansvar at downloade begge filer hvis han er interesseret.
At mulighed b og c overhovedet eksisterer i GPL er nok mest af alt et levn fra en tid hvor vi ikke havde den nemme måde at overføre kildekode på som Internettet giver os i dag. Det kunne muligvis stadig være relevant hvis softwaren overdrages i form af et fysisk stykke hardware indeholdende kompileret software. I det tilfælde er det muligvis nemmere at levere det skrevne tilbud. Dog har jeg svært ved at se det svære i at trykke en mini CD med kildekoden og levere den med hardwaren.
Jeg er helt med på at man ved mulighed a giver den næste alle muligheder for at behandle koden som de ønsker. Men hvis vi nu bliver ved mulighed a som er den eneste måde jeg kendte til. Så er jeg vel kun 'tvunget' til at give koden til min 'kunde' og ikke andre med mindre jeg distrubuere koden i compileret form til dem også?
Korrekt. Til gengæld skal du blot huske at hvis du vælger den metode skal du give dem kildekoden med det samme. Du må ikke vente på at de spørger efter den.Hubert (42) skrev:Men hvis vi nu bliver ved mulighed a som er den eneste måde jeg kendte til. Så er jeg vel kun 'tvunget' til at give koden til min 'kunde' og ikke andre med mindre jeg distrubuere koden i compileret form til dem også?
kasperd (43) skrev:Korrekt. Til gengæld skal du blot huske at hvis du vælger den metode skal du give dem kildekoden med det samme. Du må ikke vente på at de spørger efter den.
Jeg ville mene at det er på sin plads at dem der har betalt for at få koden udviklet får koden med sig når de får overdraget projektet. Så den del burde være på plads
#GPL
Bemærk at der er forskel på V2 og V3.
V2:
V3:
Linux er V2.
Bemærk at der er forskel på V2 og V3.
V2:
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
V3:
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
Linux er V2.
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.