mboost-dp1
Læser du kildekoden til de open source-programmer du bruger?
hvilket dybt tåbeligt spørgsmål.... De hyppigst anvendte OS programmer, har jo flere millioner linjers kode... Er jo komplet naivt at tro nogen læser det igennem bare for at gøre det... Det er jo lidt noget andet hvis man vil skrive plugins, men så er et API nok rigeligt... Eneste grund til at kigge koden igennem, er hvis man enten vil fikse noget, eller vide hvordan x eller y er implementeret...
Ikke fordi jeg er bange for at der er væmmelig ting gemt dybt i koden. Men har gjort det før, af ren interesse for hvordan et problem var blevet taklet.
Udviklere der bidrager med kode vil automatisk læse kildekoden, så det er nok i den gruppe man finder dem som har størst indsigt i de individuelle programmer.
Jeg vælger lidt at tro at spørgsmålet er blevet stillet, for at fremprovokere en diskussion om sikkerheden ved brug af opensource software. Personligt er jeg aldrig blevet brændt af opensource (i form af gemte vira el.lign.) og bekymrer mig heller ikke om det - måske har det noget at gøre med motivationen bag OS som tiltrækker en vis gruppe "ærlige" mennesker, who knows ;)
Udviklere der bidrager med kode vil automatisk læse kildekoden, så det er nok i den gruppe man finder dem som har størst indsigt i de individuelle programmer.
Jeg vælger lidt at tro at spørgsmålet er blevet stillet, for at fremprovokere en diskussion om sikkerheden ved brug af opensource software. Personligt er jeg aldrig blevet brændt af opensource (i form af gemte vira el.lign.) og bekymrer mig heller ikke om det - måske har det noget at gøre med motivationen bag OS som tiltrækker en vis gruppe "ærlige" mennesker, who knows ;)
Jeg kender flere som har haft glæde af at noget er opensource, uden at være i stand til at læse kildekode, eller for den sags skyld compile programmet.
Eksempel: En fyr køber en ny PDA, og er glad for den. Men det program at bruger til at synce med, understøtter ikke den nye PDA. Næste major release understøtter PDA'en, men er meget ustabil.
Jeg kigger på det for ham, og finder ud af at understøttelsen er triviel at lave. Så jeg finder sourcen til stable-udgaven, patcher understøttelsen ind, compiler, og så er han glad.
Mere generelt kender jeg flere der bruger opensource, for ikke at være afhængig af en leverandør. Hvis leverandøren dropper produktet, kan man virkelig være på skideren. Med opensource kan man ofte klare det ved at hyre en tilfældig konsulent til at lave den opdatering man har behov for. Hvis ikke andre har gjort det først, og frigivet ændringen.
Eksempel: En fyr køber en ny PDA, og er glad for den. Men det program at bruger til at synce med, understøtter ikke den nye PDA. Næste major release understøtter PDA'en, men er meget ustabil.
Jeg kigger på det for ham, og finder ud af at understøttelsen er triviel at lave. Så jeg finder sourcen til stable-udgaven, patcher understøttelsen ind, compiler, og så er han glad.
Mere generelt kender jeg flere der bruger opensource, for ikke at være afhængig af en leverandør. Hvis leverandøren dropper produktet, kan man virkelig være på skideren. Med opensource kan man ofte klare det ved at hyre en tilfældig konsulent til at lave den opdatering man har behov for. Hvis ikke andre har gjort det først, og frigivet ændringen.
Nej
Først og fremmest fordi der er ingen grund til at læse kildekoden, det er besværligt, og tidsspilde, samt alt for mange open source projekter er nærige med code-comments, specielt C/C++ udviklere.
Derudover er der en lang række programmeringssprog, og man kan ikke kende dem alle, og få noget ud af alting. Og så fordi at projekter som f.eks. Mozilla Firefox har en så ektrem rodet kilekode base, at man alligevel ikke kan hitte hovede og hale i det.
Derudover er det ofte meget billigere at købe et nyt hyldevare produkt, end en konsulent. Samt jeg tvivler på du kan finde konsulenter til alt verdens hobby software.
Open Source for mig handler i 99.99% af alle tilfælde om at det er GRATIS. Kildekoden er hamrende ligegyldig.
Først og fremmest fordi der er ingen grund til at læse kildekoden, det er besværligt, og tidsspilde, samt alt for mange open source projekter er nærige med code-comments, specielt C/C++ udviklere.
Derudover er der en lang række programmeringssprog, og man kan ikke kende dem alle, og få noget ud af alting. Og så fordi at projekter som f.eks. Mozilla Firefox har en så ektrem rodet kilekode base, at man alligevel ikke kan hitte hovede og hale i det.
Det er komplet irrelevante for private, og irrelevant for de fleste virksomheder.myplacedk (5) skrev:Mere generelt kender jeg flere der bruger opensource, for ikke at være afhængig af en leverandør. Hvis leverandøren dropper produktet, kan man virkelig være på skideren. Med opensource kan man ofte klare det ved at hyre en tilfældig konsulent til at lave den opdatering man har behov for. Hvis ikke andre har gjort det først, og frigivet ændringen
Derudover er det ofte meget billigere at købe et nyt hyldevare produkt, end en konsulent. Samt jeg tvivler på du kan finde konsulenter til alt verdens hobby software.
Open Source for mig handler i 99.99% af alle tilfælde om at det er GRATIS. Kildekoden er hamrende ligegyldig.
ToFFo (7) skrev:Læser du ingredientslisten på det mad du spiser?
Ja, også det. Nej, ikke hver gang, men det sker.
Det var sådan jeg opdagede at Tyrkisk Peber og lakrids-sovs havde nøjagtigt de samme smagsstoffer. Straks købte jeg begge dele og en portion vanille-is, lavede tyrkisk-peber-is, og serverede det med lakrids-sovs. Og det passede rigtigt godt sammen, det smagte herligt.
#6, åh så negativ.
Kort sagt.
Ja så nytter det jo ikke noget. At det så for andre kan ende med at være et spørgsmål om virksomheden kan overleve, det behøver vi ikke snakke om. Eller hvad?
Og resten snakker vi ikke om.
Jeg tror verdens-gennemsnittet er ca. ligesådan. Jeg tror også at 99,99% af landets befolkning er ligeglad med hvordan vandforsyningen fungerer, bare den gør det.
Eller sagt på en anden måde: Jeg tror rigtigt mange mennesker får glæde af at et prodult er opensource, selv om effekten er indirekte, og de nok ikke engang opdager at det er opensource.
Windcape (6) skrev:Først og fremmest fordi der [ofte er forhindringer, så det nytter jo ikke noget.]
Kort sagt.
Windcape (6) skrev:Det er komplet irrelevante for private, og irrelevant for de fleste virksomheder.
Ja så nytter det jo ikke noget. At det så for andre kan ende med at være et spørgsmål om virksomheden kan overleve, det behøver vi ikke snakke om. Eller hvad?
Windcape (6) skrev:Derudover er det ofte meget billigere at købe et nyt hyldevare produkt, end en konsulent.
Og resten snakker vi ikke om.
Windcape (6) skrev:Open Source for mig handler i 99.99% af alle tilfælde om at det er GRATIS. Kildekoden er hamrende ligegyldig.
Jeg tror verdens-gennemsnittet er ca. ligesådan. Jeg tror også at 99,99% af landets befolkning er ligeglad med hvordan vandforsyningen fungerer, bare den gør det.
Eller sagt på en anden måde: Jeg tror rigtigt mange mennesker får glæde af at et prodult er opensource, selv om effekten er indirekte, og de nok ikke engang opdager at det er opensource.
Nej...
Hvis jeg kunne kode og forstå det, ville jeg måske gøre det af ren nysgerrighed. Det kan vel ikke være meget mere underligt end et wiki trip. Hvis i ikke kender et wiki trip omhandler det en 2-3 timer man aldrig får igen, men til gengæld ved man en masse obskøre detaljer omkring star wars, startrek, wow lore eller hvad ellers der har en udemærket wiki.
Hvis jeg kunne kode og forstå det, ville jeg måske gøre det af ren nysgerrighed. Det kan vel ikke være meget mere underligt end et wiki trip. Hvis i ikke kender et wiki trip omhandler det en 2-3 timer man aldrig får igen, men til gengæld ved man en masse obskøre detaljer omkring star wars, startrek, wow lore eller hvad ellers der har en udemærket wiki.
mgX (2) skrev:hvilket dybt tåbeligt spørgsmål.... De hyppigst anvendte OS programmer, har jo flere millioner linjers kode... Er jo komplet naivt at tro nogen læser det igennem bare for at gøre det...
Jo. Men nu tolkede jeg spørgsmålet som "Læser du noget af ..." og ikke som "Læser du hele ...".
Windcape (6) skrev:Først og fremmest fordi der er ingen grund til at læse kildekoden, det er besværligt, og tidsspilde,
Afhænger jo af om man har en grund til at kigge i den eller ej.
Windcape (6) skrev:samt alt for mange open source projekter er nærige med code-comments, specielt C/C++ udviklere.
Har du noge kilde til at open source udviklere skulle skrive færre kommentarer end closed source udviklere?
Har du nogen kilde til at C/C++ udviklere skulle skrive færre kommentarer end udviklere i andre sprog?
Det lyder ikke specielt sandsynligt i mine ører, da der er så stor overlap mellem grupperne.
Windcape (6) skrev:Derudover er der en lang række programmeringssprog, og man kan ikke kende dem alle, og få noget ud af alting.
Det er indlysende at man får kun noget ud af at læse kode skrevet i et sprog man forstår.
Windcape (6) skrev:Og så fordi at projekter som f.eks. Mozilla Firefox har en så ektrem rodet kilekode base, at man alligevel ikke kan hitte hovede og hale i det.
Det gælder nok de fleste store projekter - open source eller closed source - det er besværligt at sætte sig ind i kompleks software.
Windcape (6) skrev:Open Source for mig handler i 99.99% af alle tilfælde om at det er GRATIS. Kildekoden er hamrende ligegyldig.
Du er langtfra den eneste. Jeg gætter på at >95% er lige sådan.
myplacedk (5) skrev:Mere generelt kender jeg flere der bruger opensource, for ikke at være afhængig af en leverandør. Hvis leverandøren dropper produktet, kan man virkelig være på skideren. Med opensource kan man ofte klare det ved at hyre en tilfældig konsulent til at lave den opdatering man har behov for. Hvis ikke andre har gjort det først, og frigivet ændringen.
Det ses.
Men jeg tror ikke at det er så udbredt og jeg tror at det meget begrænser sig til store firmaer eller lille software.
Google har ressourcer til at modificere hvad som helst.
Men det lille <10 mands firma går ikke igang med at modificere hverken L, A, M eller P. Allerhøjest tilretter de deres PHP webshop/forum.
#16
Jeg ser mere leverandør uafhængigheden derved at der er frit valg for last level support.
Et Windows kernel problem kan kun fixes af MS. Et AIX kernel kan kun fixes af IBM. Men et Linux kernel problem kan fixes af hvem som helst der har ekspertisen (hvilket jo nok reducerer antallet fra 6 milliarder til 600).
Jeg ser mere leverandør uafhængigheden derved at der er frit valg for last level support.
Et Windows kernel problem kan kun fixes af MS. Et AIX kernel kan kun fixes af IBM. Men et Linux kernel problem kan fixes af hvem som helst der har ekspertisen (hvilket jo nok reducerer antallet fra 6 milliarder til 600).
Nej, men hvis ens kildekode er åben så ekstra mange har adgang til den, burde det være brændt endnu tydligere ind på ens nethinde. Det er desværre sjældent tilfældet.arne_v (15) skrev:Har du noge kilde til at open source udviklere skulle skrive færre kommentarer end closed source udviklere?
Rent kulturmæssigt virker C/C++ langt fra Java og C#, når det handler om dokumentation. Der er ikke en endegyldig standard for hvordan man dokumentere, ikke en fælles måde at auto-generere documentation i de forskellige udviklingsmiljøer/IDEs.arne_v (15) skrev:Har du nogen kilde til at C/C++ udviklere skulle skrive færre kommentarer end udviklere i andre sprog?
Og når man så af en eller anden grund, altid forsøger at vælge så obscure variable navne som muligt, gerne uden type eller bare some pointer, så er mangel på en metode-kommentar med parameter dokumentation, virkelig træls.
Så måske lægger man bare ekstra meget mærke til det i C/C++.
(Sprog som PHP/Python/Ruby er often ligeså slemme, hvis ikke altid.)
arne_v (16) skrev:Men det lille <10 mands firma går ikke igang med at modificere hverken L, A, M eller P. Allerhøjest tilretter de deres PHP webshop/forum.
Det er vel også et open source program. :)
(Selv om nogle stejler fordi PHP ikke kompileres.)
Men hvis et 5 mands firma virkelig har behov for en (mindre) modifikation af L, A, M eller P for at overleve, så skal de da nok finde nogen der vil gøre det.
Det sker ikke med Windows, IIS osv. Så må de gå på røven.
Ja, jeg kan ikke lige se for mig hvordan det skal ske med lige præcis de produkter. Men jeg har set problemet i praksis med andre produkter. Der er firmaer fx. endt med at betale MANGE gange produktets oprindelige pris, for at få leverandøren til at fortsætte supporten. En pris som produktet ikke er værd, lige bortset fra det lille fact, at uden support fra leverandøren vil virksomheden have svært ved at overleve.
Jeg glemte helt:
I mit gamle job var politikken, når vi tog et jquery-plugin ind i vores produkt at hovedudvikleren på interfacet (dvs. mig) skulle gennemgå plugin'et for at se om der var nogle grimme overraskelser i det, men også for at vurdere maintainability og om det overholdt vores kvalitetskrav*.
Det betød alm. test af plugin'et i brug, men også en gennemgang af koden.
Det kan man selvfølgelig ikke altid gøre, men her var de færreste plugins over 1000 linier og derfor til at overskue.
*) Al kode skulle kunne verificeres af jslint, dette blev indført efter for mange fejl, som skyldes ting som udefinerede variabler og andre tåbeligheder som jslint ville have advaret om. Desuden skulle koden også være fri for de værste potentielle memoryleaks.
I mit gamle job var politikken, når vi tog et jquery-plugin ind i vores produkt at hovedudvikleren på interfacet (dvs. mig) skulle gennemgå plugin'et for at se om der var nogle grimme overraskelser i det, men også for at vurdere maintainability og om det overholdt vores kvalitetskrav*.
Det betød alm. test af plugin'et i brug, men også en gennemgang af koden.
Det kan man selvfølgelig ikke altid gøre, men her var de færreste plugins over 1000 linier og derfor til at overskue.
*) Al kode skulle kunne verificeres af jslint, dette blev indført efter for mange fejl, som skyldes ting som udefinerede variabler og andre tåbeligheder som jslint ville have advaret om. Desuden skulle koden også være fri for de værste potentielle memoryleaks.
Windcape (18) skrev:Rent kulturmæssigt virker C/C++ langt fra Java og C#, når det handler om dokumentation. Der er ikke en endegyldig standard for hvordan man dokumentere, ikke en fælles måde at auto-generere documentation i de forskellige udviklingsmiljøer/IDEs.
Så godt som alle har vel kommentarer i .h filerne.
Hvis man vil have javadoc/ndoc funktionalitet kan man kigge på DoxyGen.
Windcape (18) skrev:Og når man så af en eller anden grund, altid forsøger at vælge så obscure variable navne som muligt, gerne uden type eller bare some pointer, så er mangel på en metode-kommentar med parameter dokumentation, virkelig træls.
Variable i C/C++ har altid en type. Og en pointer er altid en pointer til en type (med undtagelse af void*).
Grundlæggende henter jeg aldrig "ren" kildekode ned, med mindre det er public domain (eller det er et javascript som kommer på en webside, etc.), da jeg ikke gider have risikoen for at blive slagtet for at noget af det kode jeg selv skriver også kan findes i random GPL program på nettet, og jeg derfor bryder en GPL licens.
Så for ikke at blive slagtet af rets-fnider fra "åbne" licenser, holder jeg mig fra alt kildekolde der ikke er 100% free-for-use.
Så for ikke at blive slagtet af rets-fnider fra "åbne" licenser, holder jeg mig fra alt kildekolde der ikke er 100% free-for-use.
jeg programmer selv i BlitzMax.
Det var et spil med navn Grid Wars 2, hvis udvikling er langt om længet er stoppet (bedt af Microsoft), men kunne stadig finde spillet.
Source code var med, og var tilfældigvis var skrevet i netop dét sprog.
På en engelsk arcadespil forum var der nogle der savnede undersøttelse af dual analog joystick til 2 porte (Ultra360 fra Ultimarc f.eks.), som jeg så tilføjet dette til spillet, og desuden rettet en lydproblem, samt gjort det mere arcade kabinet venlig, så det kunne indstallerers på min maskine.
Det er vist nok også det eneste gang det er sket at jeg har patchet et program, her dog et spil.
Ellers er det meget sjældent at jeg ser på kildekoden. BlitzMax eller ej.
Det var et spil med navn Grid Wars 2, hvis udvikling er langt om længet er stoppet (bedt af Microsoft), men kunne stadig finde spillet.
Source code var med, og var tilfældigvis var skrevet i netop dét sprog.
På en engelsk arcadespil forum var der nogle der savnede undersøttelse af dual analog joystick til 2 porte (Ultra360 fra Ultimarc f.eks.), som jeg så tilføjet dette til spillet, og desuden rettet en lydproblem, samt gjort det mere arcade kabinet venlig, så det kunne indstallerers på min maskine.
Det er vist nok også det eneste gang det er sket at jeg har patchet et program, her dog et spil.
Ellers er det meget sjældent at jeg ser på kildekoden. BlitzMax eller ej.
#27
Hvis man læser noget GPL kode, og så frigiver det under en ikke-GPL kompatibel licens, så bliver man slagtet hvis det bliver opdaget. Så det er yderst fornuftigt at undgå GPL hvis man vil sikre sig mod at blive sagsøgt.
Du har misforstået hvis du tror GPL handler om at sikre rettigheder til noget som helst. GPL handler om at tvinge alle der bruger ens kode til også at frigive deres rettelser som open-source, som en slags "betaling" for at du frigav din kode i første omgang.
GPL er den mindst frie open-source licens der findes, og er på niveau med Ms-RSL. Udviklere som vil sikre sig så meget som muligt bør undgå at bruge og læse Ms-RSL og GPL til open-source projekter.
Hvis man læser noget GPL kode, og så frigiver det under en ikke-GPL kompatibel licens, så bliver man slagtet hvis det bliver opdaget. Så det er yderst fornuftigt at undgå GPL hvis man vil sikre sig mod at blive sagsøgt.
Du har misforstået hvis du tror GPL handler om at sikre rettigheder til noget som helst. GPL handler om at tvinge alle der bruger ens kode til også at frigive deres rettelser som open-source, som en slags "betaling" for at du frigav din kode i første omgang.
GPL er den mindst frie open-source licens der findes, og er på niveau med Ms-RSL. Udviklere som vil sikre sig så meget som muligt bør undgå at bruge og læse Ms-RSL og GPL til open-source projekter.
Windcape (28) skrev:Hvis man læser noget GPL kode, og så frigiver det under en ikke-GPL kompatibel licens, så bliver man slagtet
Øhh... Then don't do that. Vi snakker ikke om at udgive software, og da slet ikke under en licens man ikke har rettighed til at udgive under.
Windcape (28) skrev:Du har misforstået hvis du tror GPL handler om at sikre rettigheder til noget som helst. GPL handler om at tvinge alle der bruger ens kode til også at frigive deres rettelser som open-source, som en slags "betaling" for at du frigav din kode i første omgang.
Og formålet med det er at sikre, at rettighederne stadig er der. Det har vi snakket om før, og der forstod du vist heller ikke min pointe, så jeg gider ikke komme med den lange forklaring igen.
Windcape (28) skrev:GPL er den mindst frie open-source licens der findes
Joh. Men det eneste den reelt ikke tillader, er at du ændrer licensen på andre folks arbejde. Ja, det er et problem for nogen, men det har altså et formål, uanset om du kan se det eller ej.
Jo, det er faktisk netop det vi snakker om.myplacedk (29) skrev:Øhh... Then don't do that. Vi snakker ikke om at udgive software, og da slet ikke under en licens man ikke har rettighed til at udgive under.
Du forstod det måske ikke, men hvis du LÆSER noget GPL kode, og så skriver din egen kode som er næsten magen til (det kunne være en algoritme eller bestemt måde at lave systemkald på), så kan din kode betragtes som kopiering, og derfor tvinge dig til at udgive hele dit projekt under GPL.
Hvilket kan være problematisk for virksomheder der lever af at producere software (Hvordan tjener din egen arbejdsgiver penge? På velgørenhed?).
Jeg kan sagtens se formålet. Men et formål gør det ikke nødvendigvis rigtigt, gør det?myplacedk (29) skrev:Men det eneste den reelt ikke tillader, er at du ændrer licensen på andre folks arbejde. Ja, det er et problem for nogen, men det har altså et formål, uanset om du kan se det eller ej.
Så det er ydest fornuftigt at undgå GPL hvis man arbejder med software udvikling, og læser andres kode for inspiration. Bedre at holde sig til BSD/MIT lign. licenser, som ikke begrænser dig.
myplacedk (29) skrev:Vi snakker ikke om at udgive software, og da slet ikke under en licens man ikke har rettighed til at udgive under.
myplacedk (29) skrev:Og formålet med det er at sikre, at rettighederne stadig er der.
For lige at dodge din tidligere diskution med Windcape, så er MIT problem med at se GPL-kode følgende.
Skriver jeg et program "A", som indeholder fx følgende:
if (true) {
return;
}
og du har lavet et program "B" der indeholder samme kodestump - OG "B" er GPL, og jeg har hentet "B"'s kildekode, så skal jeg frigive "A" under GPL, også selv om jeg måske har skrevet den stump kode før jeg så "B"s kildekode, da der ellers kan slåes tvivl om jeg har kopieret eller selv skrevet det.
Får at gøre sagen mindre søgt, erstat overstående kodesnip med en algoritme, eller lign. Men fakta er at ovenstående kode ER nok til at jeg pt. kunne blive sagsøgt...
#30+#31
Bare fordi man udgiver software, betyder det ikke at man ikke må læse GPL-kode.
Der kan være yderligere omstændigheder som gør at man skal passe på, men sådan er det jo altid. Jeg må jo også gerne svinge med øksen, medmindre der står nogen foran mig osv.
Vi lever af at køre den software vi skriver, dvs. vi sælger services. Så vi lever af den software vi selv skriver, men vi udgiver den aldrig.
Bare fordi man udgiver software, betyder det ikke at man ikke må læse GPL-kode.
Der kan være yderligere omstændigheder som gør at man skal passe på, men sådan er det jo altid. Jeg må jo også gerne svinge med øksen, medmindre der står nogen foran mig osv.
Windcape (30) skrev:(Hvordan tjener din egen arbejdsgiver penge? På velgørenhed?).
Vi lever af at køre den software vi skriver, dvs. vi sælger services. Så vi lever af den software vi selv skriver, men vi udgiver den aldrig.
Saxov (25) skrev:da jeg ikke gider have risikoen for at blive slagtet for at noget af det kode jeg selv skriver også kan findes i random GPL program på nettet, og jeg derfor bryder en GPL licens.
Windcape (28) skrev:Hvis man læser noget GPL kode, og så frigiver det under en ikke-GPL kompatibel licens, så bliver man slagtet hvis det bliver opdaget. Så det er yderst fornuftigt at undgå GPL hvis man vil sikre sig mod at blive sagsøgt.
Windcape (30) skrev:Du forstod det måske ikke, men hvis du LÆSER noget GPL kode, og så skriver din egen kode som er næsten magen til (det kunne være en algoritme eller bestemt måde at lave systemkald på), så kan din kode betragtes som kopiering, og derfor tvinge dig til at udgive hele dit projekt under GPL.
Saxov (31) skrev:
For lige at dodge din tidligere diskution med Windcape, så er MIT problem med at se GPL-kode følgende.
Skriver jeg et program "A", som indeholder fx følgende:
if (true) {
return;
}
og du har lavet et program "B" der indeholder samme kodestump - OG "B" er GPL, og jeg har hentet "B"'s kildekode, så skal jeg frigive "A" under GPL, også selv om jeg måske har skrevet den stump kode før jeg så "B"s kildekode, da der ellers kan slåes tvivl om jeg har kopieret eller selv skrevet det.
Ah hva ??
Hvis vi snakker ren copyright, så vil en sag komme til at dreje sig om hvorvidt koden er kopieret eller bare er blevet ens ved et tilfælde. Rent konkret hvor sandsynligt er det at man ved et tilfælde producerer N identiske linier. Hvis det er tilpas usandsynligt så bliver I dømt. Og det vil være fuldstændigt samme sag uanset om I har læst det pågældende open source kode eller ej. Koden er tilgængelig og det er ikke muligt at spore hvem der har læst den og hvem der ikke har læst den.
Hvis vi snakker om anden IP (patenter, forretnings hemmeligheder etc.), så er FSF og de fleste andre GPL udgivere stærke modstandere af den slags, så der er der heller ikke nogen risiko.
Windcape (28) skrev:Du har misforstået hvis du tror GPL handler om at sikre rettigheder til noget som helst.
Nej - det er dig som har misforstået noget.
GPL drejer sig præcist om at sikre rettigheder.
Mere præcist slutbrugerens rettigheder.
Der er en naturlig konflikt mellem udviklerens rettigheder og slutbrugernes rettigheder.
GPL har valgt klart side og har valgt at sikre slutbrugerens rettigheder.
arne_v (34) skrev:
Ah hva ??
Hvis vi snakker ren copyright, så vil en sag komme til at dreje sig om hvorvidt koden er kopieret eller bare er blevet ens ved et tilfælde. Rent konkret hvor sandsynligt er det at man ved et tilfælde producerer N identiske linier. Hvis det er tilpas usandsynligt så bliver I dømt. Og det vil være fuldstændigt samme sag uanset om I har læst det pågældende open source kode eller ej. Koden er tilgængelig og det er ikke muligt at spore hvem der har læst den og hvem der ikke har læst den.
Hvis vi snakker om anden IP (patenter, forretnings hemmeligheder etc.), så er FSF og de fleste andre GPL udgivere stærke modstandere af den slags, så der er der heller ikke nogen risiko.
Det er muligt du har ret, men når jeg læser GPL'en igennem siger den:
GPL Licence skrev:
0. Definitions
~snip~
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
GPL Licence
Altså for at noget opretholder definationen "modified work", skal blot en del af programmet være videreført, hvor stor eller lille del man så mener der skal til her, er jo et åbent spørgsmål, men det kan jo være en metode, funktion, objekt, eller måske en mindre del som et par linieres kode.
Og under Section 5 i GPL'en står der at et modified work SKAL have GPL licencen med.
Men igen, jeg har ikke rigtigt sat mig ind i det, jeg har bare valgt at acceptere at sålænge jeg vil release kode under andet end GPL, så er det sikrest at holde sig fra GPL licenceret kode.
#37
Så længe du slet ikke har behov for at lege med GPL-kode, så er det da også fint nok. Man behøver jo ikke vide alt.
Men skulle du få lyst engang, så læs endelig lidt op på det. Der er ingen der kanøfler dig bare for at læse GPL-kode, heller ikke selv om du er programmør.
Jeg har bare én bøn: Husk at du ikke har sat dig ind i det, når du udtaler dig om det. Hvis du havde sagt det lidt tydeligere lidt tidligere, kunne vi måske have undgået dette sidespring. :-)
Så længe du slet ikke har behov for at lege med GPL-kode, så er det da også fint nok. Man behøver jo ikke vide alt.
Men skulle du få lyst engang, så læs endelig lidt op på det. Der er ingen der kanøfler dig bare for at læse GPL-kode, heller ikke selv om du er programmør.
Jeg har bare én bøn: Husk at du ikke har sat dig ind i det, når du udtaler dig om det. Hvis du havde sagt det lidt tydeligere lidt tidligere, kunne vi måske have undgået dette sidespring. :-)
#38,
Men kan du så fortælle mig til en anden gang, hvor det er min læsning af GPL i #37 hopper af sporet. ?
For er det ikke korrekt at GPL siger følgende:
1) En hvilken som helst stump kode i et GPL-program, er i sig selv et GPL beskyttet værk (GPL, Section 0)
2) Et hvilken som helst værk der er baseret på et GPL-program og som bliver frigivet, skal videre licenceres under GPL (GPL, Section 5)
Hvilket må betyde at hvis bare noget kode (fx 1 metode) er kopieret fra et GPL program "A" over i et andet program "B", så skal program "B" frigives under GPL - HVIS det bliver frigivet.
Men fortæl mig endeligt hvor det er jeg laver en fejl henne i den konklusion, eller i mine basis antagelser.
Men kan du så fortælle mig til en anden gang, hvor det er min læsning af GPL i #37 hopper af sporet. ?
For er det ikke korrekt at GPL siger følgende:
1) En hvilken som helst stump kode i et GPL-program, er i sig selv et GPL beskyttet værk (GPL, Section 0)
2) Et hvilken som helst værk der er baseret på et GPL-program og som bliver frigivet, skal videre licenceres under GPL (GPL, Section 5)
Hvilket må betyde at hvis bare noget kode (fx 1 metode) er kopieret fra et GPL program "A" over i et andet program "B", så skal program "B" frigives under GPL - HVIS det bliver frigivet.
Men fortæl mig endeligt hvor det er jeg laver en fejl henne i den konklusion, eller i mine basis antagelser.
#39
Som svar på det du skriver i #39:
Lad være med at kopiere GPL-kode, og udgiv det som ikke-GPL. Ret simpelt:
Mere generelt svar på det vi diskuterer:
Måske overreagerer du bare.
Hvis du har set noget GPL-kode, og derefter skriver noget kode selv, så har du ikke nødvendigvis kopieret. Hvis du har set "i++;" i ét program, og skriver "i++;" i dit eget, så har du ikke kopieret.
Bare lad være med at kopiere direkte, kopiere og obfuskere, skrive af eller på anden måde lade dig "inspirere" på en måde som et normalt menneske burde vide er mere end "inspiration".
Som svar på det du skriver i #39:
Lad være med at kopiere GPL-kode, og udgiv det som ikke-GPL. Ret simpelt:
Mere generelt svar på det vi diskuterer:
Måske overreagerer du bare.
Hvis du har set noget GPL-kode, og derefter skriver noget kode selv, så har du ikke nødvendigvis kopieret. Hvis du har set "i++;" i ét program, og skriver "i++;" i dit eget, så har du ikke kopieret.
Bare lad være med at kopiere direkte, kopiere og obfuskere, skrive af eller på anden måde lade dig "inspirere" på en måde som et normalt menneske burde vide er mere end "inspiration".
#37
Afsnittet du citerer drejer sig om at du laver en modificeret version af GPL softwaren.
Der kan muligvis være grænsetilfælde som er svære at afgøre, men de fleste ved da godt om de er igang med at modificere noget eksisterende kode eller igang med at skrive noget nyt kode.
Afsnittet du citerer drejer sig om at du laver en modificeret version af GPL softwaren.
Der kan muligvis være grænsetilfælde som er svære at afgøre, men de fleste ved da godt om de er igang med at modificere noget eksisterende kode eller igang med at skrive noget nyt kode.
#39
Det her er helt almindelig copright.
Hvis man kopierer copyrighted kode, så skal man følge licensen.
Det er ikke engang specielt for kode. Det samme gælder for bøger. Du kan ikke bare kopiere indholdet af en bog.
Men jeg har aldrig hørt om forfattere som undlader at læse bøger for at undgå at blive beskyldt for copyright krænkelser.
Og ligesom man ikke bliver beskyldt for at have stjålet ordene "Der er" fra en anden bog, så bliver man heller ikke beskyldt for at have stjålet "i++;" fra noget andet kode.
Er der en halv side tekst som er ordret ens i en bog, så bliver det svært at overbevise retten om at det er tilfældigt.
Er der 50 linier (non triviel) kode som er ens byte for byte, så bliver det svært at overbevise retten om at det er tilfældigt.
Diverse argumenter om at man ikke har læst bogen eller ikke har set det pågældende open source kode bliver formentligt ignoreret - det kan ikke bevises.
Det afgørende er hvor meget der skal kopieres for at man kan kalde det en kopi.
Det skal være så meget at det er helt usandsynligt at det er et tilfælde.
Det her er helt almindelig copright.
Hvis man kopierer copyrighted kode, så skal man følge licensen.
Det er ikke engang specielt for kode. Det samme gælder for bøger. Du kan ikke bare kopiere indholdet af en bog.
Men jeg har aldrig hørt om forfattere som undlader at læse bøger for at undgå at blive beskyldt for copyright krænkelser.
Og ligesom man ikke bliver beskyldt for at have stjålet ordene "Der er" fra en anden bog, så bliver man heller ikke beskyldt for at have stjålet "i++;" fra noget andet kode.
Er der en halv side tekst som er ordret ens i en bog, så bliver det svært at overbevise retten om at det er tilfældigt.
Er der 50 linier (non triviel) kode som er ens byte for byte, så bliver det svært at overbevise retten om at det er tilfældigt.
Diverse argumenter om at man ikke har læst bogen eller ikke har set det pågældende open source kode bliver formentligt ignoreret - det kan ikke bevises.
Det afgørende er hvor meget der skal kopieres for at man kan kalde det en kopi.
Det skal være så meget at det er helt usandsynligt at det er et tilfælde.
Miguel mener ikke det er usandsyneligt, http://tirania.org/blog/archive/2007/Oct-03.htmlarne_v (42) skrev:Diverse argumenter om at man ikke har læst bogen eller ikke har set det pågældende open source kode bliver formentligt ignoreret - det kan ikke bevises.
Det afgørende er hvor meget der skal kopieres for at man kan kalde det en kopi.
Det skal være så meget at det er helt usandsynligt at det er et tilfælde.
People that are interested in continuing to contribute to Mono, or that are considering contributing to Mono's open source implementation of those class libraries should not look at this upcoming source code release.
Samme princip gælder for en GPL licens. (Dog ikke for Mono, da det er duo-licenceret)
Altså at man kan blive påtvunget at have brudt en licens, for at være inspiret for meget (f.eks. til navn på en klasse.)
#43
Det er en speciel-case, hvor folk gør noget som er MEGET tæt på at kopiere kode. Der skal ikke meget til, for at krydse grænsen. Derfor må man være en smule ekstrem i sin politik, for at undgå det.
(Jeg tætter på at du tænker på at mono-projektet ikke tillader mono-udviklere at læse kildekoden til den funktionalitet de kopierer.)
Det er en speciel-case, hvor folk gør noget som er MEGET tæt på at kopiere kode. Der skal ikke meget til, for at krydse grænsen. Derfor må man være en smule ekstrem i sin politik, for at undgå det.
(Jeg tætter på at du tænker på at mono-projektet ikke tillader mono-udviklere at læse kildekoden til den funktionalitet de kopierer.)
Korrekt.myplacedk (44) skrev:Jeg tætter på at du tænker på at mono-projektet ikke tillader mono-udviklere at læse kildekoden til den funktionalitet de kopierer.
Og man tænker at Microsoft måske er mere pendantiske end de fleste. Men fra hvad jeg har set, så står FSF klar med fakler og høtyve ligeså snart de ser muligheden for at sagsøge et firma for at bryde GPL.
Der er så mange andre bedre licenser, hvorfor vælge GPL?
Windcape (43) skrev:
Miguel mener ikke det er usandsyneligt, http://tirania.org/blog/archive/2007/Oct-03.html
Jeg kender udmærket eksemplet.
Men der er to ekstra problemer i dette tilfælde:
1) Her er der tale om en komplet reimplementering af funktionalitet. D.v.s. at risikoen for at koden kommer til at ligne er meget større end normalt. Mono kan jo ikke vælge om klassen skal hedde System.Xml.XmlDocument eller System.XML.XMLDocument eller System.XML.Document eller System.XML.DOMDocument. De er nødt til at bruge samme navn som Microsoft. De er nødt til at have præcis samme funktionalitet. Etc.. Så er man altså sårbar overfor klager om kopiering.
Hvis du har planer om at lave en C/C++ compiler med præcis samme syntax (inkl. udvidelser til ANSI standarden) og samme command line switches som GCC, så vil jeg nok også anbefale dig at holde fingerene væk fra GCC kilde teksten.
Men det er vist ikke et udbredt problem.
2) MS er kendt for også at beskytte andre former for IP end copyright. D.v.s. kopiering af kode kan udover copyright infringement også give anledning til patent krænkelser og krænkelser af forretnings hemmeligheder.
Windcape (43) skrev:Dog ikke for Mono, da det er duo-licenceret
Meget lidt af Mono er dual licenseret.
Som jeg læser deres licens side så:
C# compiler - dual license MIT og GPL
andre tools - GPL
libraries - MIT
runtime - LGPL
det som MS har open sourcet - genbrug under MS licens
Windcape (45) skrev:Men fra hvad jeg har set, så står FSF klar med fakler og høtyve ligeså snart de ser muligheden for at sagsøge et firma for at bryde GPL.
Hvad du set??
Alle de eksempler jeg har set har FSF sendt et venligt lille brev omkring licens problematikken, hvorefter firmaet så efter lidt tænketid har besluttet sig for at overholde licensen. Forholdsvis udramatisk.
Ingen fakler eller høtyve. Ingen sagsanlæg. Ingen foged, Ingen BSA.
- Forside
- ⟨
- Forum
- ⟨
- Afstemninger
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
- ⟨
- Afstemninger
Gå til bund