On Tue, Aug 03, 2004 at 12:14:41AM -0500, Joe Wreschnig wrote: > > > > Read please, I said non-program files. > > What's a Postscript file, a literate program, or a TeX document that > does calculations?
Interpreted language files are source as well as program. You don't see
a difference in semantics between those and application/octet-stream?
> > The list of MIME types would correspond to actual media files which are
> > present in Debian packages. What would be the point of extending the
> > proposal to every MIME type in the world, besides to try to shoot it
> > down?
>
> Okay; how long do you think it will take to track down every MIME type
> in Debian?
As long as it takes people to file source-availability/validity bugs
against packages containing things that are contested. Same as the
non-free firmware.
> And then define source for them in terms of another MIME type
> (which may not be in Debian at all, or even have a reader in Debian)?
Having something free to interpret the source seems to be irrelevant.
See the non-free firmware discussion. I guess the (rather weak)
argument is that the availability of a source in some unknown language
will cause a toolchain to be developed for the architecture that the
source targets, of which details are naturally unavailable as well. My
question is how to get from point A to point C, but that's a moot
argument: nobody showed up with source for any of the firmware in
question, so we didn't have a chance to test this possibility before
shipping the lot off to non-free.
> There's still ambiguities that can arise. An acceptable "source" for a
> Vorbis file might be a wave, but if the song in question originally
> comes from Fruity Loops, we're not really that better off.
Either we define our own acceptable source forms, or we let upstream
define their source forms. Letting upstream do it doesn't seem to work,
because upstream simply doesn't care. Defining a blanket policy for all
of Debian doesn't work, for practicality reasons. ("Where do we store
uncompressed video?" "Hey, this source is only useful in .foo format,
but by policy it's provided in .bar. What gives?") Like I said, I
think the best approach is a hierarchical approach. We would have a
default Debian policy, based on the type of the media file, providing
several acceptable forms of source formats for packagers or upstream to
satisfy, based on case law from the lists as it is generated. The
packager can define his own policy on what is considered source for his
package, overriding the Debian-generated policy. In order for the
package policy decision to be made, he consults upstream as well as
common sense, and provides documentation of the effort and the
conclusion with his package.
> And then vote on them all? The last thing this project needs is more
> voting.
Hey, I *like* seeing things brought up for vote. Keeps radical changes
moving nice and slow, so we can have more time to think about whether
we're really fixing the right problem.
> > If upstream says he wrote it by hand, are you going to call him a liar?
>
> Sure. We've had upstreams lie about licensing (Transgaming), try and
> sneak Debian-specific trojans into their software (micq), create
> incompatible licenses by ignorance or laziness and not bother to fix
> them (Red Hat), or throw lawsuits all over the place (SCO). I don't
> think *most* upstreams will do these things; but I think it's a
> possibility.
I think if upstream is hostile towards Debian, this should not be
something which is to be included in the distribution. I'm sure that
at least one of his competitors is a bit nicer to developers.
> Where are these discussions? All I have is what I see on and other
> Debian lists, and from that I'm the only person to comment on your
> proposal so far;
I was referring to discussions over beer. You know, real human
interaction with other Debian+legal geeks :)
> I've never seen it proposed before either. I bet you'll
> get comments ranging from "no, we need uncompressed video"
Of course. There are always people unwilling to compromise on any
issue. The question is, is that to be adopted as the project's
position?
> to "the DFSG doesn't apply to non-programs so there's no point in
> discussing this" when this gets exposed to a bigger audience.
I already got my ass chewed numerous times on that one. That's where
the academic example from above originated. Granted, the originator is
no longer a Debian developer, but it was used repeatedly to sink my
arguments that the different uses of the words "software" and "program"
in the DFSG were intended to have different semantics.
FWIW, I believe the current wording of DFSG implies that #2 does not
apply to non-programs, and that "program" is a subset of "software".
And I have stated numerous times that it is unclear to me how the DFSG
could mean otherwise as currently worded, but apparently my brain have a
strict policy that causes me to parse two different words as different
tokens, while the real world has a greater tolerance for handwaving
ambiguous grammar.
> > Again, re-read what I said. The people whose machines, network
> > connections, and hard drive space are in jeopardy by hosting these
> > packages are going to have the final say in any decision of this sort.
>
> Your argument doesn't hold much water though, because mirror operators
> have little clue what comes to them over the pipe in the end. They trust
> the FTP masters, who trust... us. Especially if these things begin
> appearing in existing source, there's no manual FTP master filter and
> these hit the mirrors anyway.
>
> I'm not sure a package has ever been rejected because it was too large.
> I'm not sure I want that to happen, either.
It will happen if people start having DV files hosted using their
resources. There's no way it couldn't. The ftpmasters don't hold the
lock and key to the server rooms of the mirrors, the mirror operators'
bosses do. And when the mirrors start costing them a disproportionate
amount of money to maintain compared to the benefit they get from it,
they're going to want out. And to what benefit is it for a business to
have uncompressed multimedia files hosted for world+dog to wget -m?
> I've not seen much discussion of a definition for "source" (the most
> notable one being around the middle of the first GFDL debate, sometime
> back in early 2003, iirc). Lots of debate about "software", and
> "guidelines", and what the DFSG applies to, but not "source" itself.
The most recent discussion I can remember was regarding the timidity
patches (which was Cc: to the timidity mailing list, of which I happened
to be reading at the time). I think there is a piano sample set out
there which is multiple gigabytes in size, which was used to create a
.ogg composition of around 5 megs. Imagine the mirrors hosting that
"source".
> It's all a practicality thing at some level; a GPLd binary offers the
> same legal freedoms as GPLd source, just that one is infinitely more
> practical to work with. The question is where we can draw the line and
> say "this level of practical hindrance is non-free".
The problem is that we are then encouraging upstream to use shoddy
original representations of a work to create derived stuff from. "Oh,
well if I use this 8 gig sample set to create my music, it becomes
non-free, so I'll use this 32 meg soundfont instead, even though the
outcome is nowhere near as good, because Debian can distribute that
no problems".
I've never felt that GPL-like licensing mapped linearly into the space
of media. In fact, I have no problem at all with people allowing only
non-commercial distribution of their creative works (not in Debian of
course, speaking as a music fan and occasional artist myself). I'm not
sure why I'm okay with that while at the same time retching when faced
with using or maintaining proprietary software. It suggests to me that
there is something fundamentally different about the nature of these
categories of works, though that's just a gut feeling.
> I don't think voting is a reasonable way to decide that. I don't know
> much about video formats
There are container formats and there are stream formats. Containers
can contain other containers or streams. Raw digital or analog video is
simply crazy to consider. Even light lossy compressions like MJPEG are
borderline insanity. Video is simply not practical to transfer via a
network in uncompressed form.
> and there's no way every DD can know the breadth of domain-specific
> file formats.
He gets to make the call for his package. If he can't decide, or if
the user disagrees with his decision, he Cc:'s the bug to the list, and
the list either consults case law or holds a vote on the matter.
> The basic goal, that we need to figure out what "source" is, is a good
> idea. Voting on it, or trying to exhaustively generate lists of MIME
> types (or exhaustively generate lists of *anything* for that matter), is
> dumb.
The word 'exhaustive' never appeared in my original post. Perhaps
you're reading something into it that just isn't there. The non-free
firmware witch-hunt didn't sink Debian, and neither would this proposal,
especially if you consider it a passive approach; wait for the user who
wants a better 'source' for the binary blob to file a bug, and reach a
consensus on the problems as they arise to be used as future reference
material for that file type.
The passive approach only makes sense. These things are only non-free
if 1. they are "programs" (oh well, we'll pass that), and 2. they do not
include preferred form of source. Preferred form just depends on who is
using it in any case, so we need to wait for those people to show up and
tell us what form of source they prefer before we can take any actions
on it. Those actions can include badgering upstream or reaching a
consensus on the list, taking the case law I keep mentioning into
account, in order to speed up future decisions on similar materials.
Removing packages based on some random downstream person's feelings,
who has no idea how the material was generated in the first place, or by
some blanket policy requiring non-lossy source formats for every
lossily-compressed work is what would be rather dumb in my opinion.
It's a great sentiment, but it's never going to work. We can do better.
bye,
--
Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
