- This topic has 14 hozzászólás, 3 résztvevő, and was last updated 18 years telt el by
.
-
Bejegyzés
-
Nekem úgy tűnik, hogy akkor alkalmazandóak a fenti szabályok (a. és b.), ha egy GPL (+ GPL kompatibilis) vagy kereskedelmi (zárt) szoftvert együttműködő fejléceit (incorporate headers) akarod külön LGPL licenc alá helyezni, hogy zárt és nyílt szoftverek egyaránt használhassák. Az általad kiemelt rész azokat a kivételeket tartalmazza, amelyekre (a globális szabad szoftveres – és európai viszonylatban normál – felfogásban) nem vonatkozik szerzői jogi védelem: numerikus paraméterek, adat struktúra elrendezés és hozzáférés, rövid (tíz vagy kevesebb sor hosszúságú) makrók, beépülő funkciók és sablonok. Szerintem ez egy védelem, hogy ne lehessen triviális dolgok miatt perelgetni. Pl. ha írsz egy makrót, ami két vagy több értéket felcserél (swap), akkor ne lehessen zaklatni másokat, akik ugyanúgy valósítják meg.
Nekem úgy tűnik, hogy akkor alkalmazandóak a fenti szabályok (a. és b.), ha egy GPL (+ GPL kompatibilis) vagy kereskedelmi (zárt) szoftvert együttműködő fejléceit (incorporate headers) akarod külön LGPL licenc alá helyezni, hogy zárt és nyílt szoftverek egyaránt használhassák. Az általad kiemelt rész azokat a kivételeket tartalmazza, amelyekre (a globális szabad szoftveres – és európai viszonylatban normál – felfogásban) nem vonatkozik szerzői jogi védelem: numerikus paraméterek, adat struktúra elrendezés és hozzáférés, rövid (tíz vagy kevesebb sor hosszúságú) makrók, beépülő funkciók és sablonok. Szerintem ez egy védelem, hogy ne lehessen triviális dolgok miatt perelgetni. Pl. ha írsz egy makrót, ami két vagy több értéket felcserél (swap), akkor ne lehessen zaklatni másokat, akik ugyanúgy valósítják meg.
Kössz a választ!
Lehet, hogy rossz részletet „vettem elő”.
Igazából az a probléma, amin a múltkor elgondolkoztam az, hogy mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.
Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.
A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell. Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.Kössz a választ!
Lehet, hogy rossz részletet „vettem elő”.
Igazából az a probléma, amin a múltkor elgondolkoztam az, hogy mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.
Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.
A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell. Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.vizsla wrote:Lehet, hogy rossz részletet „vettem elő”.A részlet jó, azt gondoltam speciálisan csak speciálisan a részletre kérdezel rá.
vizsla wrote:mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.Csak úgy lehet, ha az LGPL-es lib külön osztott objektumként megmarad, és a nem GPL kompatibilis lib csak hivatkozik rá.
vizsla wrote:Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.Van egy speciális korlát, forráskód szintjén valóban nem tartalmazhatja, viszont a programkód igen, ha betartod az idézett részlet a.) pontját, vagy az LGPL-es kód 10 sornál rövidebb.
vizsla wrote:A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell.Így van. Az include a nem GPL kódhoz tartozik, a használatára nincs semmilyen korlátozás. A függvényhívás szintén a nem GPL kód része, és a fordító párosítja össze az LGPL implementációval. Most erre nem találok konkrét licenc részletet.
vizsla wrote:Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.Pontosan ez a kiskapu az LGPL, ami a GPL komtatibilis kódot köt(het)i össze a nem GPL kompatibilis kóddal.
Talán így világosabb (GTK+ kód):
Code:// ok, hivatkozás egy fejlécre (itt nem számít mi konkrétan a tartalma)
#includevoid create_gtk_gui ()
{
// ok, data structure layout
GtkWidget *app;// függvény hívás
gtk_init ();/* „app =”: ok, data structure access
„gtk_window_new()”: ok, függvény hívás
„GTK_WINDOW_TOPLEVEL”: ok, numerical parameter
*/
app = gtk_window_new ( GTK_WINDOW_TOPLEVEL );(…)
}
A fenti példa szerintem teljesen rendben van, még megjegyzés sem kell. Akkor kellene kötelezően alkalmazni az a.) pontot, ha 10 sornál nagyobb makró, sablon, vagy beépülő funkció (inline function) van az LGPL-es fejlécben. Tehát az LGPL értelmében minden nem GPL kompatibilis C++ kódnál kötelezően alkalmazandó az a.) pont, ha a C++ STL bármely része alkalmazva van a kódban (pl. std::string deklaráció).
Mivel licenc-ről van szó, a tévedés jogát fenntartom. 🙂
vizsla wrote:Lehet, hogy rossz részletet „vettem elő”.A részlet jó, azt gondoltam speciálisan csak speciálisan a részletre kérdezel rá.
vizsla wrote:mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.Csak úgy lehet, ha az LGPL-es lib külön osztott objektumként megmarad, és a nem GPL kompatibilis lib csak hivatkozik rá.
vizsla wrote:Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.Van egy speciális korlát, forráskód szintjén valóban nem tartalmazhatja, viszont a programkód igen, ha betartod az idézett részlet a.) pontját, vagy az LGPL-es kód 10 sornál rövidebb.
vizsla wrote:A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell.Így van. Az include a nem GPL kódhoz tartozik, a használatára nincs semmilyen korlátozás. A függvényhívás szintén a nem GPL kód része, és a fordító párosítja össze az LGPL implementációval. Most erre nem találok konkrét licenc részletet.
vizsla wrote:Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.Pontosan ez a kiskapu az LGPL, ami a GPL komtatibilis kódot köt(het)i össze a nem GPL kompatibilis kóddal.
Talán így világosabb (GTK+ kód):
Code:// ok, hivatkozás egy fejlécre (itt nem számít mi konkrétan a tartalma)
#includevoid create_gtk_gui ()
{
// ok, data structure layout
GtkWidget *app;// függvény hívás
gtk_init ();/* „app =”: ok, data structure access
„gtk_window_new()”: ok, függvény hívás
„GTK_WINDOW_TOPLEVEL”: ok, numerical parameter
*/
app = gtk_window_new ( GTK_WINDOW_TOPLEVEL );(…)
}
A fenti példa szerintem teljesen rendben van, még megjegyzés sem kell. Akkor kellene kötelezően alkalmazni az a.) pontot, ha 10 sornál nagyobb makró, sablon, vagy beépülő funkció (inline function) van az LGPL-es fejlécben. Tehát az LGPL értelmében minden nem GPL kompatibilis C++ kódnál kötelezően alkalmazandó az a.) pont, ha a C++ STL bármely része alkalmazva van a kódban (pl. std::string deklaráció).
Mivel licenc-ről van szó, a tévedés jogát fenntartom. 🙂
Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?
Akkor pedig nem mindkettőt?
…both of the following…
Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?
Akkor pedig nem mindkettőt?
…both of the following…
vizsla wrote:Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?Pontosan. A nem GPL kód minden egyes gtk.h-s inline fügvényt használó állományába jól látható helyre be kell szúrni egy megjegyzést (általában az elejére), hogy pl. „A GTK+ könyvtár XXX függvényének beépülő implementációjára az LGPL licenc vonatkozik.”.
vizsla wrote:Akkor pedig nem mindkettőt?…both of the following…
Azt hittem egyértelmű. A b.) pont azt írja elő, hogy csatolnod kell az LGPL teljes szövegét a forráskód és a tárgykód mellé. De ettől még a nem GPL kompatiblis alkalmazás nem lesz LGPL-es, hanem vegyes licenc-ű. Pánikra semmi ok, azon kívül hogy fel kell tüntetni a licenc szövegét és a programkönyvtár nevét, nincs más kötelezettség. Itt a C++ STL jobb példa, mivel pl. az std::vector sablon implementációja nem az LGPL-es libstdc++.so-ban van (lesz), hanem a sablont alkalmazó tárgykódban (ami most nem GPL kompatibilis). Ezért kell külön csatolni az LGPL teljes szövegét, ami a végleges kód nagyon kis részére vonatkozik.
vizsla wrote:Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?Pontosan. A nem GPL kód minden egyes gtk.h-s inline fügvényt használó állományába jól látható helyre be kell szúrni egy megjegyzést (általában az elejére), hogy pl. „A GTK+ könyvtár XXX függvényének beépülő implementációjára az LGPL licenc vonatkozik.”.
vizsla wrote:Akkor pedig nem mindkettőt?…both of the following…
Azt hittem egyértelmű. A b.) pont azt írja elő, hogy csatolnod kell az LGPL teljes szövegét a forráskód és a tárgykód mellé. De ettől még a nem GPL kompatiblis alkalmazás nem lesz LGPL-es, hanem vegyes licenc-ű. Pánikra semmi ok, azon kívül hogy fel kell tüntetni a licenc szövegét és a programkönyvtár nevét, nincs más kötelezettség. Itt a C++ STL jobb példa, mivel pl. az std::vector sablon implementációja nem az LGPL-es libstdc++.so-ban van (lesz), hanem a sablont alkalmazó tárgykódban (ami most nem GPL kompatibilis). Ezért kell külön csatolni az LGPL teljes szövegét, ami a végleges kód nagyon kis részére vonatkozik.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz