[LICENTIES] Ben ik verplicht de LGPL te gebruiken?

[roeleboel]

Hallo,

Ik heb volgende vraag:

Van een programma dat onder de lgpl valt (openoffice.org) heb ik source-code van c naar java 'vertaald' voor een eigen project.
Van de originele code schiet niets over, behalve de logica erachter.

Ben ik nu verplicht mijn software ook onder lgpl uit te brengen, of heb ik zelf de keuze welke ik gebruik?

Meer concrete info: het gaat over de calc-functie 'days360' die ik herschreven heb naar java, moest dit voor iemand nuttige info zijn.

Wie kan mij hier info geven?

[Verwijderd]

Heb je de licentie op OO.org al doorgenomen?
http://www.openoffice.org/licenses/lgpl_license.html

[Verwijderd]

Als je het op basis van de OOo-source hebt vertaald, dan is jouw code een afgeleid werk, en mag je het dus alleen verpreiden onder de termen van de LGPL. Die zegt:

The modified work must itself be a software library.

Je moet het dus een aparte jar maken voor zover ik het begrijp.

Zolang die jar als library te gebruiken is zonder verdere code van jou, is het een apart programma. Dat deel valt dan dus onder de LGPL, en je moet de broncode daarvan meegeven als je het distribueert.

Jouw programma dat die calc-functie gebruikt mag verder elke licentie hebben die je maar wilt.

I am not a lawyer.

[ Voor 3% gewijzigd door Verwijderd op 08-02-2008 20:30 ]

[RemcoDelft]

Tenzij je het alleen voor jezelf gebruikt, dan hoef je de source niet openbaar te maken. Zodra je een binary weggeeft, moet alles er bij, incl. source en licenties.

[Soultaker]

Het is ook een beetje de vraag hoe letterlijk je de code vertaald hebt. In principe kun je wel bekijken wat de code precies doet, en dat opnieuw implementeren in Java. Je hebt de functionaliteit dan opnieuw geïmplementeerd en niet vertaald van de ene naar de andere taal, en dan kun je wel stellen dat het geen afgeleid werk betreft.

[Verwijderd]

Soultaker schreef op vrijdag 08 februari 2008 @ 20:43:
Het is ook een beetje de vraag hoe letterlijk je de code vertaald hebt. In principe kun je wel bekijken wat de code precies doet, en dat opnieuw implementeren in Java. Je hebt de functionaliteit dan opnieuw geïmplementeerd en niet vertaald van de ene naar de andere taal, en dan kun je wel stellen dat het geen afgeleid werk betreft.

Dat is wel erg vaag. Wat is precies "opnieuw implementeren"? Ik zou het risico niet nemen en gewoon eerlijk de functie in een jar stoppen en onder de LGPL releasen. Zo ontzettend moeilijk is dat nu ook weer niet.

[Keiichi]

Iets stond me bij dat het bij LGPL weer net niet perse hoefde.

[IEF]

Als je de logica erachter 'from scratch' opnieuw implementeert is het niet echt 'afgeleid',
maar eerder een herimplementatie in nota bene een andere taal.

Vraag is natuurlijk: waar ga je het voor gebruiken ? (Commercieel/prive)

Je kunt het ook zien als 'reverse engineering'.. dan blijft er van de LGPL niks meer over natuurlijk.

Dat is juist ook _het_ probleem bij LGPL lijkt mij, wanneer is het 'modifyen' en wanneer is het reverse engineeren?

[ Voor 15% gewijzigd door IEF op 08-02-2008 21:12 ]

[Verwijderd]

Dat is niet alleen het probleem van de LGPL, maar het probleem van de gehele copyright-wetgeving. Maar zeker omdat je de OOo-code hebt gezien, ben je verdacht dat je datastructuren letterlijk hebt vertaald oid. Je bent "tainted" door de OOo-code. Zoals ik al zei, ik zou het risico niet lopen. Het is max een half-uurtje werk om het netjes in een jar-file te stoppen, dus dat is geen probleem.

[roeleboel]

Mijn idee is eigenlijk om een jar-file met een hoop financiele functies publiek beschikbaar te maken. De meeste functies zijn al te krijgen onder een hoop verschillende licenties, maar deze 'days360' ontbreekt vooralsnog (die is in ieder geval niet makkelijk te vinden met google).

Op zich heb ik voor dit doel niks tegen op de lgpl, maar ik zou liever de gpl zelf hebben (idee hierachter: een programma dat met financiën bezig is en verbergt wat het juist doet vind ik niet direct een goed idee)

[Verwijderd]

Je mag een LGPL-lib gewoon forken (wat jij hebt gedaan door het naar Java te vertalen), en releasen onder de GPL:

3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

This option is useful when you wish to copy part of the code of the Library into a program that is not a library.

Kijk wel uit dat je met de GPL ervoor zorgt dat een ernaar linkend programma ook GPL moet worden. Wat zijn precies die "hoop verschillende licenties"? Zijn die allemaal compatible met de GPL? Want het lijkt me sterk dat je zomaar MPL-functies bij een GPL-functie mag stoppen in hetzelfde package/jar. Dat rekt de definitie van "mere aggregation" wel heel erg...

Ik zou proberen om per package/jar 1 licentie te krijgen, zodat het niet te ingewikkeld wordt voor een gebruiker van die library.

Kijk hier voor een Licentie-lijst en hun compatiblity met GPL2 & 3. Als het ingewikkeld wordt kan de Free Software Foundation je misschien beter helpen. Je kan ze altijd mailen.

[ Voor 27% gewijzigd door Verwijderd op 08-02-2008 22:39 ]

[roeleboel]

Als je gaat zoeken op financiele functies voor java kan je (al dan niet betalend) een hoop jar-files vinden, waarvan er een hoop een privé-licentie hebben (gratis gebruik, geen source beschikbaar), of een commerciële licentie (betalend, geen source).

Voor de financiële functies die ik wil verspreiden is er geen licentie-probleem: ik heb de wiskundige formules van al die functies (behalve 'days360') & dus kan ik die zelf implementeren, en bijgevolg ook allen uitbrengen onder de gpl.
'days360' is de enige functie waarin ik geïnteresseerd ben waarvoor er niet direct documentatie over de berekeningswijze voorhanden is, met uitzondering van de broncode van OpenOffice.org...

Allemaal fel bedankt voor de bijdragen!