On Mon, 2004-08-02 at 23:32, Ryan Underwood wrote: > On Mon, Aug 02, 2004 at 11:23:37PM -0500, Joe Wreschnig wrote: > > > opinions aren't going to work for policy. For non-program files such as > > > multimedia or publications, there should be a master list of MIME types > > > and a voted-on list of acceptable source code formats for each MIME > > > type, in the case that upstream does not certify that the file was > > > created as-is from scratch (example: capturing directly via hardware or > > > via a software filter to a MPEG-4 or Vorbis file). > > > > This is insane. Do you want to vote for every MIME type (I'm curious if > > you know how many there are)? What's the source for > > application/octet-stream? What if the original source is outright gone? > > Read please, I said non-program files. What's a Postscript file, a literate program, or a TeX document that does calculations? > 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? 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)? 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. And then vote on them all? The last thing this project needs is more voting. > > (Oh, and this 40MB application/postscript? Upstream wrote it by hand. > > Really. Just like this 4MB application/x-executable.) > > 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. > > Have you thought about your proposal at all? If you have, I'll be more > > scared than if you haven't. > > Oh, chill out. In fact, it's been the most reasonable conclusion of > various local heated discussions that manages to satisfy almost > everybody involved. Please be aware that there are other people with > brain cells besides those who participate on this list. 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've never seen it proposed before either. I bet you'll get comments ranging from "no, we need uncompressed video" 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. > > > It's a matter of practicality, and should be up to the package > > > maintainer, with policy such as described above to decide borderline cases. > > > If the package maintainer makes a bad/impractical decision regarding the source > > > format, nobody is going to host his package for download. So it ends up > > > being a Darwinian filter. > > > > If we go with a "if people download it, it's preferred" then we can > > include an awful lot of non-free software. > > 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. > > I agree a lot of it should fall to the package maintainer, but that's > > because she better understands upstream's work habits and preferences, > > and what kind of ways people might want to modify the software, than > > J. Random DD. > > Of course. And the package maintainer knows exactly how the file was > created, in the case the validity of the currently provided source is > ever called into question. > > > I think we're sane enough to work towards a definition of "source" that > > will do the right thing for all formats when interpreted by humans. > > Go ahead. I've seen a lot of people try and get shot down mercilessly. 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. > > I also think that the GPL's is a very good place to start, and I think > > most everyone agrees with me on this point. > > Compiling software can be thought of as a lossy conversion process. The > difference between this is that the compiled object code frequently ends > up being larger than the source code, if not the same size. This cannot > be said for lossy compression on media files, which typically shaves > orders of magnitude off the raw source. Again, it's a practicality > thing. 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". I don't think voting is a reasonable way to decide that. I don't know much about video formats, or literate programming, and can't really speak to what's preferred for those; no one on this list has stepped forward with information on what source for fonts might be; I suspect there's people who don't know that XCF/PSDs offer important features over PNG that artists might want. Ignorant popular opinion does us no good, and there's no way every DD can know the breadth of domain-specific file formats. 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. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part