[-policy and emacs maintainers not cc'ed]
On Sun, Dec 02, 2001 at 12:03:09AM -0500, Branden Robinson wrote:
> On Sun, Dec 02, 2001 at 02:14:51PM +1000, Anthony Towns wrote:
> > On Sat, Dec 01, 2001 at 05:51:29PM -0500, Branden Robinson wrote:
> > > [Debian Policy group: I am not sure if the Debian Policy Manual is an
> > > appropriate forum for any of the following material. I invite your
> > > opinions.]
> > -policy is traditionally for technical policy, which the DFSG isn't. A
> > -legal FAQ or HOWTO or similar isn't an unreasonable thing to start.
> Okay, consider me smacked down for daring to raise this on -policy.
Opinions are invited, as long as they aren't mine?
> I'll take it you don't welcome the parts of this proposal that advise
> people as to how to handle specific situations in the debian/copyright
> file, even though Policy 13.6 already addresses similar issues.
The -policy list is at its best when focussing on technical issues, not
legal ones. If you want to discuss legal issues, you won't get much useful
comment from the -policy list that you won't get from the -legal list. Geez.
> I'll respond here as well as -legal, but note Mail-Followup-To:.
(The response to Thomas Bushnell, had the original M-F-T, for reference)
> > > This guideline is proposed to legitimize the status quo within
> > > Debian.
> > The status-quo's already quite legitimite, rabble rousers on mailing
> > lists aside, [...]
> Whatever. If fiat is legitimate, that is. I'm not sure what your point
> is. A rose is a rose is a rose. DFSG 3 contains absolutely no
> implication of the existence of any exception to its terms.
The Debian Free Software *Guidelines* are just that; they get interpreted,
not plugged into a script and acted upon literally. The GPL, even with
its "changing [..] is not allowed" clause is perfectly legitimate in
DFSG free packages.
> > > 2) License text used as such (i.e., not as an example) [...] is permitted
> > > to be held non-modifiable.
> > > Only actual contractual license terms are protected under this
> > > interpretive clause. Material that is used to inform, persuade,
> > > exhort, or otherwise interact with the (putative) licensee but
> > > which is not legally binding is not covered by this clause.
> > This doesn't particularly match current practice.
> Do you mean particularly, or precisely?
The copyright and license text and authorship information and upstream
info and whatever else doesn't have to be freely modifiable, whether
its contractually obligating, or whatever.
Separating out contractual terms and optional terms doesn't match
current practice.
> > > 3) An amount of non-modifiable auxiliary material which is not legally
> > > binding upon a licensee is permitted to exist in conjunction with the
> > > license terms, and the packaging of the work so licensed should reflect
> > > this. Such material may not exceed 32 binary kilobytes (32,768 bytes)
> > That doesn't make any sense at all.
> Let me guess. You're one of the people who didn't read the thread
> before replying!
Yes, clearly that must be true. Any disagreements or misunderstandings are
always due to someone else not reading what you wrote.
It doesn't make sense because:
* It's unjustified. Why 32,768 bytes? Why not 32,000 bytes? What
if the author doesn't speak English, and wants to include some
text in Korean or Japanese that happens to not be encoded as
efficiently? If it's not about disk space, why not make it
32k characters? If it's about disk space, why not let people
put their text in an accompanying gzipped file and limit the
total length of that to 32k?
* It's awkward. The definition alone is awkward enough, but trying
to work out how many "non-obligating, squeezed-whitespace bytes"
are taken up isn't a reasonable thing to expect.
Now sometimes you certainly do have to set a particular, arbitrary, limit
on things and just live with problems: voting or drinking ages, and speed
limits come to mind. This doesn't seem like one of them though.
> Therefore, leaving terms like "fairly
> small" open to the interpretation of the developers presumes a common
> standard of reasonableness that may not exist, because some developers
> do not feel the existence of any non-modifiable text is justifiable.
And? If you can come to a consensus that the developer who thinks zero
bytes is wrong, why do you think you can't come to any consensus on
whether things are overly long, or aren't?
> Therefore, one logical way of resolving this difference of opinion is by
> specifying a numeric limit, rather than expecting them to be able to
> duplicate the judgement of some specific other developer who may elect
> to take them to task for not being "reasonable enough" in their
> interpretation of inherently approximate terms like "big" and "small".
> These are *guidelines*, remember.
Yes, they are, they're not laws that have to have every ambiguity nailed
down so that no one could possibly misinterpret them. Pretending that
they are (by nailing down some ambiguities) is just going to cause more
problems in future when people start imaginging that more clauses have
been nailed down and must be interpreted exactly as written. In any event,
people who can't tell the difference between a copyright file that says
something about petting your dog, and one that includes the full text
of every speech made to Congress in the 1990s simply have to be ignored.
On Sun, Dec 02, 2001 at 12:13:11AM -0500, Branden Robinson wrote:
> Maybe this is how you feel, but I so far haven't seen general agreement
> on anything. Especially now that Anthony Towns has spoken up and
> characterized the entire proposal as a waste of time.
Perhaps you should do some rereading yourself.
> In other words, if the total amount if Invariant text in a GNU
> FDL-licensed work totals 48k, I can't put 24k of that in one package and
> 24k of it in another, because the GNU FDL won't let me. All the
> invarient text has to go in both packages.
However, if you have to GNU manuals, licensed under the FDL, with 20kB
of invariant sections each, you can't combine them into a single package,
even if that might be more convenient for you and for your users.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
Attachment:
pgpiQvUuH_1Ws.pgp
Description: PGP signature