On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: > On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: > > > Point 3 then seems to go the other way around and say we don't need > > > sources for of few types of works. My main problem with this is that > > > still a little vague about which types of works don't require source. > > What problems do you consider this vagueness to cause? What changes would > > you suggest to make this less vague? > It lists "images, video, and fonts". And I'm assume it's going to cover > more than just that. I'm also not sure that this is something we want > for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? > For instance when they're raster images or fonts, I'd rather have the > source, if there ever was a vector based format of it. But I don't care > if there never was a vector based format, so nothing that would be a > more prefered way of changing it. "Rather have" != "Insist on for inclusion in main", though? > > Anyway, the answer I had in mind was a hex editor or a decompiler. If the > > firmware in question *is* code, and we know what the chip in question is > > that the code is running on, both options seem within the realm of > > plausibility to me. No, of course they're not the *ideal* means of editing > > such a work, but AFAIK most firmware is on the order of what programmers > > used to program directly in assembly, so it's also not totally *insane* to > > try to edit such a binary directly as it would be for most modern userspace > > apps, for instance.) > I don't see a hex editor useful for much, and a decompiler only slightly > better. If a decompiled version was useful to do derived work, it > would be the same as source, so not requiring source doesn't make sense > to me. > The difference with source is that you actually have names of functions > and variables, you have comments with it. Those things make it easy to > understand what it's trying to do. So it's easier to make changes too. OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? Yes, from there we get into discussions about defining "source" as "whatever form people prefer to work from" -- hmm, redefinition? -- and whether we can ship anything in main that we don't have a full toolchain for; but a) is that actually required by the DFSG, and b) is that the right standard to set, either today or in the future? > It would also be useful to have a list of firmwares we're currently are > talking about, and what license they have. Are there any that only fail > DFSG 2, or will this part of GR have no effect at all? Larry Doolittle has prepared a very helpful table at <http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html>. A number of these are marked as being under a "BSD-ish" license, which would qualify; a number of others are listed as GPL but sourceless, which nominally makes them non-distributable, but it seems unlikely that any copyright holders on these would refuse to relicense under more appropriate terms even if they weren't willing/able to release source. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature