Re: Transitive closure of licenses
On Tue, Jul 23, 2002 at 03:58:55PM -0600, Joe Moore wrote:
> Richard Braakman wrote:
> > Well, one of the properties of free software is that you can change it
> > :)
>
> I thought the primary benefit was to have unending discussions about license
> issues... :)
That's another of the properties of free software :) Remember, I never
said "benefit"!
> > The resulting program would not be DFSG-free, even though the license
> > didn't change! This is independent of the license used for the
> > modifications themselves. I think this lack of "transitive closure" is
> > against the spirit of DFSG 3. It creates limits on what kinds of
> > derived works you can make without wandering into non-free space.
>
> Are all derived works from DFSG-free packages DFSG-free?
>
> No. The BSD network stack is DFSG-free. But Microsoft's implementation of
> it is not.
Yes, but that it due to Microsoft's choice. Someone else could make
an identical product that _is_ free. The license on the BSD network
stack does not prevent that. The ability to create a free derived work
that does a certain thing is what I care about. [I tried to find more
technical wording than "does a certain thing", but failed]
> > Hmm, I thought of a perhaps more practical example that also
> > illustrates my desire for transitive closure. What if you take a piece
> > of code from an LPPL'ed work and use it in another project? This other
> > project might lack any facility for remappping filenames. Should it be
> > required to add a remapping facility to a project that doesn't
> > otherwise need it, just to satisfy an allegedly free license?
>
> If the derived work is licensed under the LPPL, but does not provide an
> "easy" remapping facility, then the derived work is not DFSG-free.
Frank Mittelbach pointed out that the LPPL itself is not transitive,
so the "code from an LPPL'ed work" can be placed under a license that
says "do anything you want, but don't rename it back to Foo". I hadn't
thought of that, and I think it clears up this objection.
(I don't know if the current LPPL-1.3 draft works this way, but I
understood that it was the intent.)
> >> This is essentially what is said about the GFDL, "It's DFSG-free only
> >> if no options are used in the document"
> >
> > That's different: it's a condition on the license, not on what it
> > covers. A derived work can only become non-free if extra restrictions
> > are added (such as marking new text as an Invariant Section).
>
> I don't see the difference.
>
> ~/my_document.txt is licensed under GFDL, with no options. It is DFSG-free.
> ~/your_document.txt is a derived work, where you have taken my_document.txt
> and added an invariant section. your_document.txt is not DFSG-free.
>
> Note that the license on my_document.txt has not changed, and is identical
> to the license on your_document.txt. The difference is that
> your_document.txt has content that invokes non-free clauses of the GFDL.
I think there's a difference of terminology here. In my view, the
list of Invariant Sections is part of the license, because those sections
have to be listed explicitly in the "Permission is granted..." statement.
Adding an Invariant Section makes the license more restrictive.
This is similar to the ways the GPL can be applied. I would argue
that removing "or any later version" from the GPL blurb is a change
to the license, even though the license text it refers to is not changed.
--
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
(Anthony Towns about the Debian 3.0 release)
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: