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

Re: snippets

On Thu, Oct 02, 2003 at 08:49:43AM -0600, Barak Pearlmutter wrote:
> Joel Baker <fenton@debian.org> wrote:
> > > > (frankly, I'd be fine with it being unmodifiable *but removeable*, and
> > > > distributing it thus, since anyone who cares *can* remove it, still).
> > 
> > > Um, isn't that precisely what we're talking about?
> >
> > After all, to tie threads... all Invariant Sections in a GDFL work
> > are secondary, by definition (and, frankly, usually by practice) -
> > if the FSF doesn't want to allow their removal, much less
> > modification, why should we assume that Joe Random Author who
> > explicitly puts a protective license on it is actually fine with it
> > being removed, but not modified?
> I don't think there is any debate about whether non-removable material
> of any sort is okay: it is not.  We give it a pass when it is
> license-related, like patent-grant letters containing anti-GPL flames,
> but at some point I imagine we'd draw the line even there.  Also
> unmodifiable software including interfaces or documentation: not okay,
> obviously.
> The whole idea of "snippets" was that by definition they are
> removable.  Basically, I was trying to express a bit formally the
> kinds of material which we've never worried about or had problems with
> in the past.  The kinds of materials which I *think* you meant when
> you wrote "I'd be fine with ..."?

Just because I'd be fine with it (until convinced otherwise by cogent
arguments as removability being an imperfect but acceptable solution,
much like, oh, the clause under which TeX slips through) doesn't mean
that the majority opinion of d-l is; and if I'm in a significant
minority, there comes a time to, as they say, "shut up and deal with

Now, if we want to have a debate on the fundamental question of whether
something which is severable/removeable, but not allowed to be modified
*and distributed*, is OK... that's a question meriting serious discussion
divorced from any emotionally-attached examples (TeX, Emacs, etc). Things
which attempt to prevent modification at all, even without distribution,
strike me as almost certainly non-free, by attempting to control the
private use of the item (I firmly believe in the general point of 'Freedom
Five' in Branden's post last summer).

Come to think of it, the above may shed some light on why the conversation
so far seems to have been... muddy. The only exception we've ever
explicitly recognized as acceptable (as a workaround) allows for things
which cannot be *distributed* as modified source, but which actively
encourage the concurrent distribution of modifications (patches), and their
application in a local context, with a pristine source - and which allow
for us to distribute a binary based on the post-modification source.

Note the delineation between TeX (in main) and qmail (in non-free); or,
rather, qmail-src (in non-free); this would lead to an obvious (but
possibly wrong) acid test, of the form "Can the .deb contain a modified
form of the file in question?" - even if the source tarball must be
pristine, our *package* must be allowed to reflect arbitrary modifications
(assuming that, for example, we put this important documentation into
/usr/share/doc, and the maintainer has a patch that adds "For a good time,
call the USNO Atomic Clock line" with a suitable layout to keep people from
mistaking it for the upstream author's text, to the end of it).

Not that I suggest that we *should* do such a thing; it would be in
poor taste (even if atomic clocks are cool). Merely that we must have
the *right* to do it. After all, I have the right to stand on a public
streetcorner and should vitriolic insults about Emacs and all users thereof
(at least, until the Department of Homeland Security IT division comes
calling), but I don't (though it would probably make more sense than some
of the folks on the 16th Street Mal here in Denver do).

As noted, the test might be a poor test, and/or I may be missing some point
about the licenses involved; factual corrections, or arguments about the
specifics of the test, are welcomed. Perhaps call it the "Street Preacher"
test, whatever.
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU NetBSD/i386 porter                                        : :' :
                                                                     `. `'

Attachment: pgpKBEpd31KZb.pgp
Description: PGP signature

Reply to: