mboost-dp1
Licenser?
Ja man kan jo vel diskutere om det hører til under programmering, men nu poster jeg det altså her alligevel, da det jo er en rimelig essentiel ting, når man programmerer.
Mit spørgsmål går på, om der er nogen, der kender en god side, der kan forklare de forskellige kode licenser som LGPL, GPL, ASF osv. i et forståeligt menneskesprog. Eventuelt med forklaringer på, hvilke licenser skal man vælge til hvilke programmer og hvilke "huller" skal man være opmærksom på, hvis man genbruger kode fra andre, som er underlagt en eller anden form for OO licens eksempelvis. Her tænker jeg specifikt på, hvis man nu vil bruge en kodestump eller et bibliotek, som er underlagt en OO licens og man vil bruge det i forretningsøjemed (altså eksempelvis tage penge for en given applikation).
Er der nogen kloge hoveder derude, som har styr på licenser eller kender nogle gode steder at finde oplysninger? Og nej de forskellige licensers hjemmesider giver ikke umiddelbart en god forståelse af de forskellige licenser (efter min mening).
Mit spørgsmål går på, om der er nogen, der kender en god side, der kan forklare de forskellige kode licenser som LGPL, GPL, ASF osv. i et forståeligt menneskesprog. Eventuelt med forklaringer på, hvilke licenser skal man vælge til hvilke programmer og hvilke "huller" skal man være opmærksom på, hvis man genbruger kode fra andre, som er underlagt en eller anden form for OO licens eksempelvis. Her tænker jeg specifikt på, hvis man nu vil bruge en kodestump eller et bibliotek, som er underlagt en OO licens og man vil bruge det i forretningsøjemed (altså eksempelvis tage penge for en given applikation).
Er der nogen kloge hoveder derude, som har styr på licenser eller kender nogle gode steder at finde oplysninger? Og nej de forskellige licensers hjemmesider giver ikke umiddelbart en god forståelse af de forskellige licenser (efter min mening).
Windcape vil foreslå dig at kigge på Wikipedia. Derefter vil han stå fast på, at du skal bruge MIT.
In short:
AGPL (Afro GPL) : Alting skal være open source, altså ALTING, ingen smutveje!
GPL : Alting skal være open source, men du behøver ikke udgive din kode hvis det er en service provider. F.eks. en hjemmeside der bruger et GPL bibliotek.
LGPL : Mere sane GPL, tillader dynamisk linking uden at det skal være en GPL kompatibel licens. Skal stadigvæk være open source
MIT, BSD, pretty much everything NOT GPL : Du må bruge koden i lukkede projekter, uden at skulle udgive din egen kode som open source.
AGPL (Afro GPL) : Alting skal være open source, altså ALTING, ingen smutveje!
GPL : Alting skal være open source, men du behøver ikke udgive din kode hvis det er en service provider. F.eks. en hjemmeside der bruger et GPL bibliotek.
LGPL : Mere sane GPL, tillader dynamisk linking uden at det skal være en GPL kompatibel licens. Skal stadigvæk være open source
MIT, BSD, pretty much everything NOT GPL : Du må bruge koden i lukkede projekter, uden at skulle udgive din egen kode som open source.
Bekymringsniveau:
AGPL, GPL, LGPL: Vær bekymret, og undersøg alle detajler super nøje. Du tvinges sandsynligvis ud i at skulle udgive alt dit kode som open source -- Må ikke bruges med noget der indeholde forretningshemmeligheder eller porno.
Alle andre: No worries. Kan bruges som closed-source. En enkelt kræver at du køber Poul Henning Kamp en øl hvis du møder ham. Så forsøg at undgå at møde denne rødskæggede hippie, hvis du kan.
AGPL, GPL, LGPL: Vær bekymret, og undersøg alle detajler super nøje. Du tvinges sandsynligvis ud i at skulle udgive alt dit kode som open source -- Må ikke bruges med noget der indeholde forretningshemmeligheder eller porno.
Alle andre: No worries. Kan bruges som closed-source. En enkelt kræver at du køber Poul Henning Kamp en øl hvis du møder ham. Så forsøg at undgå at møde denne rødskæggede hippie, hvis du kan.
#7
Det er sådan mere eller mindre "common knowlegde", når man har arbejdet med Open Source software i en længere periode.
Jeg vil anbefale at du læser wikipedia omkring AGPL, GPL, LGPL, og MIT.
Det dækker 99% af alle licenserne. MIT, BSD, Apache, osv. er alle sammen samme type licenser, der tillader kommencielt brug, uden at du tvinges til at frigive din kildekode etc.
AGPL og GPL er de eneste virale licenser, der tvinger dig til at udgive alting der tilgår det, under en GPL kompatibel licens.
Det er sådan mere eller mindre "common knowlegde", når man har arbejdet med Open Source software i en længere periode.
Jeg vil anbefale at du læser wikipedia omkring AGPL, GPL, LGPL, og MIT.
Det dækker 99% af alle licenserne. MIT, BSD, Apache, osv. er alle sammen samme type licenser, der tillader kommencielt brug, uden at du tvinges til at frigive din kildekode etc.
AGPL og GPL er de eneste virale licenser, der tvinger dig til at udgive alting der tilgår det, under en GPL kompatibel licens.
Windcape (8) skrev:AGPL og GPL er de eneste virale licenser, der tvinger dig til at udgive alting der tilgår det, under en GPL kompatibel licens.
MIT er jo GPL-kompatibel, så man kan roligt bruge Open Source i sit projekt uden at skulle udgive kildekode, right?
Daniel-Dane (2) skrev:Windcape vil foreslå dig at kigge på Wikipedia.
Windcape (8) skrev:Jeg vil anbefale at du læser wikipedia omkring AGPL, GPL, LGPL, og MIT.
Daniel-Dane (2) skrev:Windcape vil foreslå dig at kigge på Wikipedia. Derefter vil han stå fast på, at du skal bruge MIT.
Windcape (8) skrev:Det dækker 99% af alle licenserne. MIT, BSD, Apache, osv. er alle sammen samme type licenser, der tillader kommencielt brug, uden at du tvinges til at frigive din kildekode etc.
Err, rettelse.Windcape (11) skrev:Nej, MIT er ikke GPL kompatibel.
MIT er GPL kompatibel. Dvs. du kan udgive din egen kode under MIT, hvor resten er GPL. MEN projekter der bruger dit samt GPL projektet du har linket, skal også være open source.
Det giver selvfølgelig muligheden for at skrive kode der ikke er direkte afhængigt af GPL, som så kan genbruges.
(And I blame Alrekr for killing my edit-func)
Se http://en.wikipedia.org/wiki/List_of_FSF_approved_...
Jeg troede sådan set ikke at non-copyleft licenser var GPL kompatible. Oh well.
Lad mig stille det som et ja/nej-spørgsmål:
Jeg skriver et program, som inkluderer kode, som er GPL-licenseret. Min kode er closed source, og jeg har intentioner om at sælge mit program. Kan MIT redde mig?
Jeg skriver et program, som inkluderer kode, som er GPL-licenseret. Min kode er closed source, og jeg har intentioner om at sælge mit program. Kan MIT redde mig?
#14
Nej.
Din kode skal stadigvæk være open source. Men hvis du skriver et andet program som kun bruger MIT delen fra det første program, så kan du godt udgive det closed source.
Altså ligegyldigt hvad du gør, så kræver GPL at du udgiver programmer med linked GPL kode (dynamic or static), som open source
Nej.
Din kode skal stadigvæk være open source. Men hvis du skriver et andet program som kun bruger MIT delen fra det første program, så kan du godt udgive det closed source.
Altså ligegyldigt hvad du gør, så kræver GPL at du udgiver programmer med linked GPL kode (dynamic or static), som open source
#16
Uuuuh, gråzone. Du kan principelt stille kravene om at de kommer med tilpads mange floppydiske til en bestemt addresse, for at hente din kode.
(Det burde afskrække de fleste)
In short: Du skal udlevere den hvis du bliver spurt. Men du bestemmer hvordan den skal udleveres. Der er intet krav om et public repo på nettet.
Uuuuh, gråzone. Du kan principelt stille kravene om at de kommer med tilpads mange floppydiske til en bestemt addresse, for at hente din kode.
(Det burde afskrække de fleste)
In short: Du skal udlevere den hvis du bliver spurt. Men du bestemmer hvordan den skal udleveres. Der er intet krav om et public repo på nettet.
Fedt. Lad os da lige tage den til ekstremerne:
Kan jeg sælge mit program, hvis det indeholder MIT- og/eller GPL-licenser (bare det er open source)?
Jeg behøver (læs: tvunget) altså ikke aktivt lægge kildekoden ud, når det er open source, men jeg skal udlevere den på en eller anden måde, right?
Må man godt udlevere den obfuscated?
Kan jeg sælge mit program, hvis det indeholder MIT- og/eller GPL-licenser (bare det er open source)?
Jeg behøver (læs: tvunget) altså ikke aktivt lægge kildekoden ud, når det er open source, men jeg skal udlevere den på en eller anden måde, right?
Må man godt udlevere den obfuscated?
Daniel-Dane (18) skrev:Jeg behøver (læs: tvunget) altså ikke aktivt lægge kildekoden ud, når det er open source, men jeg skal udlevere den på en eller anden måde, right?
Den fik du så besvaret med din tilføjelse. Hmm, men siden man kan tvinge folk til at møde op på adressen, kan man vel også bede folk om at betale for porto, hvis man har tænkt sig at sende source med brev.
Darwind (16) skrev:#15 - vil det så sige, at jeg bliver nødt til at lægge min kode op, så den er til fuldt skue for offentligheden, eller er det kun, hvis der er en person eller virksomhed, der spørger mig specifikt om min kode, at jeg skal udlevere den under GPL?
Det kommer an på hvordan du udgiver dit software. Det er beskrevet nogenlunde ligetil i del 6 af GPLv3. Eller fortæl hvordan du vil udgive dit software, så skal jeg nok prøve at oversætte til mere letforståeligt dansk. :)
Daniel-Dane (18) skrev:Kan jeg sælge mit program, hvis det indeholder MIT- og/eller GPL-licenser (bare det er open source)?
Du er velkommen til at sælge GPL-software, så dyrt du vil. Men din kunde skal så have adgang til kildekoden, og kunden har ret til at forære hele skidtet til højre venstre som han har lyst.
MIT-software kan du også sagtens sælge. Også her har kunden ret til at give kopier væk, men modsat GPL behøver du ikke give kunden kildekoden.
Daniel-Dane (18) skrev:Jeg behøver (læs: tvunget) altså ikke aktivt lægge kildekoden ud, når det er open source, men jeg skal udlevere den på en eller anden måde, right?
Det kommer an på licensen. Se også #20.
Daniel-Dane (18) skrev:Må man godt udlevere den obfuscated?
Det er lidt et definitionsspørgmsål.
Ifølge GPL skal kildekoden inkludere alt hvad der skal til, for at bygge softwaren. Dvs. ud fra kildekoden (plus tilgængelige værktøjer så som en compiler) skal man kunne lave et fungerende byg. Man kan ikke lave noget som kun kan compiles med nogle hemmelige parametre til compileren, eller noget som skal igennem en hjemmebrygget hemmelig pre-compiler osv.
Til gengæld siger licensen ikke noget om kodekvalitet. Jeg har set masser af kode som er meget svær for et menneske at læse og forstå (hvilket vist er definitionen af obfuscated code), men som faktisk er bare afspejler programmørens evner. (Og vilje til at gøre et ordentligt stykke arbejde.)
Dvs. du kan sagtens udvikle din egen elendige kodestil, og lave kode som ingen andre gider røre, og så udgive det som GPL eller whatever.
myplacedk (20) skrev:Det kommer an på hvordan du udgiver dit software. Det er beskrevet nogenlunde ligetil i del 6 af GPLv3. Eller fortæl hvordan du vil udgive dit software, så skal jeg nok prøve at oversætte til mere letforståeligt dansk. :)
Jeg skal lave et stykke software for et firma og skal bruge nogle 3. parts biblioteker, som er under GPL licens. Kunden er ikke interesseret i, at kildekoden bliver publiceret, da de ikke er interesseret i fx, at andre får oplysninger om strukturen af database og andet lignende.
Det er så sådan, at softwaren ikke bliver udgivet til offentligheden, men i stedet for udbyder firmaet softwaren til deres egne kunder.
Softwaren skulle gerne være så "closed source" som muligt for firmaets vedkommende.
EDIT: #Off topic - det er sq rart man kan have en saglig diskussion om noget relevant herinde, uden diskussionen løber fuldstændigt af sporet ;)
Daniel-Dane (18) skrev:Må man godt udlevere den obfuscated?
myplacedk (21) skrev:
Det er lidt et definitionsspørgmsål.
Ifølge GPL skal kildekoden inkludere alt hvad der skal til, for at bygge softwaren. Dvs. ud fra kildekoden (plus tilgængelige værktøjer så som en compiler) skal man kunne lave et fungerende byg. Man kan ikke lave noget som kun kan compiles med nogle hemmelige parametre til compileren, eller noget som skal igennem en hjemmebrygget hemmelig pre-compiler osv.
Til gengæld siger licensen ikke noget om kodekvalitet. Jeg har set masser af kode som er meget svær for et menneske at læse og forstå (hvilket vist er definitionen af obfuscated code), men som faktisk er bare afspejler programmørens evner. (Og vilje til at gøre et ordentligt stykke arbejde.)
Dvs. du kan sagtens udvikle din egen elendige kodestil, og lave kode som ingen andre gider røre, og så udgive det som GPL eller whatever.
http://www.gnu.org/copyleft/gpl.html siger:
The “source code” for a work means the preferred form of the work for making modifications to it.
Så hvis man vil udlevere obfuscated source som source i GPL henseende, så skal man lige først finde nogle uafhængige eksperter som vil påstå at de foretrækker at rette i obfuscated kode fremfor ikke obfuscated kode.
Så bottom line: nej - den går ikke.
#22 & 25
Det bør sagtens kunne lade sig gøre. Closed source kode og LGPL biblkioteker er ikke et problem.
De to regler du skal være opmærksom på er:
1) hvis du laver rettelser til selve LGPL bibliotekerne (såsom at rette nogle fejl) så skal du offentliggøre disse rettelser
2) du skal linke dynamisk mod de LGPL biblioteker således at slutbrugerne kan opdatere disse uafhængigt af din app
Det bør sagtens kunne lade sig gøre. Closed source kode og LGPL biblkioteker er ikke et problem.
De to regler du skal være opmærksom på er:
1) hvis du laver rettelser til selve LGPL bibliotekerne (såsom at rette nogle fejl) så skal du offentliggøre disse rettelser
2) du skal linke dynamisk mod de LGPL biblioteker således at slutbrugerne kan opdatere disse uafhængigt af din app
#5 & 6
Jeg mener ikke at det giver et korrekt billede.
Mixed closed source & open source til internt brug:
AGPL - ok
GPL - ok
LGPL - ok
Apache - ok
BSD - ok
Mixed closed source & open source til SaaS løsning:
AGPL - problem
GPL - ok
LGPL - ok
Apache - ok
BSD - ok
Mixed closed source & open source til distribution:
AGPL - problem
GPL - problem
LGPL - ok (forudsat dynamisk link)
Apache - ok
BSD - ok
Closed source fork/klon af open source til distribution:
AGPL - problem
GPL - problem
LGPL - problem
Apache - ok
BSD - ok
Jeg mener ikke at det giver et korrekt billede.
Mixed closed source & open source til internt brug:
AGPL - ok
GPL - ok
LGPL - ok
Apache - ok
BSD - ok
Mixed closed source & open source til SaaS løsning:
AGPL - problem
GPL - ok
LGPL - ok
Apache - ok
BSD - ok
Mixed closed source & open source til distribution:
AGPL - problem
GPL - problem
LGPL - ok (forudsat dynamisk link)
Apache - ok
BSD - ok
Closed source fork/klon af open source til distribution:
AGPL - problem
GPL - problem
LGPL - problem
Apache - ok
BSD - ok
Darwind (22) skrev:Jeg skal lave et stykke software for et firma og skal bruge nogle 3. parts biblioteker, som er under GPL licens. Kunden er ikke interesseret i, at kildekoden bliver publiceret, da de ikke er interesseret i fx, at andre får oplysninger om strukturen af database og andet lignende.
Som arne_v siger: Hvis du er så heldig at det faktisk er LGPL, og ikke GPL, så er det ikke det store problem. Hvis det er biblioteker, så er der gode chancer for at det er LGPL.
Men hvis det er GPL, så betyder det formentlig at kildekoden til dit software skal være lige så tilgængeligt som dit software skal.
Darwind (22) skrev:Det er så sådan, at softwaren ikke bliver udgivet til offentligheden, men i stedet for udbyder firmaet softwaren til deres egne kunder.
Altså ligesom Windows ikke er udgivet til offentligheden, men kun til Microsofts kunder?
arne_v (24) skrev:Så hvis man vil udlevere obfuscated source som source i GPL henseende, så skal man lige først finde nogle uafhængige eksperter som vil påstå at de foretrækker at rette i obfuscated kode fremfor ikke obfuscated kode.
Som sagt, det kommer an på hvad man mener med "obfuscated".
JEG (og nok de fleste andre) mener at det betyder, at koden har været igennem et stykke software som gør det temmeligt ulæseligt.
Men som sagt kan det jeg synes nærmest ser obfuscated ud, for en anden være hans bedste forsøg på at skrive god kode. Det er helt efter GPL'en ånd og ord.
Der må være en gråzone der imellem. Men vi kan nok blive enige om at det ikke er noget der er værd at gå efter. Så snart det er bevidst, så er der mindst imod GPL's ånd. Resten er et spørgsmål om hvor meget krudt parterne vil bruge på en retssag.
myplacedk (29) skrev:Altså ligesom Windows ikke er udgivet til offentligheden, men kun til Microsofts kunder?
Den skal vist uddybes. :)
I denne sammenhæng er der to muligheder: Internt software som aldrig skal udgives, eller software som udgives til mindst én anden juridisk enhed. Der er ikke så stor forskel på at give det til én kunde, og at lægge det til gratis download rundt omkring på nettet. Softwaren er ude, og så er kildekoden praktisk talt også.
myplacedk (29) skrev:Darwind (22) skrev:Det er så sådan, at softwaren ikke bliver udgivet til offentligheden, men i stedet for udbyder firmaet softwaren til deres egne kunder.
Altså ligesom Windows ikke er udgivet til offentligheden, men kun til Microsofts kunder?
Ja, ok det var vist lidt "vagt" formuleret fra min side ;) Det jeg mente var, at jeg leverer softwaren til min kunde (firmaet). De vælger så at udbyde produktet til deres kunder som en ekstra ydelse til de produkter de allerede har købt hos firmaet. Softwaren bliver altså leveret gratis til deres kunder (så vidt jeg har forstået).
Firmaet (min kunde) beholder alle rettighederne til softwaren efter jeg har afleveret det færdige produkt til dem.
3. parts bibliotekerne er som sagt under LGPL, så det lyder jo rart, at jeg ikke skal forholde mig synderligt kritisk til det heldigvis ;)
Jeg forventer ikke at lave ændringer i 3. parts biblioteket set i den forstand, at jeg endnu ikke har leget med biblioteket endnu, så man kan jo ikke vide om man finder underlige bugs, der skal rettes ;)
myplacedk (31) skrev:Den skal vist uddybes. :)
I denne sammenhæng er der to muligheder: Internt software som aldrig skal udgives, eller software som udgives til mindst én anden juridisk enhed. Der er ikke så stor forskel på at give det til én kunde, og at lægge det til gratis download rundt omkring på nettet. Softwaren er ude, og så er kildekoden praktisk talt også.
Så vidt jeg har forstået, så har man vel ikke ret til at bruge koden, selvom et program er lagt gratis ud til download? Hvis licensen koden bruger siger, at du ikke må kopiere koden, er det så ikke underordnet om programmet er gratis eller koster penge?
arne_v (26) skrev:[...]
2) du skal linke dynamisk mod de LGPL biblioteker således at slutbrugerne kan opdatere disse uafhængigt af din app
arne_v (27) skrev:#5 & 6
[...]
Mixed closed source & open source til distribution:
AGPL - problem
GPL - problem
LGPL - ok (forudsat dynamisk link)
Apache - ok
BSD - ok
[...]
arne_v (34) skrev:#32,33
Når rettighedsindehaver (din kunde) leverer produktet til den første bruher udenfor virksomheden så er det distribution til andre. En enkelt eller en milliard brugere er ligegyldigt. Gratis eller for 100 M$ er ligegyldigt.
Så det skal forstås således, at hvis jeg linker dynamisk til de LGPL underlagte biblioteker, så er resten af koden fint lukket af for andre end min kunde og jeg?
Det var lige præcis derfor jeg lavede denne tråd til at starte med - det er fandme en jungle at finde rundt i alle de licenser ;)
Darwind (33) skrev:Så vidt jeg har forstået, så har man vel ikke ret til at bruge koden, selvom et program er lagt gratis ud til download?
Hvis det er udgivet GPL, jo.
Darwind (33) skrev:Hvis licensen koden bruger siger, at du ikke må kopiere koden, er det så ikke underordnet om programmet er gratis eller koster penge?
Det kommer an på om der står noget om det i den pågældende licens. Men udgangspunktet er at prisen ikke har betydning, og det gælder vist for alle de licenser vi kalder "open source".
Darwind (35) skrev:det er fandme en jungle at finde rundt i alle de licenser ;)
Njaæh. Så vidt jeg kan se er det LGPL du skal have styr på. Hvis du nu koncentrerer dig om det, så er opgaven allerede reduceret temmeligt meget.
Men hvis du gerne vil have overblik, så kan du gøre sådan her:
1) Lav en liste over hvilke licenser du vil kigge på. Du kan tilføje til enhver tid. Fx: GPL, LGPL, BSD, MIT, Apache
2) Find en letlæselig beskrivelse. Fx. på wikipedia, men prøv gerne selv at læse den originale licens. (Eller bare indledningen ved de lange.)
3) Skriv små notater undervejs. De ting som er vigtige for dig, og ting som overrasker dig mest.
Hvis det er til en specifik situation, kandu nok koge det ned til noget så simpelt som det arne_v gør i #27.
(Og lyt ikke for meget til Windcape. #5 og #6 ser informative ud, og jeg vil da heller ikke kalde direkte løgn. Men det er fyldt med forhastede konklusioner, juridisk meget dårlige råd og tilsyneladende et eller andet form for had.)
Det skal dog siges, at det ikke et krav at værktøjerne der skal bruges til at bygge med er gratis, open source, eller virker på alle platforme.myplacedk (21) skrev:Ifølge GPL skal kildekoden inkludere alt hvad der skal til, for at bygge softwaren. Dvs. ud fra kildekoden (plus tilgængelige værktøjer så som en compiler) skal man kunne lave et fungerende byg. Man kan ikke lave noget som kun kan compiles med nogle hemmelige parametre til compileren, eller noget som skal igennem en hjemmebrygget hemmelig pre-compiler osv.
Man kan blive bedt om at bevise (i en retssag, hvis FSF er stædige nok), om at den frigivne kode er identisk til den man har intern.myplacedk (30) skrev:Der må være en gråzone der imellem. Men vi kan nok blive enige om at det ikke er noget der er værd at gå efter.
Altså direkte obfuscering, som kun bruges til at frigive offentligt, er et no-go.
Jeg synes stadigvæk at løsningen med at folk skal hente softwaren med floppydiske, på en vejrstation på sydpolen, hvor maskinen er en Pentium I, er en bedre løsning!
Nej, kun binaries af de dele der er MIT licenceret.Daniel-Dane (23) skrev:Wait, what? Hvis et program indeholder MIT-kode, må kunden så give binaries væk?
F.eks. hvis du bruger et bibliotek jeg har udgivet under MIT, i dit closed-source program, så må kunden godt kopiere min DLL fil, og give den videre. Men ikke resten af dit program.
Ja. Du har intet ansvar for at dække udgifter til publisering af kildekoden.Daniel-Dane (19) skrev:Den fik du så besvaret med din tilføjelse. Hmm, men siden man kan tvinge folk til at møde op på adressen, kan man vel også bede folk om at betale for porto, hvis man har tænkt sig at sende source med brev.
Peter Toft skrev engang om det, hvor han forsøgte at få kildekoden til hans Samsung DVD afspiller, eller noget i den stil. Der var intet public-repo.
Der er heller intet krav om at folk skal kunne kontakte dig elektronisk, telefonisk, eller at du skal angive en adresse.
Så mulighederne for at slippe uden om at store :p
*suk* Vi kan jo godt kopiere alle wikipedia linkene ind i tråden, eller kopiere indholdet direkte.myplacedk (38) skrev:(Og lyt ikke for meget til Windcape. #5 og #6 ser informative ud, og jeg vil da heller ikke kalde direkte løgn. Men det er fyldt med forhastede konklusioner, juridisk meget dårlige råd og tilsyneladende et eller andet form for had.)
Du er selv ikke gået videre end at bede ham læse op. Jeg gav et hurtigt overview, i et lettere sarkastisk og morsomt tonefald, mens du som altid ikke kan se det for rent had.
Jeg har produceret titusindevis af linjers open source kode, kontributeret til open source projekter, og lavet open source programmer der benyttes af tusindevis af brugere.
Så jeg tror nok jeg ved mere om det end du gør.
Jeg siger tak for indlæggene - de har været yderst fyldestgørende ;) Lækkert, at der er nogle kloge hoveder herinde, man altid kan spørge til råds :D
Er allerede gået igang med at finkæmme LGPL'en.
Det der irriterer mig mest ved i hvert fald GPL og LGPL er alt det "baggrundshistorie", der står i licenserne... det er fint nok at vide, men de kunne godt lade være med at blande det sammen med de rent juridiske ting. Måske de kunne dele det hele op i "Nice-to-know" og "Need-to-know" sektioner :P
Er allerede gået igang med at finkæmme LGPL'en.
Det der irriterer mig mest ved i hvert fald GPL og LGPL er alt det "baggrundshistorie", der står i licenserne... det er fint nok at vide, men de kunne godt lade være med at blande det sammen med de rent juridiske ting. Måske de kunne dele det hele op i "Nice-to-know" og "Need-to-know" sektioner :P
#GPL vs LGPL
Traditionelt har man brugt GPL til standalone apps og LGPL til biblioteker, så selvom der er skrevet meget om den virale effekt af GPL, så er det ret sjældent at det er et problem.
I de få tilfælde hvor der bruges GPL til biblioteker, så er det typisk fordi biblioteket tilbydes med dual license:
- GPL
- commerciel closed source licens
hvilket giver folk valget mellem at udgive deres app under GPL eller at betale ved kasse et.
Mest kendt for denne problem stilling er MySQL.
Der er ikke nogen problemer ved at MySQL database server er under GPL med FLOSS exception (undtagen hvis man vil embedde MySQL i sin app).
Men der er store problemer med at MySQL connectorer er under GPL med FLOSS exception.
Der skal udviklere virkeligt holde tungen lige i munden.
Traditionelt har man brugt GPL til standalone apps og LGPL til biblioteker, så selvom der er skrevet meget om den virale effekt af GPL, så er det ret sjældent at det er et problem.
I de få tilfælde hvor der bruges GPL til biblioteker, så er det typisk fordi biblioteket tilbydes med dual license:
- GPL
- commerciel closed source licens
hvilket giver folk valget mellem at udgive deres app under GPL eller at betale ved kasse et.
Mest kendt for denne problem stilling er MySQL.
Der er ikke nogen problemer ved at MySQL database server er under GPL med FLOSS exception (undtagen hvis man vil embedde MySQL i sin app).
Men der er store problemer med at MySQL connectorer er under GPL med FLOSS exception.
Der skal udviklere virkeligt holde tungen lige i munden.
Windcape (40) skrev:Jeg synes stadigvæk at løsningen med at folk skal hente softwaren med floppydiske, på en vejrstation på sydpolen, hvor maskinen er en Pentium I, er en bedre løsning!
Windcape (41) skrev:Der er heller intet krav om at folk skal kunne kontakte dig elektronisk, telefonisk, eller at du skal angive en adresse.
Windcape (41) skrev:Så mulighederne for at slippe uden om at store :p
Der er mange som har "gode" ideer.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
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.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
Hvilket jeg vil opsummere som:
- levere binary på fysisk medie med source på samme medie
- levere binary på fysisk medie med source gratis tilgængelig på nettet
- levere binary på fysisk medie med source på fysisk medie til cost pris
- levere binary via nettet med source gratis tilgængelig på nettet
Du kan med andre ord godt gemme floppies på sydpolen hvis du distribuerer via nettet.
Og der skal også være en URL på source hvis du distribuerer via nettet.
Med hensyn til distrubution på fysisk medie, så:
- tror jeg at det er svært at sælge software på fysisk medie uden at køber kender en adresse
- risikerer du at en dommer vil mene at usædvanelige rejse omkostninger er sælgers ansvar med den formulering
#47
Emnet er stærkt omdiskuteret.
GPL teksten er ikke så klar.
Der er ingen retspraksis indenfor dette område.
Men hvis du:
1) accepterer den gængse linking fortolking af GPL teksten
2) accepterer min bedste subjektive vurdering af hvad linking er
så:
PHP mysql - ikke problem da PHP er dækkes af FLOSS exception
PHP mysqli - ikke problem da PHP er dækkes af FLOSS exception
PHP pdo - ikke problem da PHP er dækkes af FLOSS exception
.NET MySqlConnection - problem
.NET DbProviderFactories med hardcoded provider og connection - problem
.NET DbProviderFactories med config fil for provider og connection - ikke problem da ikke linket
.NET ORM - ORM producentens ansvar
Java med hardcoded driver og connection - problem
Java med config fil for driver og connection - ikke problem da ikke linket
Java ORM - ORM producentens ansvar
C MySQL API - problem
Emnet er stærkt omdiskuteret.
GPL teksten er ikke så klar.
Der er ingen retspraksis indenfor dette område.
Men hvis du:
1) accepterer den gængse linking fortolking af GPL teksten
2) accepterer min bedste subjektive vurdering af hvad linking er
så:
PHP mysql - ikke problem da PHP er dækkes af FLOSS exception
PHP mysqli - ikke problem da PHP er dækkes af FLOSS exception
PHP pdo - ikke problem da PHP er dækkes af FLOSS exception
.NET MySqlConnection - problem
.NET DbProviderFactories med hardcoded provider og connection - problem
.NET DbProviderFactories med config fil for provider og connection - ikke problem da ikke linket
.NET ORM - ORM producentens ansvar
Java med hardcoded driver og connection - problem
Java med config fil for driver og connection - ikke problem da ikke linket
Java ORM - ORM producentens ansvar
C MySQL API - problem
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.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund