[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

On interpreting licences (was: KDE not in Debian?)



This is partly in reply to messages of Andreas Pour <pour@mieterra.com> on
Fri, 28 Jan and of Jeff Licquia <jeff@luci.org> on Sun, 30 Jan. But mainly it
is about interpreting licences in general and in particular the GPL. This is
not an easy matter, and if differences of opinion arise this is most likely a
consequence of that difficulty, rather than of the other partly being a moron
or simply unwilling to understand the obvious, so I will avoid to make such
implications. I would also like to note that it is not my intention to attack
or defend KDE or Debian or whoever, just to sort things out for myself. One
may note that at some points I express ideas that contradict what I have said
before; don't hold this against me, it just indicates that the enormous load
of words poured out over me this weekend wore not entirely wasted.

My concern is to try to find a way I can read licences that allows me to
answer questions about issues concerning them in a somewhat systematic way.
The first point is the status of licences. As I have said:

> > A licence is just a statement from the copyright holder conditionally
> > lifting the default prohibition of copying of copyrighted material.

That's simple enough. But let me make some definitions to simplify the
discussion. I'll call a copyright holder the "author", the copyrighted
material his "work", somebody who wishes to copy and distribute that work the
"distributor", and the person who is to receive such a copy the "user". I'll
assume the author wishes to allow the distributor to do so under certain
circumstances, to which end he gives a "licence" that gives permission to make
and distribute copies under certain "conditions". Note that in principle the
user is no party in the licence. What complicates matters, at least in case of
the GPL, is that the conditions themselves mention the users, and in part are
concerned with allowing them to become distributors. This also makes terms
like "restrictive" ambiguous; for instance in order to guarantee certain
freedoms for users (and possibly future distributors), the GPL has to be
restrictive with respect to (current) distributors. I'll try to avoid
complications by talking only of obligations of distributors, directly
prescribed by the conditions of the licence.

For the sake of simplicity let us assume this permission is not given
exclusively to a specific distributor, but to the public in general (all
licences considered here use generic language like "Redistribution and use...
are permitted..." or "You may copy and distribute..." without mention of
specific names). One may infer that the author wishes to grant the same
permission to whoever possesses a legally obtained copy of the work: for
copyright law all different copies of the work are embodiments of just a
single item of intellectual property owned by the author, and although the
copyright pertains to the right to multiply those physical copies, it does not
really matter which instantiation serves in the duplication process. The
identity of the distributor is important only to the extent that it is the
person responsible for the conditions being met. [Consequently, I don't agree
with the idea of a licence being an attribute of some copy of the work.]

Firstly, from this it follows that _only_ the author has the right to define
the terms of the licence. Nobody can arbitrarily modify the licence by adding
or removing conditions; in this sense "relicensing" is not possible. Secondly
it follows that anybody having a legally obtained copy of the work receives
the same conditional permissions formulated in the licence, without the need
of an explicit act to that effect; in a sense these permissions were already
given before he received that copy. The fact that many licences state that the
licence has to be preserved when making the copy is therefore logical, in
order that the recipient know his rights, but it is not an act of _giving_
those rights to the recipient (like it is not the copyright notice itself
which makes the work copyrighted). On the other hand it does not follow that
the distributor is bound only by the conditions of the licence; there may be
other conditions, legal or otherwise, that he has to satisfy and that can
affect his possibility to distribute.

A more difficult situation arises when works with different authors are
combined into a single work. It is a situation not really treated in much
detail in copyright law (certainly not with the complications particularly
relevant for computer software in mind), but it is clear that every original
author still has some copyright in the combined work. A case explicitly
addressed by law is that of a "compilation" of works (not in the computer
sense), where each author contributes some clearly identifiable portion and
the editor only holds copyright on the way these are combined; in software
however things may not be as easy to separate (like when someone rewrites
pieces of existing code, or in case of an executable built from multiple
sources). Supposing separation into individual contributions is not well
possible, the combined work has multiple authors which together have copyright
on the whole. Now if they all agree to make that work available under some
licence, they may do so, whatever that licence may be; this is "relicensing"
in the strict sense.

Whether the whole can be distributed without additional explicit permission
from the authors is an important but delicate question; note however that in
cases where no clear positive answer can be deduced, it is always possible to
revert to the easier option of asking the authors to give or confirm (as
needed) permission explicitly. Now if any of them did not permit distribution
of modified version of his original work, the answer is clearly no, since the
combined work can be seen as a modified version of each of the original
ingredients. So in order to have any hope of distributing the combined work,
suppose that each individual author has in his licence given some conditional
permission to distribute modified versions of his work (if the composer of the
combined work has an original contribution to it, he may also impose some
conditions of his own, which are not derived from an existing licence). Then
the general principle seems to be clear to me: in order that legal
distribution be possible, all relevant conditions of all licences must be
satisfied simultaneously. Now each licence probably requires that its
copyright notice and licence conditions be preserved in the modified copy; as
should be clear from the above, this does not imply that the combined work is
distributed under the precise set of conditions in any one of those licences.
A practical matter is how to actually describe the conditions for
redistribution (the effective licence for the whole) to the user; I suppose it
is preferable that the distributor collects all notices and conditions into a
single file, making clear how they should be interpreted (logical AND), and
which condition stems from which author. This would be relicensing in a rather
different sense than above, although effectively the new conditions can
henceforth be considered to be "the" licence given for the combined work.

An interesting question is whether any original licence could require as a
condition that the new licence be identical to it (effectively excluding
combination with any licence whose conditions are not a subset of those of
that first licence). I would say that this is not possible, because if in
order to determine whether one condition is satisfied one has to refer to the
state of the entire collection of conditions (you only have permission to X if
you also have permission to Y but not to Z etc.) there is just no way to
start. This is precisely the kind of stuff that easily leads to logical
paradoxes, so it is simply not acceptable. Any licence may impose whatever
conditions it likes on what the distributor should do or should not do, but
references to the set of conditions imposed on him are without meaning. This
being said, if it is impossible to satisfy all conditions simultaneously, as
would be the case if two conditions contradict each other, distribution of the
combined work would still be impossible.

Let me now interpret a relatively simple licence: [Andreas Pour:]
> Well, I'll make it a bit more difficult for you. Look at the XFree license.
> Clearly even RMS and his followers think it's OK to link GPL with XFree code
> 
>     Copyright (C) 1994-1999 The XFree86 Project, Inc. All Rights Reserved.
> 
>     Permission is hereby granted, free of charge, to any person obtaining a
>     copy of this software and associated documentation files (the
>     "Software"), to deal in the Software without restriction, including
>     without limitation the rights to use, copy, modify, merge, publish,
>     distribute, sublicense, and/or sell copies of the Software, and to
>     permit persons to whom the Software is furnished to do so, subject to
>     the following conditions:
> 
>     The above copyright notice and this permission notice shall be included
>     in all copies or substantial portions of the Software.
> 
> So, on the one hand it permits "sublicensing" of the code, so it may seem to
> be an easier case than BSD. But wait -- it does not say you can sublicense
> under any terms of your choosing, it only says you can sublicense. If you
> dig a bit deeper, in the third paragraph it says, "The above copyright
> notice *and this permission notice* shall be included in all copies . . . of
> the Software".

Personally I don't know what sublicensing is, if the author does not transfer
the copyright (can I deal in permissions that are not mine to give?) so I'll
just ignore that part, it isn't really needed. What is clear is that all
dealing with the software (including modifying, copying and distributing,
which are the things pertinent to copyright law) is restricted only by the
condition that the copyright and permission notice are included in the copy.
Thus the user can always find out who it the author, and that said author does
not impose any further restrictions. It does not say (nor, as I have argued,
could it say) that this single condition should comprise the full set of
conditions for distribution of works derived from the software/documentation.

> <aside> Incidentally, you can see here that X takes a different approach to
> sublicensing than GPL. For a third party to get a license, he must have
> someone who has granted him the license. Under X, it is the intermediary,
> b/c the X license says you can sublicense. Well, sublicensing has its
> problems in law, so the GPL took a different route: in Section 6 the
> original author grants a license directly to the third party, thereby
> (hopefully) circumventing the need for an intermediary to sublicense to the
> third party. How BSD does it, well, I don't think they thought about their
> license much at all :-{. </aside>

Since the original licences address the general public (GPL even has that in
its name) their permissions automatically extend to any potential recipient.
IMHO X need not talk about sublicensing, although it does not hurt. GPL says

    6. Each time you redistribute the Program (or any work based on the
  Program), the recipient automatically receives a license from the original
  licensor to copy, distribute or modify the Program subject to these terms
  and conditions.

which seems to state explicitly what I presumed, except that the permissions
are stated also to extend to any derived work, which might otherwise not be
automatically covered. BSD says

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:

The mention "with or without modification" removes any doubt for me whether
permissions extend to anybody wanting to distribute a derived work.

> Now, commercial X server companies get around the XFree license by not
> distributing the source code at all. (The license does not require you to
> include the copyright notice and permission notice if you distribute a
> derived work of the Software, which is what a binary server is).

I doubt whether you'll find much support for reading the term "copy of the
software" to exclude derived works and in particular compiled binaries. But
commercial X server companies will have no problem in telling their clients
that XFree86 does not forbid dealing in their code, as long as they make
equally clear that the company does forbid that.

> However, GTK and company can't take that "out", because the GPL requires
> them to distribute the source code to X (since it is linked to GTK
> binaries). But XFree says you must permit redistribution w/out restriction.

No it doesn't, and it can't. It doesn't talk at all about permissions I must
give to derived works over which I have (some) copyrights, nor could it
prescribe what I permit or not. It could require me to do something that would
contradict with (not) giving certain permissions, but in fact it doesn't.

Anyway, were you arguing that people stop distributing X/GPL derived code?


Let me now look at the more troublesome passages of the GPL, which is causing
much of our difficulty.

    2. You may modify your copy or copies of the Program or any portion
  of it, thus forming a work based on the Program, and copy and
  distribute such modifications or work under the terms of Section 1
  above, provided that you also meet all of these conditions:

      a) You must cause the modified files to carry prominent notices
      stating that you changed the files and the date of any change.

      b) You must cause any work that you distribute or publish, that in
      whole or in part contains or is derived from the Program or any
      part thereof, to be licensed as a whole at no charge to all third
      parties under the terms of this License.

      c) ...

For one, this does conditionally permit distribution of derived (possibly
combined) works; so far so good. I must admit however that 2b) causes me some
headaches. How am I to "cause any work... to be licensed" if I do not own full
copyrights to that work? The only way I can interpret this is that I must be
able to state clearly to all recipients that they receive the same conditional
permissions (to modify, copy, etc.) described by the GPL that the distributor
exercises, and that there is no charge for obtaining those permissions.
Fortunately, GPL section 6. does actually give those users these permissions,
insofar as the author of the GPL-ed part is concerned. The fact that those
conditional permissions must be applicable to the whole work is
understandable, given that it may not be possible for the user to isolate the
GPL-ed part; however, does this not violate what I said above about not being
able to address the set of permissions within any stated condition? This is
quite subtle but I think it does make sense: the GPL says: as a condition to
the _distributor_, he must ensure that the _user_ receives all the permissions
formulated in the GPL with respect to the entire work. This does of course not
grant those permissions to the user insofar as other authors are concerned,
but if such permissions are lacking, condition 2b of the GPL to the
distributor is not satisfied, and he cannot legally distribute. So the
distributor can evaluate his rights as follows: supposing temporarily that he
can legally distribute, he asks what rights would a recipient of the work have
(these must be determined by inspection of in particular the other licences);
if these include all the conditional permissions stated in the GPL, then
condition 2b) is satisfied, and if all other conditions (of all licences
involved) are also satisfied, then he can legally distribute. I think
"cause... to be licensed" is not the clearest possible language for this
requirement, but I do think my interpretation does follow both the letter and
the spirit of the GPL. The explanation following section 2 does seem to
confirm this:

  But when you distribute the same sections [not derived from the Program] as
  part of a whole which is a work based on the Program, the distribution of
  the whole must be on the terms of this License, whose permissions for other
  licensees extend to the entire whole, and thus to each and every part
  regardless of who wrote it.

Note in particular "permissions for other licensees", that is for recipients
of copies, not for the distributor himself. Note also that the language twice
does not say "under this Licence", which would force a composite licence
identical to GPL, which as I have argued is not a kind of requirement any
licence can make; rather it says "any permissions mentioned in the GPL must be
granted to the user under the same conditions as in the GPL". Surely the user
may be given other permissions, and I think the user may also be
(conditionally) forbidden to do certain additional things, as long as those do
not affect the permissions mentioned in the GPL; what is clearly excluded is
that other licences attach to the same permissions (for copying etc.) to the
user, stricter conditions (such as "never"). One may ask what conditions in
other licences, other than those already contained in the GPL, might be
compatible with it, given that users must be allowed to become distributors,
and that it is unlikely that other licences would grant more liberty to these
users-becoming-distributors than to the original distributor. I would say not
very much: there may be some requirements that are so easy to satisfy, like
having to include a particular copyright notice, that they cannot be
considered a real restraint on the right to (e.g.) redistribute; however, any
requirement that is really burdensome (like having to send a postcard to the
author when distributing copies) would properly be considered a condition
placed on a relevant permission that is more strict than that of the GPL,
causing the user to have less rights than formulated in the GPL. Just to make
the reasoning clear: it would be possible to require the original distributor
(the one who put the derived work together) to do such silly things, as long
as his recipients are not required to do so as well.

Thus, when Jeff Licquia says
> With the KDE/Qt license, the plain language of the GPL expressly forbids
> distribution with more restrictive licenses. Thus the controversy.
I agree, because he says "with", not "under": it is possible that the
distributor is bound by more strict conditions than those in the GPL alone,
but users must receive all rights addressed by the GPL with respect to the
entire work, without extra restrictions. If they don't, the distributor is
violating the conditions of the GPL, and should not distribute unless he can
obtain permission to do so by other means (i.e., explicitly from the author).

And to Andreas Pour's remark
> > I think it is a bit strange, don't you, to be coy about the requirement to
> > license the whole thing under the GPL? If that was the intent, why was it
> > not said clearly?
I reply that it would not be possible to require licensing the whole thing
under exactly the GPL; in effect however the GPL does not give much room for
deviation from its set of conditions.

In its own section 2 of GPL is not too essential to the KDE/Qt issue, since it
deals with source code that is too interwoven to be split into separate parts:
disjoint sources that are merely aggregated together, possibly even in a
single tar-file (distribution medium), need not be considered as one work,
even if they can be compiled and linked to form a single executable. But in
order to be able to distribute such executables, one has to satisfy the
conditions of section 3. These say in plain language that binaries must be
accompanied by complete sources, which distribution is in turn subject to the
conditions of sections 1 and 2 of the GPL. So in this case distribution of
non-GPL-ed source code must still be subject to the conditions discussed above
for combined works, if that source is part of the "complete sources" of the
binary distributed, and the exception for OS components does not apply.

I suppose that a program dynamically linked against a library does not contain
any of the code of that library, so does the source for that library count as
part of the complete source for the dynamically linked "executable"? GPL says

  For an executable work, complete source code means all the source code for
  all modules it contains, plus any associated interface definition files,
  plus the scripts used to control compilation and installation of the
  executable.

Possibly the letter allows exclusion of the sources for the library in this
case, because the binary does not contain any modules of the library, and even
the interface definition files for the library may be considered to not be
associated to the modules that are included in the binary (even if they are
used by those modules). However, such reading does seem to violate the spirit
of the GPL, since (1) the term "complete sources" itself does not suggest this
reading, (2) it rests on a somewhat technical distinction between dynamically
linked and statically linked executables, (3) what would the purpose of
requiring inclusion of scripts be, other than to allow using them to recreate
a modified binary after changing the sources, requiring at least access to the
interface definition files of the library, and (4) such reading makes the
exception for OS components mostly unnecessary (do executables usually contain
modules that also classify as "anything that is normally distributed... with
the major components... of the operating system on which the executable
runs"?). As for reason (2), how would the intent of the GPL, which is clearly
to ensure that anybody using GPL-derived programs is able and free to improve
the sources and redistribute, be served by allowing dynamically linked
binaries where it forbids statically linked ones?

Yet, why has nobody recently put forward this way of resolving the KDE/Qt
issue? I've seen drastic bending of the meaning of much more unambiguous parts
of the GPL. Maybe this was discussed and resolved long ago, or maybe I'm just
too blind too see the obvious? Anybody please explain.

And then there is the OS components exception with it's exception to the
exception:

  However, as a special exception, the source code distributed need not
  include anything that is normally distributed (in either source or binary
  form) with the major components (compiler, kernel, and so on) of the
  operating system on which the executable runs, unless that component itself
  accompanies the executable.

I do not find it difficult to construe often used libraries (libc, curses, X,
...) as things being normally distributed with the kernel of the operating
system, so why could Qt not be added to the list? Or is it the exception to
the exception that spoils the feast? Jeff Licquia wrote

> But this doesn't help Debian; the question of separation is by no means
> settled. Qt is in main, where it belongs (the QPL is DFSG-free). If we
> distribute KDE, then the two are being distributed together. At that
> point, the "system libraries" clause kicks in.

That's a bit vague, given that the GPL never mentions system libraries. I will
assume you are not referring to the exception of OS components itself, since
it's application would resolve the problem; I suppose that you mean that parts
"being distributed together" matches "accompanies the executable" in the GPL,
whence the exception to the exception "kicks in" and in fact prevents
application of the OS components exception. Here I wonder if you aren't
reading more into the GPL than is intended. It explicitly states elsewhere
that aggregation on a storage or distribution medium does not cause the
formation of composite works, and while that does not apply to this particular
sentence, do you really think it would consider a component to "accompany the
executable" if it resides on the same CDROM, but not if it would reside on a
separately distributed one? What would the purpose be of making such a
distinction? Personally I don't really understand why the exception to the
exception is needed, but I suppose it is to avoid that people mark some part
which really belongs to a particular program as "OS component" just to escape
the GPL requirement. But Qt being (I suppose) a library of general
applicability, I can see no such abuse in this situation.


As to resolving the KDE/Qt issue, I would suggest the following (don't ask me
to do it, my interest is purely philosophical), assuming there is genuine
desire to include KDE in Debian. Those who think that distributing binaries
would violate the conditions of the GPL should formulate exactly which clause
would be violated and why, and why no exception is applicable. Then one should
locate all authors of GPL-ed code being used in KDE (whether or not KDE
developers), present them the analysis of the situation and ask them
permission to nevertheless distribute, either be stating explicitly that they
do not agree with that reading of the GPL and consider permission to be
granted in the original licence (certainly accompanying the licence by such a
statement by the author would justify having permission), or if they do agree
by granting explicit permission as an exception (Debian would probably insist
that this explicit permission be granted to the general public, not just to
them, but why should that be a problem). In case an author should agree with
the reading of the GPL _and_ in fact object to distribution of his code in
KDE/Qt, then it can be considered to actually sue RedHat/Corel/SuSe/... on
this issue. After all, if you are claiming copyrights, you should at least
consider the possibility of defending them when you feel they are violated,
lest there be no point in claiming the rights in the first place. I guess it
would be wise though to consult the FSF before proceeding to such actions. But
really, if there is an obvious violation of the GPL going on it is in
everybody's interest that appropriate action be taken.

Marc van Leeuwen
Universite de Poitiers
http://wwwmathlabo.univ-poitiers.fr/~maavl/


Reply to: