On Tue, 2002-04-09 at 01:08, Anthony Towns wrote: > Replies to -legal if you must make them. This list is for development > issues, not boring license pedantry. > > On Tue, Apr 09, 2002 at 12:12:41AM -0500, Jeff Licquia wrote: > > On Mon, 2002-04-08 at 20:53, Branden Robinson wrote: > > > Why should the DFSG have to worry about such philosophical questions? > > > Why isn't it enough to worry about the license? > > Because software isn't documentation? > > Uh, you mean "documentation isn't software".
Yeah. > And I'm sorry, but that's > quite debatable. It's quite a valid interpretation of "software" to be the > "stuff" that's implied by all the one's and zero's in memory however those > one's and zero's might be represented, as opposed to "hardware" which > actually has a physical existance. In that case anything stored in a .deb > is software, compared to, say, a book, which is fairly primitive hardware. It's certainly debatable; the thread alone should be evidence enough of that. I don't find such arguments very interesting, though. It's certainly easy to "solve" a problem by shifting the definitions around, bending a few until they match. I could try to "unbend" them by asking what the practical difference there is between printed and electronic versions of books, but that's all dictionary work, and doesn't really convey anything useful. It's more useful, I think, to look at it this way: there is a sense that the freedom we insist upon for executable code may not necessarily be appropriate for other kinds of information that may be found in a Debian package. Indeed, we already recognize at least one such distinction: copyright notices and licenses, which are as "proprietary" as they come. Could there be more? There is evidence that at least a significant number of Debian people, not to mention a DFSG author and the head of the FSF, believe there are more distinctions to be made. > > Think of it this way: national security would be so much easier to > > maintain if we could just define cryptography as a weapon of war, > > equivalent to a nuclear device, "for the purposes of the import > > regulations". We all know how well that worked. > > Quite well, in that very little cryptography was exported from the United > States. It's unfortunate, in a sense, that unlike other tools of war, > cryptography is very easy to develop outside the US, so a block on > exports doesn't really do much good. Except that most of the crypto technology you used to find on Italian and Dutch FTP servers was either code from the USA or (rather poorly) algorithms from the USA. The really big example: PGP. I think ssh was probably the first really big non-US crypto app, and it postdated PGP by a few years as I recall. > Well, yes it does. It's even simple. "Any content you distribute in > the .deb must have a DFSG-free license", although you have to add the > careful proviso that the license itself shouldn't be considered "content" > or gets a special exemption, or something similar. Well, yes. But does that really reflect the values of the project? I think that's the question at hand. > A question you could reasonably ask is "is it useful to have all the same > freedoms for documentation that we expect for programs?" And really, it > _is_ useful. Being able to cut out all the irrelevant bits of a document > and distribute an abbreviated version you can store on your PDA, or being > able to translate it, or being able to change it to match the changes in > your program, or being able to correct it on factual errors, or being > able to rip out bits of opinion which aren't interesting or useful to > you or the people to whom you want to make copies are all reasonable > and productive things to do. These are all good arguments. If they hold, I would humbly suggest then that we rename the "Debian Free Software Guidelines" to the "Debian Free Content Guidelines". This, it would seem, would be more direct. I'm not sure that usefulness is a good criteria, however, for modeling what we believe. For example, it would have been exceedingly useful a few years ago to link GPLed KDE to non-free Qt, but we didn't do it then. Usefulness is a good thing if it doesn't contradict other, more important values. (Yes, I know that I'm not answering the question of what other values we hold that are more important.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]