On Wed, Oct 01, 2003 at 08:12:25PM -0600, Barak Pearlmutter wrote:
> > The difference that I see boils down to this: while it might be
> > morally upstanding and forthright to investigate every file in every
> > package for the licensing terms and make sure that they are, in
> > fact, 100% Free Oats, this is a task of such size and scope as to be
> > impractical to accomplish in the short term.
>
> I think people are underestimating a couple things:
>
> - the lack of benefit of removing snippets (so far no convincing
> practical advantage of removing them has been forthcoming. The
> best argument made was "translations" but as others have pointed
> out that's a pretty weak argument.)
The benefit is not a question of practicality; it is one of abiding by our
promises, when we are aware of things that require fixing to keep those
promises.
> - the enormous number of snippets. I would be surprised if fewer
> than 10% of our source tarballs contain snippets. Maybe a lot more.
>
> - the difficulty of finding them. enormous task.
I'm not underestimating them at all, but then, I have context for grasping
tasks on the scale of what we're discussing - since I'm currently doing one
(NetBSD relicensing stuff).
This is larger, but both are so far beyond the ballpark of "normal
situation" that they are fairly similar in terms of the questions you bring
up.
If someone wants to embark on an audit, more power to them (and I suspect
it would take more than one person, just to keep up with new packages
coming in). If someone wants to audit some subset of packages ("all
packages beginning with 'ic'", "all of $Developers packages", "all packages
over size <X>", whatever) and report bugs found... just as much power to
them. Go for it; it's one way to improve the quality of our distribution.
> - the difficulty of removing them when found.
>
> + removing them in a patch file, or not putting them in the
> binary, is not enough! since they are not part of the software,
> whatever property they have that makes us unwilling to
> distribute them applies equally to distributing them inside
> source tarballs.
That it does. This is true of some number of our packages already, of
course; including X, which Mr. Robinson still coordinates. I doubt he would
underestimate the difficulty; I certainly don't (both as part of the XSF,
when I have time to keep up, and in my various NetBSD packages).
> Currently we to my knowledge have one (1) package containing
> "dingleberries", which I will define as materials that we feel
> must be removed for license reasons from the upstream tarball in
> order to make the debian .orig.tarball. This is the linux
> kernel, which contains binary firmware sans source which must be
> removed. As the kernel packagers will I'm sure confirm, that is
> a pain in the tush. Now imagine that 10% of debian source
> packages had dingleberries in their upstream tarballs. And not
> just one dingleberry, but often a couple. Changing with time.
>
> This would be a logistic nightmare.
It's significantly more than 1 package; I can state that from direct and
personal knowlege; see above.
> For one thing, our mechanisms are not set up to support
> dingleberry removal. So new mechanisms would be needed all over
> the place: .../debian/clip-from-upstream files listing them,
> probably the list would need to go into the .dsc files in order
> for cvs-upgrade to work properly, etc. All kinds of confusion
> would ensue, as people wonder why so many of our "pristine"
> source tarballs differ from the actual upstream source tarballs.
>
> We don't update the .orig.tar for a debian version rev, so
> fixing one of these bugs would require mechanism changes too, so
> the .orig.tar could be fixed (dingleberry removal) without
> reving the upstream version number. Or some other way of
> achieving the same ends. Any way you slice it, we're talking
> major disruption just in infrastructure and procedural changes.
Fixing .orig.tar.gz files is, in fact, how we do it today, as a rule. Yes,
to fix a specific bug, it may require some strange convolutions until the
next upstream release (if the package doesn't have frequent enough upstream
releases that one can simply wait, within reason, for the next one), to get
the orig.tar.gz updated.
No mechanism changes required, and we already ship a number of tarballs
that are not pristine upstream source (though we do, generally, try to
document that fact, and the reasons for it).
> + lots of bickering would start to happen, as people complain
> about missing snippets. upstream authors would get pissed off:
> "why did you take out the heartfelt email from my dead sister?
> i want it in to help inspire other to join me in this great
> endeavor to fight cancer!" Urkle. response: "well put it back
> with the stipulation that anyone can edit it a little to make
> their own heart-rending email. Then i will put it back and not
> change it but other people might." Yeah right. It's his dead
> sister dude!
You appear to be unclear on the protections that remain in place, even if
changes are made - they can no longer represent it as his writing, for
example. If they want to remove it entirely - well, that's what we're
talking about doing. Valid. If they want to change it by talking about
*their* sister, and put their name on it, well... it's impolite, sure,
and I wouldn't do it, but it's also impolite to do certain things to the
codebase itself, but the licenses are required to permit it. This ties,
once again, to the fundamental question of whether it is permissible to
have anything in a source tarball that is unmodifiable (frankly, I'd be
fine with it being unmodifiable *but removeable*, and distributing it thus,
since anyone who cares *can* remove it, still).
> + many patch files would be incompatible, and we'd have to deal
> with these manually all the time.
Er. That seems unlikely; if these are truly snippets that have nothing to
do with code or any core part of the package, then most patch files will
have no reason to ever touch them. If they do touch them, they clearly
intend to modify them - meaning it is in the interest of our users that
they be able to (prefferably) modify or (at least) remove them.
> - the problems with double standards
>
> + if we remove snippets (ie consider them dingleberries) whenever
> we find them, then some will be removed and others won't. This
> will engender a sense in people that we hold different upstream
> sources to different standards. Since this is proposed as an
> "anyone who notices" kind of thing, rather than a "maintainer's
> discretion" kind of thing, having politically astute maintainers
> with good upstream relations, who try not to subject their own
> packages to scrutiny beyond the level other packages enjoy,
> won't help.
Every one of which we know will be removed. Anyone having an issue
with a 'double standard' is welcomed to file bugs indicating where
license-problematic dingleberries may be found, and be assured that they
will be dealt with by the single standard we have established.
> + we allow political commentary and such as part of licenses, and
> in license-related files like letters from sleazy corporate
> lawyers grudgingly allowing use of their software patents.
> people will figure this out, and start bloating out their
> licenses with the materials they used to put in snippets. (Then
> they'll be unremovable, so they won't be snippets anymore.) So
> we'll be applying a double standard in which if someone is nice,
> and includes their dead-sister-cancer email in a removable REAME
> we go ahead and remove it, but if they bloat out their COPYING
> file with it (ugh!) we leave it in.
>
> how very clever of us, to sacrifice our current ability to
> remove the snippets when we don't like them, while leaving a
> mechanism by which they can be included without our ability to
> remove them. certainly that would be a major victory.
License texts are one of the few things we allow, for the simple reason
that we couldn't do anything at all, without them. If they start to be
abused in such a way, and it proves problematic, the DFSG ends in the
letter 'G' for a reason - we can decide that it fails our 'sense of
freeness' without violating a specific DFSG clause.
Certainly the argument 'it has excessive license text that has nothing to
do with licensing conditions or the purpose of the license' seems like a
cogent argument of non-DFSG-freeness to me.
> + license bloat & proliferation: due to the above double standard
> wrt political text in licenses, pretty soon we'll see all kinds
> of license bloat, and proliferation as people get into the
> habit of putting crap in their licenses. This is something we
> should strive to avoid, not encourage.
See above.
> + as a natural human tendency, when snippets are removed from a
> package the people who put them in will get *pissed* about it.
> One common way of responding to a perception of being a victim
> of a double standard (correct perception in this case) is to try
> to apply the standard to others in revenge, ie to level the
> field. Result: snippet-wars, with people looking for snippets
> in packages to complain about, as a matter of revenge/symmetry.
And this is why good maintainer relations with upstream are so important to
the project; if I went to one of my upstreams after finding a problem, and
talked to them about it reasonable and civilly, explaining *why* Debian had
issues with it, and offering various ways that it might be possible to work
around it while preserving the intent they had, I would expect that I would
at least be listened to, even if they disagreed and refused to change it -
and they would have been notified, privately, that it was going to happen,
and why, before it ever became a public issue.
This tends to go a good distance towards mollifying such problems. I'm
sure there will be unfortunate situations where this doesn't go so well -
and we've seen it happen, already, in regards to code (witness the recent
problems with a certain IRC client).
> Please please please, let's let sleeping dogs lie and not go on a
> snippet purge. And let's not overinterpret the debian-legal mandate
> into thinking we have the right to decide to embark on this
> potentially very disruptive course without full consultation with the
> body of debian.
Again. Neither Branden nor I (having now read Branden's followup)
are saying we should go on a 'snippet purge'. Only that we have a
responsibility to review things when people notice them, clarify the
license situation when possible, if it's unclear, and perform reasonable
due diligence in upholding the first point of the Social Contract.
Reviewing bugs about legal issues is, in fact, precisely the domain of
debian-legal. Note that we *don't* have any ability to force a maintainer
to remove text to resolve a bug; the primary excercise of that power lies
with ftpmaster (by not allowing new versions of the package which still
have the bug), should they decide debian-legal is right.
Filing bugs about legal issues is the domain of anyone with access to
the BTS who can, in fact, make useful and well-documented bug reports
about them. If the maintainer disagrees with the bug, it can be referred
to debian-legal, just like any other question of the sort. If he or she
disagrees with the debian-legal concensus, well, there are other avenues of
dealing with it.
Debian-legal does not have a mandate to tell people to go do this; we're
volunteers, and if someone finds it a worthwhile use of their time, that's
their choice. I'm busy enough that, apart from reviewing my own packages, I
probably won't have time to go over many others. If I come across one, I'll
report it, but I have no deep-seated need to hunt them down; if someone
does, however, that's their call.
If they're going to file LOTS of bugs, well, the procedures for doing that
properly are also well documented.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpkaLSc9wh36.pgp
Description: PGP signature