Re: Towards a new LPPL draft
On Tue, Jul 23, 2002 at 08:06:29AM -0600, Joe Moore wrote:
> What's wrong with the conditional statement (unproven assertion:)
> "The LPPL-1.3 is DFSG-free, but only when applied to software which makes
> the file-renaming requirement easy"
Well, one of the properties of free software is that you can change it :)
Consider a port of an LPPL'd program to a limited architecture, where
one of the space-optimizing changes has a side effect of making it much
harder to rename files. (For example, suppose the standard filenames are
tokenized in some way, and the encoding for nonstandard filenames is too
bulky to be useful.)
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.
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?
> 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).
--
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: