Even op commerciële producten projecteren.
Tussen de developer en degene die de doos in de winkel schuift, zitten zo veel schakels dat je je hele bedrijfsproces moet aanpassen om hiermee om te gaan.
Als dit commerciële producten zouden zijn van een machtige leverancier zou dit niet voorkomen cq de kans veel en veel kleiner zijn.
Developers leveren de verkeerde code,
Als je professioneel programmeert dan gebruik je een versie controle systeem daar zou ook de license in gecommit moeten zijn. Lijkt me ook logisch dat je de license kent.
de mensen van de handleiding vinden de GPL te lang en laten 'm dan weg,
Dit kan gewoon niet en zal in geen geval gebeuren bij een grote commerciële leverancier. Als je dit met bijvoorbeeld Microsoft of Oracle programmatuur zou zou je een enorm probleem hebben.
een leverancier zweert dat 'ie alles zelf geschreven heeft terwijl de code exact dezelfde bugs heeft als Busybox
Als een leverancier de binaries van bijvoorbeeld Oracle of Microsoft zou verkopen als zijn code zou dit einde oefening zijn voor de fabrikant. Dan werd het x* geleden schade per product = astronomisch. Lijkt me trouwens ook logisch dat je zo'n fabrikant bij het grof vuil zet als je er ooit achterkomt.
er is statisch gelinkt met LGPL code maar we mogen geen object files van de rest uitleveren van de leverancier daarvan, en zo kan ik nog wel even doorgaan.
Dan lijkt me dynamisch linken een optie. Statisch linken van commerciële software met GPL code is erg dom. Dan zal de rest GPL moeten worden.
Bij Asus is het echt niet per ongeluk gebeurd
zie:
# They appear to have stripped out all attribution. (Kernel modules contain information about the module name, version, and author. This has been removed.)
# They appear to have attempted to hide what they were doing. (All references to "asus_acpi" have been removed, but other identifying features remain.)
Het is hun tweede gpl overtreding
dit is de eerste.
Mogelijk dat het een interne medewerker is. Naar buiten toe is het Asus.
Als dit commerciële producten zouden zijn van een machtige leverancier zou dit niet voorkomen cq de kans veel en veel kleiner zijn.
Grapjas. Hoe groter de leverancier, hoe meer schakels. En hoe meer onzekerheden.
Als je professioneel programmeert dan gebruik je een versie controle systeem daar zou ook de license in gecommit moeten zijn. Lijkt me ook logisch dat je de license kent.
Wat doet een license tekst in een versiecontrolesysteem? We hadden het over een groot bedrijf, toch? Licenties horen door de bedrijfsjurist beoordeeld en bijgehouden te worden. Die weet hoe hij ze moet lezen en hoe de verplichtingen vertalen naar de bedrijfssituatie.
Een van mijn grote irritaties is dat programmeurs zelf licenties lezen en besluiten wat de verplichtingen zijn. "Oh, het is LGPL dus onze code mag gesloten blijven stond op Groklaw". En dan vervolgens statisch linken.
Dit kan gewoon niet en zal in geen geval gebeuren bij een grote commerciële leverancier. Als je dit met bijvoorbeeld Microsoft of Oracle programmatuur zou zou je een enorm probleem hebben.
Noem mij eens 1 MS of Oracle licentie waarbij je in documentatie naar eindgebruikers toe een licentietekst moet opnemen?
[...]
Dan lijkt me dynamisch linken een optie. Statisch linken van commerciële software met GPL code is erg dom. Dan zal de rest GPL moeten worden.
Ik zei LGPL, niet GPL. Je mag gesloten software linken met LGPL software zonder een eis dat die software open moet. Probleem is bij statisch linken alleen dat je dan object files moet meeleveren zodat mensen kunnen herlinken.
Embedded systemen hebben nog wel eens de onhebbelijkheid dat alle code als 1 grote statisch gelinkte blob in het flashgeheugen moet.
Maar ik zeg niet dat die voorbeelden
goed zijn. Ze gebeuren. En je moet je bedrijfsproces elke keer aanpassen als je tegen dit soort dingen aanloopt. Dat is een continu verhaal, je kunt het niet in 1 keer goed ontwerpen. Ook open source policies moet je debuggen.

Grapjas. Hoe groter de leverancier, hoe meer schakels. En hoe meer onzekerheden.
Ik bedoelde hier mee te zeggen dat als de code van bijvoorbeeld Microsoft of Oracle zou zijn dit veel minder zou voorkomen. Omdat ze dan aangeklaagd zouden worden en met veel geld over de brug zouden moten komen.
Wat doet een license tekst in een versiecontrolesysteem? We hadden het over een groot bedrijf, toch? Licenties horen door de bedrijfsjurist beoordeeld en bijgehouden te worden. Die weet hoe hij ze moet lezen en hoe de verplichtingen vertalen naar de bedrijfssituatie.
Als je de code correct importeert zit er standaard ook de licentie bij. Minimaal dat het bijvoorbeeld GPL is.
Ik ben eens dat uiteindelijk de juridische afdeling de licenties moet behandelen.
Een van mijn grote irritaties is dat programmeurs zelf licenties lezen en besluiten wat de verplichtingen zijn. "Oh, het is LGPL dus onze code mag gesloten blijven stond op Groklaw". En dan vervolgens statisch linken.
Dit kan ik me inderdaad voorstellen. Dat zie je hier al welke gedachten er op tweakers leven. Ik denk dat een nadeel van de licenties is dat het niet echt leesbaar is. Dat merkte ik ook toen ik door de GPL ging zoeken.
Noem mij eens 1 MS of Oracle licentie waarbij je in documentatie naar eindgebruikers toe een licentietekst moet opnemen?
De EULA bij bijvoorbeeld een windows CE apparaat neem ik aan?
Het nadeel van GPL is dat bij overtreding de gevolgen voor de schender minimaal zijn. Daarom word er waarschijnlijk bij veel bedrijven niet veel energie in gestoken. Na het publiceren van de code is het weer goed. Als het niet ontdekt word hoef je niets te doen.
Dit is anders bij commerciële bedrijven/code daar kan de schadevergoeding in de miljoenen lopen.
Ik bedoelde hier mee te zeggen dat als de code van bijvoorbeeld Microsoft of Oracle zou zijn dit veel minder zou voorkomen. Omdat ze dan aangeklaagd zouden worden en met veel geld over de brug zouden moten komen.
Mensen die GPL code misbruiken, worden ook aangeklaagd. Harald Welte heeft er bijna een
dagtaak aan. En dat is bijzonder pijnlijk. Je product moet terug, je moet documentatie herzien, broncode bijleveren die je waarschijnlijk niet (meer) hebt, enzovoorts. Om nog maar niet te spreken van de imagoschade.