Licensing of wrappers around C/C++ code under more restrictive licensing.

[Mike C. Fletcher]

Andrew Koenig wrote:

>"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message
>news:mailman.1.1078031359.21439.python-list at python.org...
>
>  
>
>>The FSF peoples seem to have a different interpretation, as, last I
>>heard, they suggest that software that links to any GPL software, even
>>at run-time constitutes an infringement (regardless of your not having
>>distributed the GPL code yourself, and the end-user having a perfectly
>>valid license to link the two for personal use).
>>    
>>
>
>Can you provide evidence to support this claim?
>  
>
Mmm, evidence, always fun to research...

A quick search didn't turn up any statements which are black and white 
on the particular issue of a "scripting language" API.  As noted in the 
paragraph above, I was going by other people's statements.  Closest 
thing I could find were these:


            What is the difference between "mere aggregation" and
            "combining two modules into one program"?
            <http://www.fsf.org/licenses/gpl-faq.html#TOCMereAggregation>

    Mere aggregation of two programs means putting them side by side on
    the same CD-ROM or hard disk. We use this term in the case where
    they are separate programs, not parts of a single program. In this
    case, if one of the programs is covered by the GPL, it has no effect
    on the other program.

    Combining two modules means connecting them together so that they
    form a single larger program. If either part is covered by the GPL,
    the whole combination must also be released under the GPL--if you
    can't, or won't, do that, you may not combine them.

    What constitutes combining two parts into one program? This is a
    legal question, which ultimately judges will decide. We believe that
    a proper criterion depends both on the mechanism of communication
    (exec, pipes, rpc, function calls within a shared address space,
    etc.) and the semantics of the communication (what kinds of
    information are interchanged).

    If the modules are included in the same executable file, they are
    definitely combined in one program. If modules are designed to run
    linked together in a shared address space, that almost surely means
    combining them into one program.

    By contrast, pipes, sockets and command-line arguments are
    communication mechanisms normally used between two separate
    programs. So when they are used for communication, the modules
    normally are separate programs. But if the semantics of the
    communication are intimate enough, exchanging complex internal data
    structures, that too could be a basis to consider the two parts as
    combined into a larger program.

Also:

    However, in many cases you can distribute the GPL-covered software
    alongside your proprietary system. To do this validly, you must make
    sure that the free and non-free programs communicate at arms length,
    that they are not combined in a way that would make them effectively
    a single program.

    The difference between this and "incorporating" the GPL-covered
    software is partly a matter of substance and partly form. The
    substantive part is this: if the two programs are combined so that
    they become effectively two parts of one program, then you can't
    treat them as two separate programs. So the GPL has to cover the
    whole thing.

And:

    If the program dynamically links plug-ins, and they make function
    calls to each other and share data structures, we believe they form
    a single program, so plug-ins must be treated as extensions to the
    main program. This means that linking the GPL-covered plug-in with
    the main program would violate the GPL. However, you can resolve
    that legal problem by adding an exception to your program's license
    which gives permission to link it with the non-free main program.

Which is from the GNU.org FAQ. here:

    http://www.fsf.org/licenses/gpl-faq.html

Now, the first two quotes don't explicitly state that, in the event that 
you let *someone else* distribute the GPL software, you are okay with 
using direct and intimate communication (which the Python module being 
discussed would, I think, qualify as). However, that is the image that 
arises.  That is, if you are not distributing the GPL software you might 
be okay, if not for that third paragraph.

The first two quotes suggest that, if your software links "intimately" 
with the GPL software and you distribute both pieces of software (even 
though only "alongside" one another, (such as two download links from a 
web-site?)), though, then your package is a derivative work and thus 
GPL-requiring. 

The third quote, however, goes much farther.  A plug-in, presumably 
downloaded entirely separately from an application (hence plug-in) is 
somehow able to violate the license of the plug-in merely by being 
loaded by the proprietary application, effectively by being "linked in" 
by the user.  In the situation we are describing, a GPL library with an 
arguably more intimate linking (the Pythonic interface) is being loaded 
into a proprietary application, we would seem to have met all of the 
conditions outlined in that third paragraph (and more). 

To make that work, the using application somehow has to be a derivative 
work of the plug-in, which, particularly in the case of a plug-in API, 
makes no sense, after all, the plug-in API is from the application and 
almost certainly has no code specific to the GPL-licensed plug-in.  What 
would stop a user from using the plug-in with the application?

How this works, (other than wishful thinking) I don't know, as it had 
been my impression that the unmodified use of GPL software on your own 
computer wasn't affected by the GPL. The strange thing about the third 
quote is that, from the GPL section 0 (the FAQ has no legal weight AFAIK):

    Activities other than copying, distribution and modification are not
    covered by this License; they are outside its scope. The act of
    running the Program is not restricted, and the output from the
    Program is covered only if its contents constitute a work based on
    the Program (independent of having been made by running the
    Program). Whether that is true depends on what the Program does.

which seems to allow the *end user* to combine proprietary code with 
unmodified GPL-licensed software for their own use.

As mentioned in the earlier message, I don't think there's been too much 
case law saying that you can claim copyright on something which doesn't 
include any of your code, the LGPL even explicitly states (section 5), 
if there's no LGPL code in the given element, then it is not a 
derivative work.  Still, there must be some logic which makes the 
application above somehow a derivative of its plug-in.  Though again, I 
was under the impression that, for personal use, you could create 
derivatives which linked against proprietary code (even intimately)...

Anywho, hope that's sufficient, must be off to write now.
Mike

(In case anyone is silly enough to think I were... "I am not a lawyer")

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/