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

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

*** 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: