LGPL i properetær kode for CANopen

[GeirGrusom]

I forbindelse med implementasjon av CANopen over CANbus så driver vi og leter etter CANopen programvare. Vi fant en som var frigitt under LGPL, men alle steder jeg har kikket så bryter statisk lenking med LGPL. Vi har derimot ikke noe annet valg enn statisk lenking, ettersom dette skal kjøre på en mikrokontroller uten noe omfattende operativsystem (eller engang spesielt mye minne)

Så det virker som vi enten da må lenke inn og frigi alt som LGPL, eller finne på noe annet. Noen som kan utdype, eller vet om noen løsninger på dette? Vi kan også godt betale for løsninger på dette (så lenge det er billigere enn å gjøre det selv selvsagt) så hvis noen vet om noe, så hadde det vært flott.

[asicman]

Hva om du lager en liten dynamisk linker selv som laster inn koden, evt. at du lager en liten wrapper med en hopptabell så du slipper å modifisere adressene i ditt eget kodesegment.

 

Discalimer: IANAL. Det å definere dynamisk linking jurudisk er jeg ikke sikker på. Om det holder at koden lastes separat, eller om den må ligge på disk, flash, e.l.

[NevroMance]

Kravet fra LGPL er vel at du kan lenke den statisk, så lenge du frigir LGPL kildekoden med deres eventuelle modifikasjoner, samt deres propreitære objektfiler. Dette skal så kunne kompileres og linkes for å sikre at objektfilene deres ikke er infisert av LGPL kode.

 

EDIT:

Nå må det også nevnes at statisk linking av LGPL er ett minefelt, og det jeg sier burde taes med ett klype salt og ting burde gåes gjennom av en advokat.

Endret 22. november 2011 av NevroMance

[GeirGrusom]

Vi har vært i kontakt med noen som har skrevet kode for dette, men selvsagt er gratis alltid en fordel (ettersom hele hensikten er å kunne spare litt inn på budsjettet). Vi vil ideelt skrive så få endringer på koden som mulig, men det er jo ikke noe problem å frigi den delen vi har modifisert så lenge vi ikke trenger å frigi hele kernelen.

[TAC-2]

Biblioteklisenser er et minefelt. LGPL kan tolkes forskjellig men de fleste vil si at statisk linking ikke er tillatt uten å tilby egen kode enten i form av kildekode eller objektfiler dersom annet ikke er spesifisert av utviklerne av biblioteket.

 

Det hender man kan få særskilt tillatelse fra utviklerne hvis man kontakter dem, men pass på å da få dette fra alle utviklerne. Hvis det er 2 så er det jo greit, hvis det er 100, noen har dødd og andre har skiftet mailadresse er det mindre aktuelt.

[NevroMance]

Ja, objectfiler er som regel det en maa gi, det vil derimot ikke si at programet maa gjore mer enn aa kompilere.

[asicman]

de fleste vil si at statisk linking ikke er tillatt

 

Men hvordan definerer man statisk linking?

 

Er det at lib.so lastes sammen med app.elf, eller er det at alle adressene til til funksjoner og data i lib.so er referert direkte i fra app.elf, eller begge deler? Hvordan definerer man sammen. Holder det med at det er en NOP instruksjon mellom dem for at de ikke skal være lastet sammen?

 

ld.so som laster lib.so etter (eller under lasting av) app.elf er typisk det man forbinder med dynamisk linking. Men man kan laste lib.so først inn i minnet ved å skrive:

 

LD_PRELOAD=lib.so ./app.elf

 

Hvis dette fortsatt er dynamisk linking så betyr det at det er indirekte referanser som er definisjonen på dynamisk linking, eller at disse indirekte referansene blir bygget under runtime.

 

Eller at GeirGrusom bare trenger å lage en hopptabell som peker inn i canbuslib.so og han kan laste sitt canbuslib.so, hopptabell og applikasjon i fra flash inn i ram. Alternativt laste sin app, NOP, laste canbuslib.so, deretter laste eller bygge hopptabell.

 

Eller sagt på en annen måte: Han kan benytte en evt. ny API komptibel versjon av canbuslib.so uten å måtte rekompilere sitt program. Dersom dette er krav nok for å kalle det ikke statisk linking burde det ikke være så vanskelig å få til, selv på et lite embedded system.

[GeirGrusom]

Dessverre har vi 8 KB RAM tilgjengelig på mikrokontrolleren, så dynamisk lenking er neppe spesielt aktuelt foreløpig.

[asicman]

Nå vet jeg ikke hviken microcontroller det er snakk om, ei heller hvilken verktøykjede eller formater som brukes (elf, coff osv.) eller om programmet kjøres i fra flash (eller hvor mye flash microcontrolleren har) eller i fra sram, men dynamisk lenking kunne bestå i av noe så enkelt som en løkke som kopierer N adresser fra can biblioteket inn i en indirekte referanse tabell (igjen så vet jeg ikke om denne ligger i flash eller sram). Noe som burde være mulig med minimalt bruk ram (hvis N ikke er stor og at den ikke må ligge i sram). Utfordringen ligger nok i å behandle filene på forhånd slik at bygging av tabellen vil bli enklest mulig.

[David Brown]

Det er ikke så enkelt som å si at LGPL tillater dynamisk linking men ikke statisk linking. Den beste måten å finne ut hva som man kan og ikke kan gjøre er å forstå formålet med lisensen. Når du gir ut et program som inneholder LGPL kode, skal brukeren kunne få kildekoden til LGPL biten av deg (ingen krav til kildekoden til resten), de skal kunne modifisere den (og gi vekk kopier av denne kildekoden), og de skal kunne bruke den modifiserte koden i programmet som helhet.

 

Det enkleste måte å oppnå dette er ofte at LGPL koden ligger i en egen dynamisk bibliotek. Da er det enkelt å skille ut kildekoden til den, og kunden kan rekompilere den og bruke den med resten av koden.

 

Men dette er ikke den eneste måten å få det til. Man kan også levere linkable object kode sammen med de nødvendige makefiles slik at kunden kan rekompilere LGPL biten og linker det sammen med din kode.

 

Men før du grave deg for mye ned i dette, er det verdt å ta en prat med forfatteren (eventuelt copyright eieren). Det er nemlig ganske vanlig at folk lager ut sånt kode under LGPL med tanke på at det lar andre bruker det sammen med egen lukket kode i embedded systemer - det er derfor de velger LGPL og ikke GPL. Det er like lett for forfatterer å misforstå detaljer i lisenser som det er for brukerer. Det hender i sånne tilfeller at forfatteren da endre lisensen til MPL (Mozilla Public License) eventuelt en modifisert GPL (FreeRTOS har en god eksempel) eller t.o.m. BSD lisens. Det er også mulig at forfatteren er villige til å gi deg koden under en annen lisens mot betaling.