Re: snippets
On Wed, 01 Oct 2003 20:12:25 -0600, Barak Pearlmutter <barak@cs.may.ie> said:
>> 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.)
Are you sure you passed NM? The social contract is
unconvincing, or is it merely impractical?
> - the enormous number of snippets. I would be surprised if fewer
> than 10% of our source tarballs contain snippets. Maybe a lot
> more.
Hmm. I scanned my packages. No, 10% of my packages do not
contain snippets. 10% of my packages contain GFDL docs, but those are
not snippets.
> - the difficulty of finding them. enormous task.
Rubissh. Each develoepr has only a few packages to deal
with.
> - the difficulty of removing them when found.
What is so very difficult about removing sniuppets? Are you
_sure_ you went through NM?
> + 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.
Of course. You so modify the tarball. Can be scripted, really.
> This would be a logistic nightmare.
Heck no. Lots of packages already do it, silently, no moaning
and beating of breasts going on there.
> 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.
Hell no. You download upstream sources, you scrpt the removal
of the ``dingleberries'', you call cvs-upgrade on the new file, and
away you go.
> 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.
You just add, say, .0.0.0.0.1, to the upstream version. New
source file, new binaries, and seamlessly handle new upstream
versions.
These are trivial release engineering tasks.
> + lots of bickering would start to happen, as people complain about
> missing snippets. upstream authors would get pissed off: "why
So, they are non-free snippets, that we can't distribute under
the SC.
> did you take out the heartfelt email from my dead sister? i
Yes, I did. It does not belong in free software.
> 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.
We already massage patches.
You seem to think Debian developers are glorified packagers.
If so, you are doing the project a disservice, and our users as well.
> - the problems with double standards
Ah. Double standards. like following the social contract?
> + if we remove snippets (ie consider them dingleberries) whenever we
> find them, then some will be removed and others won't. This
Keeping them shall garner a RC bug.
> will engender a sense in people that we hold different
> upstream sources to different standards. Since this is
That is why we should not keep any.
> 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.
You mean people who try to weasel arounfd the social contract
to appease upstream would find it harder to do so?
> + we allow political commentary and such as part of licenses, and in
The license is required to use and distribute the work; and
thus we must needs preserve it to follow the law.
> license-related files like letters from sleazy corporate
> lawyers grudgingly allowing use of their software patents.
If it is not the license, and it is not freely modifiable, out
it should go.
> 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.
Right. Someone, somewhere, shall figure out a way to subvert
anything good we can do, so let us lie in sloth and apathy, for to do
otherwise leads to the evil of subversion.
> 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.
Ah yes. We should thus forget about the social contract, for
to follow it would make people do nasty things to subvert it, and
thus defeat the very purpose of the sc, so let us join to gether in
common cause never to undertake any noble endeavor, for surely it
shall be subverted.
> + 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.
Verily, let us decry anything that is good; for evil is
omnipresent, and shall surely rise to sully any thing good. Let us,
then, roll in the mud, if only a little, to escape the evil of
subverting someting pure.
Let us rise together, and destroy purity, for surely, purelty
invites the attention of evil
> + 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
The double standard of applying the dfsg to the work, but not
the permission to use the work? Aaiieee, truly, we are twisted.
> 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.
Heaven forbid that all our packges should ever be DFSG free.
> 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 am curious: who was your AM?
manoj
--
Pain is a thing of the mind. The mind can be controlled. Spock,
"Operation -- Annihilate!" stardate 3287.2
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: