On Tue, Jul 23, 2002 at 11:53:26PM +0200, Frank Mittelbach wrote:
> > Sure. Before getting to your hypotheticals, I'll try and give you a
> > direct, if generalized, answer.
> >
> > A license must be tested against DFSG 4 when either of the following are
> > true:
> >
> > A) the license places restrictions on the form in which modifications to
> > the Work are distributed;
> > B) the license places restrictions on the manner in which the Work is
> > named or versioned.
>
> okay. that is because DSFG 4 exists.
Not exactly; see below.
> > Without DFSG 4, *any* license term did either of the above would violate
> > violate DFSG 3.
>
> stepping more and more into that type of legal thinking ... (sorry if i'm a
> bore, but I really like to understand) ... I don't see that anything like the
> above follows from DSFG3.
>
> to my (proably simple) mind DSFG3 says absolutely nothing about "how" the
> licenses must allow modification other than it must allow them to be
> distributed under the "same terms" as the original software.
You're correct. DFSG 3 says absolutely nothing about how the licenses
must allow modification, aside from the transitivity of the license.
That means that all methods of modification must be allowed (as, I have
said elsewhere, with the exception of deletion of or semantic alteration
of applicable copyright notices and license terms).
*ANY* license with restriction or condition on modification that is not
expressly permitted by the DFSG renders that license incompatible with the
DFSG.
Consider that DFSG 4 does not say:
"The license may restrict source-code from being distributed in modified
form _only_ if permission to do is always granted upon payment of US$500
or more per modification to the copyright holder."
That this sentence is not in DFSG 4 means that the copyright holder
cannot restrict source-code from being distributed in modified form to
those who pay him or her *ANY* amount of money. It is not does
implicitly mean that a license can demand any amount of money, for
permission to distribute source-code in modified form.
You appear to be saying that it is DFSG-free for the LPPL to place
restrictions on modification -- namely a requirement to rename files --
because DFSG 4 doesn't say you cannot. But that is backwards. The only
DFSG-compatible restrictions on modification allowed by the DFSG are
those expressly stated in the DFSG (again, with the exception of
preservation of applicable copyright notices and license terms).
> Eg if the
> license puts restrictions on naming or versioning (the same restrictions on
> the original as well as the modifictions) then to my understanding the "same
> terms" is not violated at all.
The license may require derived works to carry a different name or
^^^^^
version number from the original software.
The copyright that exists in a work is a different thing from its name
or version number.
The copyright that exists in the film _Il Postino_ is the same whether
it is released in the United States with the title _The Postman_ or _Il
Postino_. More to the point, the copyright that exists in the film _The
Postman_ is the same regardless of whether the title is discernible when
the work is exhibited.
A filename is a technological device. The name of a copyrighted Work is
an identifier that is used for legal purposes. DFSG 4 does not
establish Debian as a filename registry.
> I can however understand that if a license make modification in principle
> possible but makes modification so difficult that in practise it *is*
> impossible or nearly impossible that this would violate DFSG3.
It doesn't matter whether the modification is easy or hard. I think the
assertions of the Free Software Foundation and some of my fellow
Debian developers are misguided in this respect. The DFSG says nothing
about how inconvenient the copyright holder is permitted to make the
acts of modification or redistribution.
I do not see any more evidence that DFSG 4 permits the imposition of the
renaming of modified files any more than it permits the requirement that
modifiers or distributors of copyrighted works pay a fee to the
copyright holder.
> I'm therefore happily tried (and i think succeded) in removing the cascading
> file renaming obstacle out of the way.
In my opinion, the only way to remove the file renaming obstacle in a
way that is DFSG-compliant is to remove the requirement to rename the
files altogether, or to provide a DFSG-free alternative to renaming
files.
> > You are correct. I do not think that DFSG 4 can plausibly be read to
> > permit the the restrictions you posit in your hypothetical.
>
> okay, thouhg I think one can make a case for arguing that there is nothing
> explicit that says you are not allowed to require the the binary has a
> different name.
Restrictions that are not permitted by the DFSG are forbidden...at least
if you want to be DFSG-compatible.
> I do however submit that the intention of clause for is to disallow it
> (but since we here are so often and quite rightly into exact wording
> (hallo Jeff:-) i think you might consider making this clear, but
> perhaps I miss something that follows from combining other points ...)
I am sorry, but I do not understand this sentence.
> okay. sounds good to me. As I said in my post I think stuff like latex macros
> really don't fit nicely into this scheme as bing both source and binary more
> or less.
There's nothing illegitmate about that. The same is true of Bourne
shell scripts, Perl scripts, and Python programs -- at least as they are
distributed by Debian.
> but i would liketo sumarize on what I understand (and don't) perhaps one or
> the other is joining in at this point
>
> a) My understanding is that the outlined LPPL rewrite behind Jeff's mail
> "Concluding the debate"
> would be DSFG free as the rights we offer through would be complient with
> DSFG #3 since
> - it allows modification (and there is no question that it allows it
> only theoretically but not in practice, ie with ease)
> - it allows derived works
> - it allows them to be distributed under the same terms as the license of
> the original work
>
> (it clearly doesn't state that it has to allow the distribution of the
> modifications in place of the original work disguising itself as the original
> work. This is in fact in my opinion further exemplied by explicitly giving
> sentence three in DFSG #4)
Sentence three of DFSG 4 actually has nothing to do with the first two
sentences. It is an orthogonal issue that is also related to "Integrity
of the Author'S Source Code".
DFSG 4 is poorly constructed, and would best be split up as follows.
* The license may restrict source-code from being distributed in
modified form _only_ if the license allows the distribution of "patch
files" with the source code for the purpose of modifying the program
at build time. The license must explicitly permit distribution of
software built from modified source code. (This is a compromise. The
Debian group encourages all authors not to restrict any files, source
or binary, from being modified.)
* The license may require derived works to carry a different name or
version number from the original software.
Were I in a mood to propose a General Resolution, I would propose that
DFSG 4 been stricken entirely, and the third sentence added to DFSG 3.
Ideally, I think we should get rid even of the third sentence of DFSG 4,
because it is my opinion that people need to register trademarks if they
want protection on names. Copyright law does not grant them this power
and it is illegitimate for a copyright license to claim it.
However, I am not certain that I could persuade a majority of my fellow
developers of that reasoning, and in any event I find the other three
sentences of DFSG 4 far more onerous.
> b) As far as DSFG 4 is concerned, I haven't so far seen an argument (sorry
> when I missed it) why it should forbid file renaming as a way to mark
> version or name change (it even talks about "file" in the parentheses)
Yes, but it's poorly worded.
(This is a compromise. The Debian group encourages all authors
not to restrict any files, source or binary, from being
modified.)
For one thing, this is statement of rationale, not a binding condition
in any way. The DFSG is written sloppily and consists primarily of
normative statements, a few sentences' worth of examples, a lone
parenthetical exhortation not to take advantage of a particular clause
of the DFSG, and a clause that has no binding force on anyone whatsoever
(DFSG 10). (Maybe Bruce Perens just wanted ten clauses because it's a
"round" number to our human, decimal minds.)
It is clearly the case that the DFSG does not in fact permit "authors"
to categorically restrict any file, source or binary, from being
modified. What this parenthetical appears to mean is:
(This is a compromise. Debian group encourages all authors not to
restrict any files, source or binary, from being distributed in modified
form.)
> - i've seen an accepted the argument that it might lead to violating
> first sentence of DSFG #3 if the modification gets too complicated
> but that particular thing we are confident to 100% prevent by something
> outside of the work being licensed (so that modification of the work
> wouldn't change that status!)
I, for one, have not accepted any such argument that arbitrary
restrictions on modification are "acceptable" as long as they're "easy
enough". This may be the reasoning of some, but it is not mine, and
furthermore there isn't a shred of evidence within the DFSG that DFSG 3
is meant to permit resitrictions on modification above and beyond that
explicitly authorized in DFSG 4 as long as the difficulty of complying
with the restriction is taken into account.
Maybe that's what some, or even most, people think the DFSG *should*
say, but that isn't what it *does* say.
> I'm certainly prepared to think further about the possibility to dual licenses
> (though that has its own difficulties as some of the sub-threads have shown)
>
> But I would be glad if you, on the other hand, also discuss a bit more the
> "Concluding debate proposal" by Jeff and come to a more firm conclusion.
This reply and the previous one are my means of doing so.
--
G. Branden Robinson | You don't just decide to break
Debian GNU/Linux | Kubrick's code of silence and then
branden@debian.org | get drawn away from it to a
http://people.debian.org/~branden/ | discussion about cough medicine.
Attachment:
pgpIij_SzpWLP.pgp
Description: PGP signature