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

Re: Proposal: The DFSG do not require source code for data, including firmware

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

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

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

Reply to: