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
