Re: Linux and GPLv2
Sean Kellogg <skellogg@u.washington.edu> writes:
> On Sunday 13 March 2005 02:12 pm, Måns Rullgård wrote:
>> It's also rather interesting how people, apparently without much
>> reflection, release code under terms, the interpretation of which is as
>> yet undefined. Given the grayness of these legal areas, and the lack
>> of prior case-law, the outcome of a court case concerning the GPL
>> could be just about anything.
>>
>> Although it is often the case, that the choice is between releasing
>> under terms that might be overthrown, or altered, by a court, and not
>> releasing at all, simply taking the statements from the FSF regarding
>> interpretations about the GPL, such as the GPL FAQ, at face value,
>> must be regarded as somewhat misguided. Since this is the
>> interpretation the FSF would want to see, and wishes were possible,
>> they are quite unlikely to make any statements to the contrary. At
>> the very least, someone contemplating releasing his code under the
>> GPL, should review some independent analysis of its terms, even if the
>> the GPL FAQ seems compelling.
>
> Well, there are lots of good reasons to have as many FOSS works
> under one single license as possible. As a matter of policy, FOSS
> works well because there are very low transaction costs to share
> work between developers. Outside of the FOSS world it takes a dozen
> lawyers to allow two developers to share work... its inefficient
> and to be avoided (that's the main thinking behind Collective
> Commons).
While you have a valid point, the current situation is that there are
a multitude of sometimes incompatible licenses out there. When
choosing a license for software one is about to release, one should
not simply choose one, more or less at random, that "looks OK", but
rather carefully consider the implications of using this particular
license, paying attention to what already existing software the new
work might be usefully combined with. If it is natural to combine it
with, for instance, OpenSSL, it is a good idea to choose a license
that allows this, while still granting/restricting the freedoms of the
user as is seen fit. I have the feeling that such issues are often
overlooked, leading to unnecessary duplication of work, which was not
at all the primary intention of the author in his choosing a
particular license.
> As for grey areas, there are fewer than you might think. There is a
> lot of chatting going on between lots of involved groups as to what
> one clause of the GPL means in very particular situations. While of
> all of it is quite fascinating, I suggest they are not the questions
> that matter to the vast majority of developers. So long as everyone
> sticks with the GPL, then everything is okay.
Here's something for you to think about. I have written a program
heavily based on plugins. In fact, the core is nothing but a plugin
loader, and all real work is done by the plugins. The core is under
the MIT license. Plugins must implement one or more of a number of
separately defined interfaces, and are loaded automatically at runtime
at the moment they are needed. For example, there is a URL interface,
which is implemented by plugins providing access to various protocols
like HTTP, FTP, etc. The plugin providing HTTP will be loaded when
someone requests to open an http URL, and so on. Imagine now, that
the HTTP plugin uses libcurl to do its work, and libcurl is linked
with OpenSSL (this is the actual situation). Suppose further, that
the FTP plugin uses some GPL licensed library. Is it in violation of
the GPL to cause both of these plugins to be loaded at the same time?
Each of the plugins can be compiled and linked independently of
anything else, even the core program. The core program is also built
without any knowledge of which plugins are available.
Some argue that this is in violation of the GPL. I, however, fail to
see how any part involved, except the FTP plugin, can possibly be
construed a derivative of the GPL'd library.
>> We should certainly try to respect the wishes of the copyright holder,
>> wherever possible, but this is only an act of politeness, and not
>> necessarily something we are forced to do by law. The situation gets
>> still more complicated when non-FSF authors use the GPL for their
>> work. I find it somewhat difficult to believe that all the authors of
>> various little libraries would mind much if someone linked an
>> application with both their library and OpenSSL, for instance. I was
>> myself not aware of these issues when I first started writing
>> software, and released some things under the GPL. As soon as I
>> learned about the problems, I moved to other licenses.
>
> I'm not quite certain what you mean here, but in the copyright world
> the wishes of the copyright holder are the law.
Within certain limits. There are always things like fair use rights.
> If the copyright holder is only granting you the license under
> certain terms, than those terms are law and quite enforceable. If
> there is a "difference of opinion" between the licensor and the
> licensee as to what those terms are, well... that's when things get
> quite a bit more interesting :)
I am suggesting that the existence, and application of, boilerplate
licenses creates a situation where there exists code licensed under
terms the author may not be aware of the full consequences of, such as
obscure incompatibilities. The ability of a third party to change
these terms only makes matters worse.
--
Måns Rullgård
mru@inprovide.com
Reply to: