Embedding Bazaar into C/C++ applications

[Brian de Alwis]

On 2-Dec-2009, at 12:49 PM, Russel Winder wrote:
> On Wed, 2009-12-02 at 10:28 -0500, Brian de Alwis wrote:
>> Though using a Boost-generated wrapper will likely invoke GPL licensing issues, if that's a concern.  From previous posts [1], interfacing via xmlrpc should avoid such issues.
> 
> In what way does using Boost invoke GPL?


First off, IANAL, but have looked into this recently (I'm building a product that I intend to go commercial, and considering incorporating bzr to implement some functionality) and worked with companies that were sufficiently concerned about this issue to prohibit use of GPL'd code for development.  Second, I'm assuming that the Boost approach is not invoking Python through some arms-length mechanism (e.g., XML-RPC), but rather starting an embedded Python interpreter and providing some mechanism to share data structures across the language divide. 

The GPL FAQ covers this issue <http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins> (I would consider bzrlib to being a plugin):

> Can I release a non-free program that's designed to load a GPL-covered plug-in?
> 
> It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
> 
> 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, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
> 
> If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
> 
> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

Using Boost to wrap a GPL-covered component doesn't remove the GPL'ness of the wrapped code unless it's using some arms-length approach.  The GPL FAQ covers this too <http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper> [bracketed text is mine]:

> The fact that proprietary module A [proprietary system] communicates with GPL-covered module C [bzrlib] only through X11-licensed module B [boost wrapper] is legally irrelevant; what matters is the fact that module C is included in the whole.

A derivative work must then be licensed under a GPL-compatible license.  I'm not aware of any licenses that are compatible with the GPL other than the GPL itself.  The Wikipedia GPL article has a nice license-compatibility diagram:

	http://en.wikipedia.org/wiki/File:Quick-guide-gplv3-compatibility.svg


I'll point out that this linking interpretation isn't universally accepted, and hasn't been tested in court; the Wikipedia GPL page has some discussion <http://en.wikipedia.org/wiki/Gpl#Linking_and_derived_works>.  And the meaning of "derivative work" likely changes in different jurisdictions.  But the FSF's intent pretty clear, and I'm not prepared to test them!


There are two approaches to avoid this problem.

(1) Ask Canonical to change the license for bzr by either relicensing under the LGPL or add a linking exception like the Classpath exception <http://en.wikipedia.org/wiki/GPL_linking_exception>.  I believe this was asked previously and refused.  I suppose if you have money, you can also pay Canonical to provide a relicensed exception.

(2) Use an arms-length mechanism like communicating across XML-RPC as provided by the bzr-xmloutput plugin.

I'm personally looking at approach #2.  But unfortunately for me, the bzr-java-lib is GPL'd.


There was a good paper in ICSE last year that summarized many of the issues on license compatibility:

DM German, AE Hassan (2009). License integration patterns: Addressing license mismatches in component-based development? In Proc. Int. Conf. Softw. Eng. (ICSE), 188–198. doi:10.1109/ICSE.2009.5070520. <http://sail.cs.queensu.ca/publications/pubs/icse2009_german.pdf>
> In this paper we address the problem of combining software components with different and possibly incompatible legal licenses to create a software application that does not violate any of these licenses while potentially having its own. We call this problem the license mismatch problem. The rapid growth and availability of Open Source Software (OSS) components with varying licenses, and the existence of more than 70 OSS licenses increases the complexity of this problem. Based on a study of 124 OSS software packages, we developed a model which describes the interconnection of components in these packages from a legal point of view. We used our model to document integration patterns that are commonly used to solve the license mismatch problem in practice when creating both proprietary and OSS applications. Software engineers with little legal expertise could use these documented patterns to understand and address the legal issues involved in reusing components with different and possibly conflicting licenses.

--
On bike helmets: "If you think your hair is more important than your brain, you're probably right."  (B. J. Wawrykow)