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 unsound). 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 solutions). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature