Re: The draft Position statement on the GFDL
> > I was looking for a "patches only" license, and my memory wasn't up to the
> > job.
On Thu, May 13, 2004 at 09:49:53AM -0600, Joe Moore wrote:
> Please pick one example and stick with it to the logical conclusion. This
> is your third (and fourth) hypothetical GCC combination.
I don't like to make mistakes and try to avoid them.
That said, there are several different sub threads running, because I
was originally discussing a number of different points. [And I've been
unclear in my examples in more than one thread -- which I apologize for --
but there does seem to be a need for more than one example.]
> Even the "patches only" license does not place restrictions on
> non-distributed materials. (Otherwise Debian users could not build QMail)
qmail is built under the principle that users are allowed to make copies
in the course of normal use. That's fine, but it's completely outside of
any DFSG discussion. [Or, at least: I was told that we do not consider
something free where the freedoms required by the DFSG are granted by
the law of the land rather than the license on the software.]
> Since you're not calling GPL+$must_rename "$must_rename", there's no problem
> meeting ${must_rename}'s terms.
There is, however, a problem meeting the GPL's terms. One of the GPL's
terms is that there be no restrictions beyond those imposed by the GPL.
> > Or just read the GPL and consider what happens in the case where a DFSG
> > license imposes some restriction not imposed by the GPL, and where someone
> > wants to combine software under the two licenses.
> If the combined work can not be distributed under the terms of the GPL (i.e.
> providing complete source code and the freedom to create derivative works),
> then the combined work can not be distributed at all.
Yes.
> (I'm pretty sure we both agree with that: GPL + GPL-incompatible =>
> non-distributable)
Yes.
> >> complete explanation of all copyright holders, nor a complete
> >> description of the licensing terms. If it did, the Linux kernel would be
> significantly bigger (something like over 10000 (C) notices).
> >
> > The problem comes when the licensing terms conflict.
>
> That problem only comes if you want to distribute.
No.
That problem comes up in any context where copyright law grants the
copyright owner exclusive rights.
> > That said, I don't have any reason to believe it's possible to have
> > licensing terms which aren't explicitly stated in the license on the
> > software. If I receive software with a license, I have no reason to act as
> > if there were some other licensing terms which I haven't been told about.
>
> There's a difference between the GPL-required "keep intact all the notices
> that refer to this License and to the absence of any warranty" (section 1)
> and what you're describing.
I would ask you what the difference is, but fortunately it looks like
you're willing to spell out your reasoning...
> I think you and I agree that the resulting work (GCC + Metafont, or GCC +
> QMail, or GCC + $paladium) can not be distributed under the terms of the
> GPL.
Yes. I also maintain that this unauthorized derived work cannot be copied
under the terms of the GPL. (If you read the actual GPL, rather than
the paraphrase you're providing below, you'll find this stated rather
clearly, in the first sentence of Section 2.)
> So, I will refer specifically to the requirements that the GPL places
> on other acts restricted by copyright:
>
> 1) Creating Derived works: You are given permission to create derived works
> by section 2, as long as you do all of the following:
> a) post conspicuous and appropriate copyright notices (Section 1) b)
> keep intact references to the GPL* and warranty disclaimers (Section 1) c)
> clearly mark modified files (section 2a)
> d) preserve interactive banner printing (section 2c)
>
> 2) Copying the work:
> Verbatim copies of the source code are allowed by section 1. Just put a
> post-it note on your PC that there's GNU/Inside(TM) if that's appropriate.
>
> Since you are given permission to create derived works, any copies
> produced in the normal process of creating derived works are allowed.
> (principle of estoppel. What good is the right to create derived works if
> it is legally impossible?)
The fundamental problem with the above is that the language isn't the
language of the GPL. It says something different.
That said, it is not legally impossible to create derived works. Instead,
you are obligated to make sure those derived works have appropriate
copyright notices, and it's only cases where you can't accomplish that
that the GPL does not grant permission to create derived works.
> * References to the GPL apply to the work if the reference is placed there
> by the copyright holder (section 0, first sentence). Since you are
> (presumably) not the copyright holder of
> {$paladium|QMail|MetaFont|$must_rename}, the copyright holder has not placed
> the GPL reference there, so the GPL notice does not meet the conditions of
> Section 0. (Hence the terms and conditions of the GPL do not apply)
This is false.
Section 0 says that if the work contains a notice that the terms of the
GPL apply. If there is some other reason for the terms of the GPL to
apply, the absence of a notice obviously doesn't change that.
That said: if the making of a derivative work would cause these conditions
to no longer be relevant it's likely that the person making the derivation
would be obligated (by Section 1) to place a GPL notice on the derived
work, but this is a very obscure hypothetical case and not only am
I uncertain about it, I can't come up with any reasonable example to
illustrate it.
Anyways, the reason I brought up GPL section 1 in the context of derived
works is that if you can't place an appropriate copyright notice on the
derived work (this happens when you incorporate incompatibly licensed
code) then you can't satisfy the terms of section 1, which means section 2
is not granting you the right to make that derived work. [The law of the
land might grant you this right, but that's outside the scope of the GPL.]
--
Raul
Reply to: