Re: acceptable restrictions on modification (was: proposed licence change for moodle)
On Sun, 2003-01-26 at 19:56, Branden Robinson wrote:
> On Wed, Jan 22, 2003 at 02:12:49PM -0500, David Turner wrote:
> > Unfortunately, DFSG doesn't discuss what sorts of modifications can be
> > restricted.
>
> Implicitly, no sort of restriction on modification is permitted, except
> those already mandated by copyright law (removing someone's copyright
> notices can infringe their copyright, and usually does according to the
> terms of most copyright licenses).
All modifications are restricted by copyright law, except those which
constitute fair use or are otherwise excepted. Removing copyright
notices are in no way special, and in no Berne jurisdiction are
copyright notices required.
> Restrictions on modifications that already happen to exist in the
> licenses that the DFSG already explicitly identifies as satisfying
> meeting Debian's definition of "Free Software" also are implicitly
> regarded as acceptable.
This seems fundamentally arbitrary -- "we've screwed up before, so let's
keep screwing up". Of course, the reason for this is that rejecting
restrictions on modification requires rejecting nearly all software. In
my view, a compromise should be worked out based on ideology and
practicality, rather than tradition.
> > The Apache license restricts modifications that *don't* also modify
> > the name.
>
> Yes, and in my opinion this is a defect in the license.
I see it as a defect mainly because it's (a) potentially unweildy and
(b) incompatible the licenses of most other Free Software. But I can
see the reason for it, and indeed, have heard of people being bitten by
bug reports for modified versions of their software (which I think is
the main concern of the Apache people).
> > The GPL forbids removing code from interactive programs which displays
> > copyright notices.
>
> Yes, and in my opinion this is a defect in the license.
I disagree with this. Certainly, the presence of these strings has been
immeasurably helpful in finding other GPL violations (although a
determined violator would simply remove them, most violators are not
willful but ignorant). And many authors think that this does not go far
enough -- for instance, Zach Smith recently changed the license for
future versions of his Beest and UnRTF software because he didn't want
them renamed. I think Smith goes too far, but I do think that a little
credit is hardly out of line. I can't imagine a case where I might want
to remove these credits -- there's no embedded application that cares
about a few kbytes these days. So, I see it as an acceptable
restriction.
> > The AGPL forbids removing code which makes the source code available
> > to users of the software.
>
> Yes, and in my opinion this is a defect in the license.
Here, I again disagree -- and this is the key point, because the other
licenses you'll accept even though you feel they're defective, because
(1) Debian strongly requires the software or (2) you want to not change
past decisions. Neither of these seem to be very strong reasons.
> > The Microsoft Word EULA forbids all changes.
>
> Yes, and in my opinion this is a defect in the license.
Mine too.
> > Which of these are acceptable depends on where you want to draw the
> > line. I would argue that any restriction on modification must serve a
> > compelling Free Software interest unrelated to restrictions on
> > modification, and be the least restrictive means possible of
> > accomplishing its goal. I know that this is a rather American way of
> > putting it, but it's hard to overcome my upbringing.
>
> The judgement of what is and is not a "compelling Free software
> interest" is quite subjective and slippery. RMS apparently feels that
> the Invariant Sections mentioned in the GNU FDL serve a compelling Free
> Software interest.
RMS doesn't make decisions for Debian. You and I disagree, and have
reasoned arguments for it. For instance, a less restrictive means would
be to allow Invariant Sections to be removable.
A slippery standard is better than an arbitrary standard or no standard
at all. Debian will judge licenses on a case-by-case basis anyway, so
an arbitrary standard doesn't save any work. And this standard (well,
with s/Free Software/something else/) is used by another famous
organization to judge compliance with a much more important standard
than DFSG.
> As much feedback during the FSF's public comment
> period on GNU FDL 1.2 revealed, there are many people who disagree with
> his calculus.
Indeed, and nobody is suggesting that Richard's word be accepted as
gospel. I've written to the FSF's board about the FDL. Have you? On
the other hand, I notice that the FDL'd glibc-doc, at least, is still in
Debian main...
> > Letting users of software get at the source code (which is the aim of
> > the AGPL's (2)(d)) is certainly such a compelling interest.
>
> Certainly, but placing shackles on people's freedom to reuse the source
> code is perhaps not the best way to achieve such an end. The GNU GPL
> itself demonstrates other ways to serve this particular end, such that
> compelling every Free Software program to be a quine is demonstrably
> unnecessary.
The GPL is not perfect, and was written twelve years ago. The issue
with ASPs had not come up then. It's come up now, and many people are
allowing software to be used over a network, without allowing users to
get the source code. This is clearly a weakness in the current Free
Software development model. Must we allow it to continue, merely
because the AGPL wasn't around when DFSG was written? Or do you have a
less restrictive way than the AGPL's requirement to retain what amounts
to less text than most copyright notices. It looks to me like Affero's
code uses a simple link to an independently-maintained tarball, which is
not so onerous at all.
> > If Xpdf had enshrined its DRM code with licensing, due to its stated
> > goal of following the intent of the author (rather than the law or the
> > goals of the user), this would not be such a compelling interest.
>
> That's your personal judgement. That I happen to agree with this
> specific point doesn't establish much.
Debian must make a judgement about this in the same way it now must make
judgements about other aspects of the DFSG.
> > If the AGPL had forbidden modification completely to the subsection
> > which delivers the source code (rather than requiring the equivalent
> > functionality), this would have been a more restrictive means than
> > necessary.
>
> And what of people who feel that FSF itself publishes licenses that
> employ more restrictive means that necessary? Are they to be dismissed
> out of hand, or shall we attempt to understand what metrics are being
> used to evaluate the strength of a "compelling Free Software interest"
> vis-a-vis particular licensing contrivances intended to serve those
> interests?
We ought to understand them -- the FSF doesn't have a direct line to
God, any more than OSI or Debian-legal. But each organization must make
decisions based on its principles as best as it can. And sometimes,
everyone will get it wrong -- but that's no reason not to try,
> > Keep in mind, here, that I'm not speaking for the FSF, which doesn't
> > think about the DFSG at all.
>
> If it is a point of principle for the FSF to practice a sort of
> ideological isolationism[1], the FSF should not begrudge other
> organizations their own isolationism, and should not be surprised if the
> Debian Project in particular practices it.
>
> [1] note that I don't imply that this is necessarily a bad thing
I don't think it's a principle that codes worked out by other
organizations can't be used by the FSF, but I think those in charge of
these things (that is, not me), have reasons (which I don't know very
well) for not using the DFSG. One is that it focusses on what's
disallowed, rather than what's required.
I hope that the Debian will continue to judge licenses independently,
just as I expect the FSF to, even if I sometimes disagree with both [1].
I hope that the Debian will, however, consider my proposed standard for
judging DFSG 3 compliance, or at least some standard other than
tradition.
[1]: For instance, the gnuplot (no relation to GNU) license is
incompatible with itself, which bugs me but not, apparently, anyone
else. That is, two gnuplot-licensed programs can't be combined without
serious effort, because any patch against one includes a modified
version of the other.
... and if you think I'm speaking for the FSF iin a message where I
explicitly disagree with the FSF's decision on FDL, you're mad. ...
--
-Dave Turner Stalk Me: 617 441 0668
"On matters of style, swim with the current, on matters
of principle, stand like a rock." -Thomas Jefferson
Reply to: