PFZ.nl - PHP Community: Juridische impact van bijv. GNU GENERAL PUBLIC LICENSE - Discussie - Forum - PFZ.nl - PHP Community

Ha freaks,

Pas sprak ik iemand (achtergrond in rechten) die vertelde dat sommige open source licenties "gevaarlijk" kunnen zijn. Bijv. omdat het je verplicht alles wat je er om heen bouwt ook als open source aan te bieden. In een aantal commerciele situaties zeeeeeer onwenselijk....

Kennen jullie dat? Op internet kon ik weinig zinnige dingen vinden.

Groet!
Sam

Zie de MySQL dual-license. Dat is precies wat je omschrijft.
Je mag de GPL versie gratis gebruiken, maar als je daar commerciële apps op wilt draaien dan erven deze de GPL licentie. Wil je dat niet, dan moet de de commerciële versie van MySQL kopen.

Zo is het mij althans ooit uitgelegd door iemand van MySQL (die zal het dan wel weten :))

Quote

omdat het je verplicht alles wat je er om heen bouwt ook als open source aan te bieden.

Dat is niet waar. OS licenties gebieden je om veranderingen/uitbreidingen op de gelicenceerde code te publiceren, niet om de code die gebruik maakt van de gelicenceerde code.

Soms verbieden ze je wel om de code te gebruiken in een commerciele toepassing.

Maar begin met het lezen van de licenties want daar staat gewoon in wat je wel en niet mag doen.

Ik heb dit topic even verplaatst naar ->offtopic
Het is niet een php probleem opzich. ;)

FUD, dat is wat je in grote hoeveelheden tegen gaat komen wanneer je vragen gaat stellen over de juridische impact van GPL.

Ga je de code van bv. Linux aanpassen of maak je gebruik van Linux? Dat zijn twee totaal verschillende dingen, het eerste verplicht jou om de aanpassingen te publiceren en het twee verplicht jou tot helemaal niets. Dat zijn dus al twee uitersten. Hou wel in de gaten dat je goed weet welke componenten je allemaal gebruikt en welke licenties daar bij horen. Zo is een OS één ding, een database een ander ding, maar de driver om met de database te kunnen kletsen weer een totáál ander ding.

Dual Licence is in elk geval onhandig, je loopt het risico dat je de verkeerde licentie gebruikt zonder dat je het weet.

Kortom, zorg voor goed en volledig licentie- en software beheer. Je MOET weten wat je gebruikt en welke licenties daar bij horen. Dit geldt voor zowel open als closed software, daar zit geen wat administratie betreft, niet zo heel veel verschil in.

Tip: Wanneer je software installeert, krijg je altijd (?) de licentie te zien en moet je deze accepteren. Kopieer deze tekst naar een database voor licentiebeheer en sla het daarin op. Dan weet je altijd wat je op welk moment hebt geaccepteerd. Daarmee kun je dan ook de rest van de administratie gaan opbouwen en bijhouden. Denk bv. aan beperkingen op het aantal gebruikers, processors, hoeveelheid RAM, etc.

Ps. BSD-style licenties hebben mijn voorkeur, geven je de meeste vrijheid en de minste verplichtingen. BSD-, MIT-, Apache- en PostgreSQL-licenties vallen in die groep. Klanten zijn hier ook blij mee, is vrijwel een standaard vraag die ik op m'n bord krijg.

Bart, hoort dit juist niet in Discussie thuis?

Lastig, die nieuwe indeling ;)

En let wel dat je wijzigingen niet verplicht hoeft te delen als het alleen eigen gebruik is of binnen een organisatie.
Pas als je het gaat (her)verspreiden moet je deze wijzigingen delen.

En er is ook een groot verschil tussen GPL en Lesser/Library GPL!
Met LGPL mag je open-source library call gebruiken in een closed-source programma, met GPL is dit verboden.
Het gaat dan echt primair om de verspreiding, als je het voor een eigen gemaakt programma doet dat alleen jij gebruik is er niets aan de hand.

Persoonlijk als ik iets ontwikkel wat open-source is, kies ik het liefst voor GPL omdat je dan de investering enigszins kan beschermen.

Voor grote projecten als PostgreSQL en Zend Framework is dit geen probleem, omdat deze zo'n grote groep ontwikkelaars hebben (en in het geval van Zend, het gebruik zelf al een verdienst is voor andere producten) dat ze geen verlies kunnen hebben als iemand besluit om de boel te forken en zelf iets gaat maken en verspreiden dat gesloten is.

Open Source software ligt veel onder vuur vanwege (zogenaamde) patenten, echter gelden deze niet in Europa en worden ze geregeld ongeldig verklaart omdat er spraken is van prior-art.

Op 10-09-2010 10:18 schreef Boyd Pappot:

Zie de MySQL dual-license. Dat is precies wat je omschrijft.
Je mag de GPL versie gratis gebruiken, maar als je daar commerciële apps op wilt draaien dan erven deze de GPL licentie. Wil je dat niet, dan moet de de commerciële versie van MySQL kopen.

Zo is het mij althans ooit uitgelegd door iemand van MySQL (die zal het dan wel weten :))

Jammer, maar het klopt niet. Zolang je geen wijzigingen aanbrengt in Mysql en die verspreidt hoef je niets van de code te openbaren. Het lastige zit 'm in de connectors, deze zijn ook GPL'ed, en op het moment dat je die embed in je software moet je ook de rest van je app verspreiden onder de gpl license. Een probleem wat dus niet bestaat voor php applicaties omdat normaal gesproken daar geen mysql connector in wordt ge-embed. Voor mysqlnd geldt trouwens iets anders, juist onder andere om dit soort problemen te voorkomen, is dat gereleased onder de PHP license.

Op 10-09-2010 16:26 schreef Freeaqingme :

Jammer, maar het klopt niet. Zolang je geen wijzigingen aanbrengt in Mysql en die verspreidt hoef je niets van de code te openbaren. Het lastige zit 'm in de connectors, deze zijn ook GPL'ed, en op het moment dat je die embed in je software moet je ook de rest van je app verspreiden onder de gpl license. Een probleem wat dus niet bestaat voor php applicaties omdat normaal gesproken daar geen mysql connector in wordt ge-embed. Voor mysqlnd geldt trouwens iets anders, juist onder andere om dit soort problemen te voorkomen, is dat gereleased onder de PHP license.

Het embedden is lastig te definiëren. Als ik een C++ programma schrijf dat gebruik maakt van MySQL en als ik dan gebruik maak van dynamic binding voor de dll bestanden van de connector, dan is de MySQL connector geen onderdeel van mijn programma en mag ik hem gewoon gebruiken zonder de code van mijn programma in de openbaarheid te gooien. Als ik hem inderdaad static ga binden dan geldt de GPL inderdaad wel. Oplossing is dus dynamic binding, wat bijna altijd prima te doen is.

Op 10-09-2010 14:00 schreef Sebastiaan Stok:

Open Source software ligt veel onder vuur vanwege (zogenaamde) patenten, echter gelden deze niet in Europa en worden ze geregeld ongeldig verklaart omdat er spraken is van prior-art.

1) FUD
2) Welke patenten dan? Geen hond die ze bij naam durft te noemen, waarom niet?
3) Zoals je reeds aangeeft, er bestaan geen software patenten in het overgrote deel van de wereld.

Punt 2 is nog het grootste probleem, de patenthouders durfen niks te noemen en al helemaal geen rechtzaken te beginnen. Waarom niet? Zolang ze niet aangeven waar het fout gaat, geloven ze er zelf blijkbaar ook niet in.

Zorg er voor dat je de administratie op orde hebt, zoveel moeite kost dat niet, maar laat je vooral niet afbluffen door een paar FUD-hufters die met lege handen staan. Geen aandacht aan schenken, dat zijn ze niet waard.

Nouja, zo is PDF een mooi voorbeeld, is een open standaard, ISO gecertificeerd. Maar, implementeer je 't niet naar de zin van Adobe, hebben ze wel een aantal patenten om mee te strijden (in de US of A): http://partners.adob...al_notices.html

"2) Welke patenten dan? Geen hond die ze bij naam durft te noemen, waarom niet?"
Daarom zeg ik ook "zogenaamde", want niemand heeft ooit concreet geantwoord.

Op 11-09-2010 10:56 schreef Sebastiaan Stok:

"2) Welke patenten dan? Geen hond die ze bij naam durft te noemen, waarom niet?"
Daarom zeg ik ook "zogenaamde", want niemand heeft ooit concreet geantwoord.

Dat was voor mij ook wel duidelijk, er zijn alleen mensen die nog de illusie hebben dat hier enige vorm van waarheid in schuilt, ook al durft niemand met feiten te komen en dus de daadwerkelijke patenten bij naam en nummer te noemen. En met "niemand" kun je hier denken aan Microsoft, die roepen al jaren e.e.a. over Linux maar tot op de dag van vandaag hebben ze er niemand voor aangeklaagd. Een andere grappenmaker, SCO, is op sterven na dood, ten ondergegaan aan hun eigen wanbeheer en kansloze processen.

Maar goed, terug naar de GPL: Wanneer jij aanpassingen maakt in GPL-code en het resultaat gaat verspreiden buiten jouw eigen servers/pc's, zul je ook de broncode moeten publiceren. Met BSD-style licenties hoeft dat niet, mag je rustig gesloten houden.

Deze opmerking is mij niet helemaal duidelijk:

Op 10-09-2010 14:00 schreef Sebastiaan Stok:

Persoonlijk als ik iets ontwikkel wat open-source is, kies ik het liefst voor GPL omdat je dan de investering enigszins kan beschermen.

Hoe kun je met GPL jouw investering beschermen? Alleen grote multinationals hebben de juridische slagkracht om wereldwijd de boel in de gaten te houden en actie te ondernemen, ik zie jou geen bedrijf in bv. Japan of China aanklagen vanwege misbruik van jouw code.

Quote

. Een andere grappenmaker, SCO, is op sterven na dood, ten ondergegaan aan hun eigen wanbeheer en kansloze processen.

Dat ging over copyright op regels code, linux zou complete libraries 1:1 hebben gekopieerd. Dat was pure bluf van een bedrijf dat op de rand van de afgrond stond, waar ze nu dus ook echt ingedonderd zijn.

Overigens is dat wel een interessant punt want als je de website van GrokLaw bekijkt (die zich in het bijzonder bezighoudt met de SCO zaak) dan zie je een soort van open-source-rechtshulp in actie; een hele community van mensen met een juridische achtergrond zetten zich belangeloos in om uit te zoeken hoe het precies zit.

SCO dacht dat ze met wat juridische hoogdraverij het fenomeen linux wel even zouden doodtrappen (al dan niet in opdracht van Microsoft, sappige roddels beschikbaar) maar net zoals de broncode door een community wordt ondersteud blijkt ook de rechtspositie door een grote groep te worden ondersteund.

De gebruikelijke tactiek van grote bedrijven is om een ingewikkelde rechtzaak aan te spannen en te winnen door het simpelweg onbetaalbaar te maken om hen aan te vechten. Maar als er een groepje vrijwilligers opstaat die er een principe zaak van maakt dan werkt dat niet meer.

Afijn, of je het nu kunt verdedigen of niet, het is altijd beter om wel vast te leggen wat toegestaan is dan om het niet te doen.

Quote

Hoe kun je met GPL jouw investering beschermen? Alleen grote multinationals hebben de juridische slagkracht om wereldwijd de boel in de gaten te houden en actie te ondernemen, ik zie jou geen bedrijf in bv. Japan of China aanklagen vanwege misbruik van jouw code.

Daarom zeg ik ook 'enigszins' ;)