[cairo] Re: License for cairo changed to LGPL
kilsmo at kilsmo.net
Sat Aug 7 10:10:06 PDT 2004
On Fri, 06 Aug 2004 23:39:32 +0200, Nicklas Larsson <kilsmo at kilsmo.net>
> So, is there a way to really avoid CallSecretCode() problems in an open
> source license, that works according to David's intentions?
I will answer this myself (couldn't stop thinking about it).
First, I would like to apologize for sending this lengthy message to the
Cairo list, but since license issues are important, and I have come up
with a solution that I find interesting, I decided to post it anyway.
People not interested in these issues will probably skip all comments in
this thread anyway.
I think I have found a solution to my (and other people's) objections to
most free software licenses that tries to combine free usage of free
software, and at the same time making sure that changes to the software is
made available to everyone. I may have (read: probably most likely have)
missed something, which will make my suggested license worthless.
If there is a very similar license solution out there (which there
probably is, since most good and bad thoughts usually already have been
thought by someone else) please tell me where.
I do not know how to write a proper license (I do not even know how to
read one properly), so I will not even try. I will, however, try to
describe how my suggested license should work.
I have tried to make this text as short as possible, I found that it was
very easy to use much more words than what is included in this message. My
original text was probably twice the size of the current one.
IGPL (Interface GPL), is a license with the following goals:
* GPL compatible.
* All source code changes must be made available.
* CallSecretStuff()-changes are not allowed.
* Code can be statically linked within a closed source application.
These are goals shared by David Turner's suggested license, and also by
some other licenses. I think that a lot of people would like such a
license for their projects. There are only two other different open source
license goals that I think is needed, one is inside the GPL, where the
freedom of the code is guranteed, and the other is inside BSD-like
licenses, where the freedom of the user of the code is guranteed.
So, let us dive into the IGPL.
Source code licensed with the IGPL has two types of source code,
implementation and interface. Each line in the source tree will be either
implementation or interface. The interface parts must be marked out in one
way or another. A source file may consist of both implementation lines and
Note that the terms implementation and interface is used as terms in the
license, and is not the same (but often similar) as what a programming
language and software developers mean with such terms.
So, what are you allowed to do with the implementation part of the IGPL:ed
code, and what are you allowed to do with the interface part?
First, I introduce a new abbreviation:
IGPLS: A source code package released under the IGPL.
* Can only use (call) code in the IGPLS's implementation and in the
* Can only be used (called) from code in the IGPLS's implementation and
the IGPLS's interface. That is, cannot be used (called) from something
outside the IGPLS.
* Can be changed by anyone, as long as the change is published under the
IGPL or the GPL.
* Can be used (called) from the IGPLS's implementation, the IGPLS's
interface, and other code, too.
* Can only use (call) code in the IGPLS's implementation, and the IGPLS's
interface. Callbacks to other code will also work, as long as the
interface to the callbacks are defined in the IGPLS's interface.
* Can only be changed by the copyright holders of the IGPLS's interface in
consensus (and then the source code will still be IGPLS), or changes
released under the GPL.
IGPL and GPL
As I said in the beginning one goal of the IGPL is to make it compatible
with the GPL. The way that I try to achieve that is to allow changes to
IGPL source code that is released under the GPL. What happens with the
IGPL source code then is that it is treated as it was all GPL, as soon as
a GPL patch is added, that is, the source code can no longer be used
together with non-GPL code.
Flaws and comments
Obviously, there are flaws in my IGPL "license". I will comment on things
that I am already aware of, and would appreciate if other flaws were found
and commented on too.
What if I want to use other code from inside the IGPLS. It is currently
not allowed. One way to do that is to allow IGPLS to use the interface to
another IGPLS, just like any other code. Then there will also be a problem
with code released under another license, as the LGPL. I will leave that
out of scope for now.
Another thing that I have not talked about is older versions of the IGPLS,
and forks of the IGPLS.
1. Q: Can I really use a IGPLS in my closed source product, statically
A: Yes, you can, as long as:
a) You only use (call) the interface part of the IGPLS.
b) You do not change the interface part of the IGPLS.
c) You publish all the source code changes that you have made to the
implementation part of the IGPLS.
2. Q: Is the IGPL protected against CallSecretStuff()-abuse?
A: Yes, it is, since:
a) The implementation part of the IGPLS is only allowed to use things
available inside the IGPLS.
b) Noone is allowed to make changes to the interface part of the IGPLS,
without the current copyright holders' acceptance in consensus.
3. Q: Will my "Free as in speech" rights be fulfilled when using an IGPLS?
A: Yes, they will.
You can always make GPL:ed changes to all parts of an IGPLS. That way you
can make all free changes to the source code as you would like. However,
noone can use the modified source code together with non-GPL code.
4. Q: Will the IGPL make sure that changes made to an IGPLS can end up in
the main version of the IGPLS?
A: Yes and no.
a) Changes made by anyone that is not doing the change under the GPL, must
release the change under the IGPL, and can be merged back to the main
version of the IGPLS.
b) Changes released as GPL cannot be merged back to the IGPLS, but can
only be used with GPL:ed source code. This is a very small price to pay,
and is the only way to assure the "Free as in speech"-goal.
5. Q: What if I need to make a change to an IGPLS' interface part, but at
least one of the copyright holders will not accept the change?
A: It is a little bit tricky.
a) As long as you use the GPL, you are not locked-in by the copyright
holders. You can always make GPL changes to the source code, if you need
b) You may be able to find an earlier version of the IGPLS, before the
copyright holder that is stopping your patch had copyright to anything in
the interface part of the IGPLS.
c) You should make sure that the goals of the IGPLS seems to be on track
with your own goals, or is able to change their view. If the IGPLS is not
fulfilling your needs from the beginning, and you have to go for non-GPL,
you should really make sure that you are not painting yourself into a
5. Q: Using words like interface and implementation, is that wise to do in
A: It depends.
Since the meaning of the words are defined in the license, it is rather
safe. Noone should be able to argue what is interface and what is
implementation, and therefore misuse of the license will be hard, without
actually breaking the license terms.
6. Q: What about people violating the IGPL?
A: First of all, it is impossible to write a license that will gurantee
that noone will violate it. Then, it is hard to write a license so that
you can control if someone is violating it. For example, with the GPL, you
just need to hide the code inside your closed source product, and in most
cases noone will find out. However, the license need to state what is a
violation, but it is not up to the license to describe how to catch the
violators. Source code released under the IGPL can be stealed as easily as
source code released under the GPL.
More information about the cairo