Kombination von GPL- und proprietärer Software

[Volker Grabsch]

Michael Kesper <mkesper at fsfe.org> schrieb:
> On Tue, Jun 29, 2010 at 12:05:51PM +0200, Volker Grabsch wrote:
> > ich hoffe, dies ist ein geeigneter Ort für meine Lizenz-Frage.
> > 
> > Es ist ein Projekt in Planung, das unter anderem von einer
> > GPL-Library und einer proprietären Library abhängig sein würde.
> 
> In diesem Zusammenhang lesenswert sollte auch das "Linking Paper"
> des European Legal Network sein [0,1].
> [...]
> [1] https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument

Besten Dank für den Hinweis. Aber zumindest die Zusammenfassung
lässt genau die Punkte offen, um die es mir ging:

| Dynamic linking
|
| Legal view: a dynamically linked library may or may not cause the program
| to be a derivative / collective work including the library. Scenario
| dependent on external factors (development process, APIs, existence of
| other libraries with same functionalities)

Ähnlich offen ist der RPC-Fall:

| Interprocess communication
|
| Legal view: No copyleft obligations, as most IPC/RPC involves well
| separated and clearly differentiated programs. In some limited
| circumstances, the intimacy, nature of and organisation of the data
| exchanged could give rise to the two programs being viewed as a single
| work.

Auch wenn offenbar einer RPC-Schnitstelle eher "geglaubt" wird als
einer dyanmischen Library, dass sie separat ist: In beiden Fällen
gibt es Probleme, falls die Kommunikation zu "intim" ist. Was auch
immer das heißen mag.

Wer weiß, vielleicht läuft das irgendwann darauf hinaus, dass man
seine Schnittstellen (APIs, IDLs) als "GPL-konform" zertifizieren
kann, d.h. die Verwendung einer zertifizierten Schnittstelle
garantiert unabhängig Werke im Sinne der GPL. Wer sicher gehen will,
dass er die GPL nicht verletzt, sollte GPL-inkompatiblen Code stets
über eine zertifizierte Schnittstelle anbinden. Das wär's doch. ;-)


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR