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

Re: O: gnu-standards -- GNU coding standards

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".


> 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

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 debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: