GPL and Pd patches [Was: Re: [PD] a little ot: creative commons]

Frank Barknecht fbar at footils.org
Fri Jun 16 00:56:48 CEST 2006


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__




More information about the Pd-list mailing list