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

[Graham Dumpleton]

On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:

> Graham Dumpleton wrote:
> ...
>
>> So, how can one cast the licensing so as to provide an exception that
>> provided the underlying C/C++ library isn't changed, that the Python
>> wrappers can be used under a less restrictive license. I have control 
>> of
>> the licensing on both so can stipulate exceptions, but what is the
>> best way of doing it?
>>
>
> ...
>
> If I understand correctly, the QPL is basically a dual license 
> encouraging you to either pay Trolltech or GPL your software.

I presume you actually meant to say "QPL" and not "GPL" in this 
sentence.

Anyway, have been looking at the QPL again, and as far as I can see, it
doesn't force you to make any code you write which links with the QPL'd
library available explicitly under the QPL. What it says is:

6. You may develop application programs, reusable components and other 
software items that link with the original or modified versions of the 
Software. These items, when distributed, are subject to the following 
requirements:

  a. You must ensure that all recipients of machine-executable forms of 
these items are also able to receive and use the complete 
machine-readable source code to the items without any charge beyond the 
costs of data transfer.

  b. You must explicitly license all recipients of your items to use and 
re-distribute original and modified versions of the items in both 
machine-executable and source code forms. The recipients must be able 
to do so without any charges whatsoever, and they must be able to 
re-distribute to anyone they choose.

  c. If the items are not available to the general public, and the 
initial developer of the Software requests a copy of the items, then 
you must supply one.

Thus, as far as I can tell, it would be quite okay to make the Python
wrappers themselves available under a BSD/MIT type license as opposed
to the QPL license.

Overall though, this probably doesn't make much difference however
as anyone using the Python wrappers still in effect has to wear the
underlying conditions of the QPL licensed code. That is, the end
application still has to be made available under terms in line with
the Open Source model if distributed. The only Open Source license
you definitely wouldn't be able to use is the GPL since it regards
the QPL as incompatible.

If you agree with Open Source, that the QPL license is still used
for the C++ code in the runtime loadable component shouldn't be an
issue. We are therefore back to simply not satisfying those who don't
want to pay money for an alternative license if they want to make
money off there own application by selling it.

To meet other requirements I have, if I wanted to not restrict use
in for sale software, I almost need a LGPLish version of the QPL.
Noting that the reason I couldn't use the LGPL was because I need
the control enforced by the following clauses of the QPL.

3. You may make modifications to the Software and distribute your 
modifications, in a form that is separate from the Software, such as 
patches.

That is, need to be able to say that the original package must always
be redistributed as is, ie., in the form provided, with any changes
being in a distinct package, such as a patch. I believe this should
also prevent a free for all as far as people taking/stealing just bits
of the package and reusing it in other things, but then in practice
that is almost impossible to enforce. :-(

If one had a LGPLish variant of the QPL which doesn't transfer
conditions on linking, problem may be solved. I don't however now
of any Open Source license which does that. Does anyone else?

IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.