[cairo] Re: License for cairo changed to LGPL

Nicklas Larsson kilsmo at kilsmo.net
Fri Aug 6 14:39:32 PDT 2004


I would like to comment on David's proposal of a "better" license, not to  
try to change the path taken by the Cairo developers, but only on the  
theme of balancing the needs of the end user and the library developer.

 From the embedded developer's perspective, I think that David's modified  
GPL license would work as a charm. Just take the code, and compile it into  
the embedded product unmodified.

But I think it would fall short when it comes to making sure that all  
improvements is given back to the community. I may have misinterpreted  
something, and I will give an example (this is sa variant of the famous  
CallSecretCode() pattern):

Let's say that the Freetype library used a GPL with linking exception  
license. Then I (or someone else with more Freetype competence) decide to  
write my own antialiasing renderer from glyphs (from scratch, that is,  
without using the old renderer's code). I do that by removing the old  
renderer from the code, introducing a call in the interface to Freetype  
that is SetRenderer(FreeTypeRenderer* renderer). Then I put my renderer  
inside my closed-source application. The result is that I have patched the  
Freetype library, making it impossible to use the patched library without  
writing their own FreeTypeRenderer (or modifying the old one to conform to  
the new interface).

So, is there a way to really avoid CallSecretCode() problems in an open  
source license, that works according to David's intentions?

Regards,
Nicklas Larsson

On Thu, 5 Aug 2004 11:28:18 +0200, Turner, David <DTurner at nds.com> wrote:

>>
>> Around 18 o'clock on Aug 4, "M. Evans" wrote:
>>
>> > To my mind, the wx approach is a very good middle ground.  It lets
>> > businesses sell binaries with or without library changes,
>> and without
>> > worrying about the definition of "linkage."
>>
>> One reason for the switch to LGPL is precisely to avoid
>> 'hidden' changes like these.  We really do want to see any changes  
>> people need
>> to make in cairo for whatever weird environment they're using.  To my
>> mind, the wx license is no more effective at this than the MIT or BSD  
>> licenses.
>>
>
>> Basically, if you use cairo, we want to see what you've done
>> with it, but not any code outside of cairo.  The LGPL provides a
>> reasonably coherant description of what changes are "within the  
>> library" by
>> requiring that the user be able to (in theory) replace the version of  
>> the
>> library used within the resulting product.  The goal is to make it  
>> possible for
>> people to use cairo without disclosing their own code, while still  
>> sharing
>> any changes they've made to cairo itself.
>>
>
> If that's the *primary* goal, why not simplify the problem by releasing
> Cairo under the GPL + linking exception license, which is already
> used by projects like GNU ClassPath, PNet and others. Here it is:
>
>     The source code for the library is distributed under the terms of
>     the GNU General Public License, with the following exception:
>
>     As a special exception, the copyright holders of this library give
>     you permission to link this library with independent modules to  
> produce
>     an executable, regardless of the license terms of these independent
>     modules, and to copy and distribute the resulting executable under
>     terms of your choice, provided that you also meet, for each linked
>     independent module, the terms and conditions of the license of
>     that module. An independent module is a module which is not derived
>     from or based on this library. If you modify this library, you may
>     extend this exception to your version of the library, but you are not
>     obligated to do so. If you do not wish to do so, delete this  
> exception
>     statement from your version.
>
> Pros:
>
>   - no distinction need to be made between dynamic and static linking
>
>   - anybody can use an unmodified version of the library
>
>   - all modifications must be released under either the GPL or
>     the same license. In other words, no "hidden changes" to the
>     library itself are possible.
>
>   - much simpler terms than the LGPL. I believe it's also much
>     simpler to understand. (basically, "use it freely, but release
>     any changes you make to it")
>
> Cons:
>
>   - doesn't provide the user with the "freedom" to "relink" the final
>     product, whatever that means. I think this is the *major*
>     difference, you really need to decide wether you want it or
>     not.
>
>   - some people might find it less 'standard'
>
>   - some GNU nut could make some improvements and exclusively release
>     them under the GPL, but I don't see this as a probable
>
>
> The exception's text could be clarified by replacing
>
>   "the copyright holders of this library give you permission to
>    link this library"
>
> by:
>
>   "the copyright holders of this library give you permission to
>    link *unmodified* versions of this library"
>
> but you get the idea... The FAQ for such a license can be very
> small indeed. Hell, I just took five minutes to write it[1]
>
>
> Does this seem even remotely interesting to you ?
> reasonnable or not ?
>
> Opinions welcomed,
>
>
> Regards,
>
>
> - David Turner
> - The FreeType Project  (www.freetype.org)
>
>
>
> [1] Quick on-the-fly FAQ:
>
>   Q1: Can I use <Project> in proprietary or non-GPL products ?
>
>   A1: YES. Because of the linking exception, you can use
>       unmodified versions of <Project> in any kind of project,
>       and distribute the corresponding binaries under the terms
>       you choose (provided the licenses of all modules are
>       compatible).
>
>       However, to obey the parts of the GPL that are not covered
>       by the exception, you *must* distribute the <Project>
>       sources you used to any user of your product. For example
>       by putting a source archive on your product's media, or
>       by providing a download from your web/ftp site.
>
>       All other sources used to generate your product don't need
>       to be distributed to users, unless specified by their
>       license.
>
>
>   Q2 : Can I use a version of <Project> that I modified for my
>        own use in proprietary or non-GPL products ?
>
>   A2: YES, If you release it under the same license.
>
>       The linking exception only covers code written by
>       <Project> copyright holder(s), and doesn't affect your
>       changes.
>
>       This means that by default, your modified version of
>       <Project> can only be distributed under the "pure" GPL,
>       which doesn't allow redistribution in non-GPL products.
>
>       However, you have the ability to release your modified
>       <Project> under the exact same license (i.e. GPL + linking
>       exception), which would allow you, and *anyone* else, to
>       use it in non-GPL products.
>
>       Note that this however *still* obliges you to distribute
>       the source code of all your modifications to your users.
>
>       Hence, while you can create a modified version of the
>       library, you'll need to release it under the same
>       license to be able to distribute it in your product.
>
>
>   Q3 : Why are you not using the LGPL instead ?
>
>   A3 : Compared to the GPL, the LGPL contains a lot of ambiguous
>        technical terms whose meaning can change with time (e.g.
>        what is the exact meaning of static and dynamic linking
>        in Java ? Think as a lawyer, not a developer !).
>
>        We also didn't want to forbid certain users from using
>        the library (e.g. when the code is in the ROM of an
>        embedded device, there is simply no way to "relink"
>        as mandated by the LGPL).
>
>
>   Q4 : Can I distribute <Project> as a DLL in my product
>
>   A4 : SURE, one good thing about the linking exception is that
>        it doesn't need to distinguish between static and/or
>        dynamic linking. You can distribute <Project> binaries
>        under the format that best suits your need.
>
>        Note that DLLs have the additionnal benefit of allowing
>        easy updates of <Project> to an installed product.
>
>        Unlike the LGPL, this license doesn't mandate that the
>        users have the ability to relink your product with
>        modified version of <Project> at will.
>
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo





More information about the cairo mailing list