[PHP] LGPL i.c.m. eigen programmatuur

[TheCrius]

Voor een zakelijk project ben ik van doel om een externe graph library te raadplegen die uitgegeven is onder de LGPL 3.0 is uitgegeven. Nu heb ik het een en ander opgezocht, op de originele site, maar ook op forums maar ik vind het toch allemaal wazig uitgelegd. De meningen over LGPL zijn erg verspreid.
Waar ik achter ben gekomen is dat het geen probleem is als ik de software alleen voor "het bedrijf" gebruik, waar ook de software is gemaakt. Maar hoe zit het als ik de software wil gaan verkopen? Uiteraard wordt er bij vermeld dat de credits van de grafieken naar de desbetreffende ontwikkelaar gaan.
Bij verkoop stel ik me voor dat het complete script wordt overgedragen in bijvoorbeeld een licentievorm.

Bron die ik heb doornomen;
http://www.gnu.org/licenses/lgpl.html

[alex3305]

Voor zover ik weet moet je dan de originele broncode en verwijzing naar de maker meegeven. Dat doen wel meer programma's of spellen bijvoorbeeld. Mocht je echter aanpassing maken aan de software, dan is het de bedoeling dat je deze dan ook weer vrijgeeft. Dat zou je eventueel op de website van het product kunnen doen.

[TheCrius]

Gaat het dan om de originele broncode van het maken van een grafiek en de (onaangepaste) library, of ookde ontworpen databasestructuur, php code met fetches etc?

[Herko_ter_Horst]

Er staat in de licentie toch echt precies wat je wel en niet mag en moet. Je moet vooral kijken naar sectie 4 "Combined Works". De "moeilijkheid" zit in paragraaf d): kun je de graph library los installeren en updaten? Zo ja, dan zit je in principe goed. Zo niet, dan moet je het gedeelte van jouw code dat gebruik maakt van de graph library ook onder de LGPL (of GPL) uitbrengen.

Als je de licentietekst niet kunt "lezen", zou ik in een zakelijke context zeker een professional inschakelen, want: IANAL .

[TheCrius]

Klopt, ik ben ook geen advocaat vandaar de vraag . Het lijkt me erg lastig om nou precies de library te scheiden van je php code waarmee je je dynamisch je grafieken genereert. Maar als ik het bericht van jou mag aannemen, is het dus zo dat die code die ik zou gaan schrijven uit moet worden gebracht onder de lgpl.

[IStealYourGun]

TheCrius schreef op woensdag 07 september 2011 @ 15:06:
Het lijkt me erg lastig om nou precies de library te scheiden van je php code waarmee je je dynamisch je grafieken genereert.

Hangt er een beetje van af. Als het gewoon een class is lijkt me dat héél simpel.

[Herko_ter_Horst]

TheCrius schreef op woensdag 07 september 2011 @ 15:06:
Klopt, ik ben ook geen advocaat vandaar de vraag . Het lijkt me erg lastig om nou precies de library te scheiden van je php code waarmee je je dynamisch je grafieken genereert. Maar als ik het bericht van jou mag aannemen, is het dus zo dat die code die ik zou gaan schrijven uit moet worden gebracht onder de lgpl.

Het criterium zoals ik het lees, is of de library losstaand is en je alleen maar via interfaces tegen het ding praat vanuit je applicatie, of niet. Oftewel: kan ik de library zonder problemen vervangen door een interface-compatible variant ervan?

Eén manier om dat te bereiken, is de library los te installeren/ergens neer te zetten en tijdens de installatie van jouw pakket de locatie van die library te laten configureren. Als dat kan, en je applicatie blijft werken als de gebruiker de library op de bestaande plaats updatet, dan heb je volgens mij aan die voorwaarde van de LGPL voldaan.

Is jouw programma echter totaal verweven met de library, m.a.w. zit de library helemaal "vast" in jouw code, dan moet je het scheidingspunt zoeken tot waar dat geldt en dat geheel onder de LGPL uitbrengen. Dat kan potentieel je hele applicatie zijn.

[Grijze Vos]

M.a.w. zorg dat je een fatsoenlijk wrapper hebt om die LGPL component. Deze wrapper moet je dan ook onder LGPL uitbrengen, de rest van je applicatie niet.

[TheCrius]

Grijze Vos schreef op woensdag 07 september 2011 @ 15:52:
M.a.w. zorg dat je een fatsoenlijk wrapper hebt om die LGPL component. Deze wrapper moet je dan ook onder LGPL uitbrengen, de rest van je applicatie niet.

Inderdaad, bedankt jongens dit is inderdaad de oplossing.