On Fri, Jun 14, 2002 at 09:00:31AM -0700, Mark Rafn wrote:
> Covered, but still unclear. I need to get my head around the difference
> between "aggregation" and "derivation", and the duties they imposes on a
> distributor to determine underlying license on any part he wants to
> release seperately. It seems hard to believe that if I recieve a package
> under the GPL, that I can't just treat the whole thing as GPL unless I
> choose to track down a different license on part of it.
You can, until and unless you surgically remove parts of the package
that weren't originally under the GNU GPL. They then revert to their
original licenses. Traditionally there hasn't been much of a practical
difference. I don't know that there has been a license before that
attempted to do what I am attempting to do with the DFCL and its
endorsements boilerplate.
> > No, you cannot take an MITed work and just slap the GPL on it. The MIT
> > license *is* compatible with the GPL, but that doesn't mean that
> > original author's copyright doesn't apply.
>
> But you CAN take an MITed work, make a (subjectively defined) nontrivial
> change, and release the result under the GPL.
Yes.
> And a recipient can make further changes, etc.
Yes.
> Soon it becomes impossible to know what changes are GPL and what
> "original work" is MIT.
Not necessarily; however I agree that it could be very, very difficult.
However, for my position to be affirmed, all we need is an example that
is very, very simple. Hence my Guitarmacs example elsewhere in this
discussion.
> Does this mean it's now undistributable, as I can't know whether I
> must use GPL or MIT for a random function I'd like to use elsewhwere?
No. You know it's distributable because, based on your good faith
knowledge that no one infringed a copyright by incorporating
GPL-incompatibly-licensed code into a GPL codebase, the work must be
distributable under the GPL.
The work might *also* be distributable under another license, but since
you *know* it's distributable under the GPL, you can redistribute it in
good faith until and unless someone comes along and points out that it's
really under a different license.
I admit, this could be a problem if someone carried my DFCL principle to
an absurd point. For example, imagine the Microsoft EULA, with a rider
tacked on to every single requirement; "this requirement is rendered
optional when the code is combined with a work licensed under the GNU
GPL as published by the Free Software Foundation".
You could then have the perverse result that, if you didn't pay
attention, you could extract enough code out of a GPLed work that it
would become proprietary ("reverting", as it were, to its original
license)!
You should note that this is probably one reason the FSF insists upon
clause 2a) of the GNU GPL:
You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
The likely foresaw the perverse possibilty I described above, and wanted
to make sure that no one could accidentally end up extracting a
proprietary piece of software from a GPLed combination.
However, it is not I who am creating the possibility of this situation.
It is a property of copyright law. The GNU GPL simply cannot
unilaterally impose changes in license terms on works copyrighted by
others. As far as I know, only a court of law or an act of Congress can
do such a thing. What the GNU GPL has done is built up a heck of a lot of
leverage, so that a lot of times people feel "compelled" to make their
license GPL-compatible, just so they can get along in the commons that
the GPL has created.
I personally have no problem with that. I've read the GNU GPL. I
believe I understand the rules of the game. I'm willing to play.
So, before you go carelessly yanking bits out of a GPLed work:
* Read the copyright statement on the file, especially if it's
*not* GPLed. (E.g., 3-clause BSD, MIT, LGPL, etc.)
* Read the prominent notices indicating the changes that have
been made to the file. You may need to preserve or remove
independently copyrightable changes that were made under the
GPL, depending on your aims.
(For instance, if you're a BSD hacker wanting to recover some
FSF-authored changes to a traditional BSD utility, and you find that the
FSF is distributing this utility with a bundle of others and licensing
the whole ball of wax under the GNU GPL, you'll probably want to be
extracting the original BSD-licensed stuff, and keep only the changes
that are clearly derivative only of the original code, and which would
not enjoy copyright protection in their own right. Yes, that
determination is incredibly subjective and you might want to have the
advice of an attorney. Nobody said intellectual property law was easy.)
> > Now you grab the source to GNUFree86 4.3. Under what terms are the
> > files licensed to you? The answer: the NVidia driver that the FSF wrote
> > is under the GNU GPL. The rest, even the FSF's changes to
> > xf86PciInfo.h, remain under the XFree86 license.
>
> Ok, now I make some modifications to generate GFree86-4.3-light, by
> deleting a bunch of stuff. Is it my duty to determine that I've removed
> "enough" of the FSF code that the package is no longer an aggregate of
> copyrightable FSF code and MIT? I'm certainly allowed to do so, but I
> didn't know it was required.
To be honest, I am not sure. If you *deliberately* misrepresent the
copyright license on a work, you are probably committing copyright
infringement. Will the author care? I don't know. Is this scenario
inherently more of a risk with the DFCL than it is with any other
license? No. Consider that there has already been considerable
cross-pollination between BSD or MITed codebases and GPLed code (though,
of course, mostly in one direction, but that's how the BSD and MIT
licenses want it -- "Take our code proprietary! Get rich off of it and
enslave the masses! We don't care!").
Is this scenario more likely in practice because if the DFCL really
takes off among non-programmer types, their unfamiliarity with the GNU
GPL and the concept of an intellectual property commons might drive them
to become license Nazis regarding the omission of a few sentences after
the copyright notice that make it clear that they don't necessarily
endorse the work?
I don't know. It's possible. It's a risk we should evaluate and
attempt to weigh against the benefits. My proposed endorsements clause
is there because authors seem to want it, and may not get on board if
it's not there. Is it worth trying to appeal to that group? I don't
know.
> > Here's a question for you. If I get my mitts on the source code to
> > Windows 2000, and change one line in a source file, can I then
> > distribute that source file under any license I want?
>
> What? Nobody claimed that any random license (or unlicensed code) can be
> converted to some other arbitrary license. The discussion is whether
> there can be a GPL-compatible license that cannot be converted into pure
> GPL.
You cannot "convert" one license into another unless (arguably) you hold
the copyright on the work and the former license has a mechanism within
it for being withdrawn.
You can distribute a MITed work under the terms of the MIT license.
You can distribute a GPLed work under the terms of the GPL license.
You can distribute a MITed work under the terms of the GPL license,
because the GPL does not violate any restrictions made by the MIT
license.
You can distribute a DFCLed work under the terms of the GPL license,
because the GPL does not violate any restrictions made by the DFCL
license.
Nobody's work or license gets "converted" to anything in an intellectual
property sense. ("Conversion" is actually a legal term for "theft";
interesting, eh?) A work is either distributed under the terms of a
license or it is not. A work may be distributed under multiple licenses
simultaneously. The word for this concept is "non-exclusivity", and all
Free licenses must possess this trait.
> If you got it under a GPL-compatible license, you can aggregate it with a
> GPL installer or make a GPLed modification to it and distribute THAT under
> the GPL.
That's correct.
> It's an open question (to me) whether a derivative of that aggregation
> automatically gets converted back to the original license.
It's not automatic as I understand it. You have to do a certain thing
for this happen. That certain thing is extracting the original work
from the GPLed composite.
> But this is exactly what you're saying, so I'll believe it. Thanks for
> the clarification.
I am trying to persuade you with reasoning, not force of personality.
--
G. Branden Robinson | A celibate clergy is an especially
Debian GNU/Linux | good idea, because it tends to
branden@debian.org | suppress any hereditary propensity
http://people.debian.org/~branden/ | toward fanaticism. -- Carl Sagan
Attachment:
pgpeKTy5WNXh5.pgp
Description: PGP signature