[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]

On Tue, May 18, 2004 at 07:02:08PM -0400, Glenn Maynard wrote:
> Watch out before trying to get rid of it, though.  The GPL has some parts
> that would fail the DFSG without using DFSG#10 as an escape.  For example,
> the "date changes" restriction (2a) and "output a GPL blurb" (2c) would
> probably both fail DFSG#3.

I have in the past provided at least compelling, if not conclusive,
arguments as to why these pass DFSG #3 while at the same time the GFDL
does not; this is a partial summary.

It's not particularly hard to do; DFSG #3 is very weakly phrased. The
correct interpretation as I see it is in fact the one frequently
proposed by people who are trying to excuse non-modification clauses -
that only those restrictions that actually pose a problem
matter. (Their argument fails because they proceed to ignore all the
reasons why their clause poses a problem, not because the principle is

Theoretically there could exist a work which could never be usefully
modified in any way, and it could still be DFSG-free; even if the
license explicitly prohibited modification, this prohibition wouldn't
be an issue because (a) it's just a restatement of a technical fact,
and (b) it doesn't *matter*. However, this is just a thought
experiment; I do not believe such a work can exist. (Everybody please
constrain your desire to debate this point to death).

GPL 2(a) is easy to satisfy (given the conventional interpretation
that published revision control logs are adequete, and do not have to
be included in the file itself) and does not prevent you from
modifying the work in any way you desire.

GPL 2(c) has two escape clauses; the first is that you only need
display an "appropriate" notice, which can mean almost anything but
should not require you to do anything which poses a significant
problem to you, and the second is that the clause doesn't apply if you
modify the program such that it does not "read commands interactively
when run".

I don't think anybody can come up with a convincing explanation of a
scenario where either of these clauses would pose a real problem. I
also think they're right up against the line of what is acceptable,
and that this is intentional.

It is very hard to write clauses like this which are not
problematic. Moglen seems to have pulled it off.

If they were even slightly more restrictive - if 2(a) required the
notices to be contained within the files, or if 2(c) specified the
text which you must display - then they would be non-free.

Here's a rule of thumb which is handy to keep focussed when thinking
about this sort of thing:

A clause which says you must credit the original author, is okay.

A clause which says you must credit the original author using the
following text, is not okay.

That one neatly and clearly classifies the vast majority of the
licenses we are confronted with (it's the counterpart to "say WHAT you
want, not HOW you want it" - licenses should be specifications, not

  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature

Reply to: