Re: snippets
> 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 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.
- 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.
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.
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.
+ 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!
+ many patch files would be incompatible, and we'd have to deal
with these manually all the time.
- 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.
+ 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 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.
+ 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.
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.
----------------------------------------------------------------
(I'm including this to try and keep the discussion on-topic, so fewer
people will go off on strange irrelevant rants about xroach and such.)
*** BY MY DEFINITION:
***
*** A "snippet" is a file in a source tarball which:
***
*** - MERELY ACCOMPANIES and is not an integral part of the source
*** - is REMOVABLE
*** - is NON-FUNCTIONAL (not code, not documentation, not needed for build)
*** - is NON-TECHNICAL in nature
*** - is usually of historic, humorous, or prurient interest
*** - is usually NOT itself MODIFIABLE, eg "may redistribute verbatim"
*** - is very SMALL compared to the technical material it accompanies
***
*** (examples of such snippets are historic or humorous emails and
*** usenet posts and the like.)
Reply to: