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

Re: GPL compatibility of DFCL



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.

It's easy to confuse sublicensing with the fact that under the GPL there
is no sublicensing; under clause 6 all recipients automatically receive
an 'original' license from the original author.

An equivalent clause will almost certainly be necessary for us.


> > 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.  And a recipient can make 
> further changes, etc.  Soon it becomes impossible to know what changes are 
> GPL and what "original work" is MIT.  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?

You should use GPL I guess, as you are certainly allowed to (whichever source
it came from - although this will not bind someone else who *is* able to
identify the function in question as being MIT-licensed originally).
You may not necessarily be allowed to use the MIT license.

The point in this case is that where a work was originally licensed under
a more permissive license, it is not possible to take away their right
to anything that that license grants. However, in our case, we are trying
to achieve the reverse - using a less permissive license and only allowing
a particular relaxation *whilst* the work is part of a GPL-distributed
whole.

The GPL requires that copyright notices remain "appropriate". That means that
our copyright notices are required to remain appropriate (and any other
notices that refer to the GPL or the lack of any warranty are required to
remain *intact*). So if someone writes a doc and puts a DFCL copyright
notice and warranty disclaimer at the top, the GPL requires that it
remains whilst the work is part of the GPL'ed larger work. So long as we
make clear that the only appropriate copyright notice is one that refers
to the DFCL.

So, whether sitting in a tarball with a GPL'ed program is regarded as
"merely aggregated" or "combined into a derived work", our DFCL-licensed
stuff remains intact with its DFCL copyright notices. At a point where
it is actually merged into a GPL'ed source, it becomes GPL'ed. However
an appropriate copyright notice, as *required* by the GPL, would mention
the fact that that portion (if it is significant) was originally DFCL-
licensed, and will revert to being so if excerpted from the whole.

Which is nice.


So what the hell have we been arguing about?

1) The GPL requires that appropriate copyright notices remain. An
appropriate copyright notice for the DFCL'ed work refers to the DFCL.

2) The GPL requires that notices disclaiming warranty remain *intact*.
If our warranty disclaimer prominently mentions the fact that a modified
work is likely not to reflect the views of the original author, then
that is *required* to be carried through by the GPL.

Um, where's the problem?


> 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.

You can license it under the GPL, but if anyone successfully demonstrates
that it is all MIT-derived, there will be an interesting argument as to
whether or not your removal of chunks constitutes enough work to grant
you copyright (remember, performing "significant work" in compiling an
anthology gives you copyright on the anthology, but not on the individual
works contained therein) on the whole. And if so, whether they are using
your work or the original work... think rich lawyers.



Cheers,


Nick
-- 
Nick Phillips -- nwp@lemon-computing.com
Don't tell any big lies today.  Small ones can be just as effective.


-- 
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: