Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote:
> 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?
I think we should require it. The DFSG says we need the source, and
I understand that as the best possible form for modification.
For instance, bison/yacc generates a C file. You could consider that
C file a source, but it's not. We want the original file that was used
to generate that C file. There might be several layers of tools that
are used to generate an object file from it's source, but it's the
source we want.
> > 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?
No, I would insist on having it.
> > > 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?
The DFSG doesn't say that the toolchain should be available for it to be
free, and it shouldn't. But I understand the SC as requiring it to be
included in main. It's also one of the reasons we have such a thing as
contrib.
There was a time when alot of java applications were in contrib because
there wasn't anything in main we could use them with. But those were
free software. You just needed non-free software for it to be useful.
And now most, if not all, have moved to main.
> > 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.
So, from that list:
* 46 source files that already use request_firmware() or
mod_firmware_load()
* 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz)
* 47 apparently nondistributable
* 12 apparently ok for non-free
* 14 free
So, we have a total of 137 drivers that require firmware. We have
14 that are free and can stay in main in any case.
I'm not sure about those 46 that already use request_firmware(), but we
seem to have atleast 12 (BSD-ish) that could go to non-free, but with
your proposol could stay in main.
It would be interestig to know if any of those other 46 are currently in
non-free, or what their license is.
Kurt
Reply to: