Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
hmm, although in that thinking [expr] is being used like a lib in traditional software development; just using a gpl'd lib doesn't mean that you have to gpl the thing that uses the lib - does it?
If using means "linking", then yes, it does for GPL, but no, it doesn't for LGPL.
Quoting http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL now:
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the
library.
Looking this up, I found another interesting FAQ directly after it, which might be interesting to our case. My remarks are indented 8 spaces:
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no.
The interpreted program, to the interpreter, is just data; a free
software license like the GPL, based on copyright law, cannot
limit what data you use the interpreter on. You can run it on any
data (interpreted program), any way you like, and there are no
requirements about licensing that data to anyone.
Frank: IMO Pd is an interpreter, patches are interpreted
programs. [expr] can be viewed as an interpreter in itself as
well.
However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it
uses through these bindings. So if these facilities are released
under the GPL, the interpreted program that uses them must be
released in a GPL-compatible way. The JNI or Java Native Interface
is an example of such a binding mechanism; libraries that are
accessed in this way are linked dynamically with the Java programs
that call them. These libraries are also linked with the
interpreter. If the interpreter is linked statically with these
libraries, or if it is designed to link dynamically with these
specific libraries, then it too needs to be released in a
GPL-compatible way.
Frank: I must admit, I don't fully understand above paragraph
yet, probably because I have only a vague view of what "JNI"
and "bindings" are exactly. Is a patch similar to JNI? As I
understand it, it is not: A patch file is not effectively
linked to anything, it is just instructing Pd to link its main
application to other modules/libraries. I also see some tricky
cases coming up here: Assuming I write a closed-source, binary
only external. Someone else uses it in a patch and also uses
[expr] there. Is this someone allowed to distribute the patch
file? Am I, as the author of the binary external, suddenly
violating the GPL without even knowing?
Another similar and very common case is to provide libraries with
the interpreter which are themselves interpreted. For instance,
Perl comes with many Perl modules, and a Java implementation comes
with many Java classes. These libraries and the programs that call
them are always dynamically linked together.
Frank: "libraries which are themselves interpreted" would be
patches shipped with Pd.
A consequence is that if you choose to use GPL'd Perl modules or
Java classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or
Java interpreter that the combined Perl or Java program will run
on.
We should probably consult a lawyer now. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__