Package: linux-2.6
Version: 2.6.26-1
Severity: serious

Hi,

drivers/media/dvb/frontends/tda10021.c (licensed under GPLv2+) contains a
small chunk of binary code:

static u8 tda10021_inittab[0x40]=
{
0x73, 0x6a, 0x23, 0x0a, 0x02, 0x37, 0x77, 0x1a,
0x37, 0x6a, 0x17, 0x8a, 0x1e, 0x86, 0x43, 0x40,
[...]

Since the licensing terms allow redistribution, shipping it is not illegal but
is a DFSG violation.

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Aug 07, Robert Millan <rmh@aybabtu.com> wrote:

> drivers/media/dvb/frontends/tda10021.c (licensed under GPLv2+) contains a
> small chunk of binary code:
What makes you believe this is code instead of data to be loaded in
the card registers?

--
ciao,
Marco

On Thu, Aug 07, 2008 at 09:34:31AM -0700, Steve Langasek wrote:
> > drivers/media/dvb/frontends/tda10021.c (licensed under GPLv2+) contains a
> > small chunk of binary code:
>
> > static u8 tda10021_inittab[0x40]=
> > {
> > 0x73, 0x6a, 0x23, 0x0a, 0x02, 0x37, 0x77, 0x1a,
> > 0x37, 0x6a, 0x17, 0x8a, 0x1e, 0x86, 0x43, 0x40,
> > [...]
>
> > Since the licensing terms allow redistribution, shipping it is not illegal but
> > is a DFSG violation.
>
> By "small chunk", you mean 64 bytes of data. That's not a program; that's
> almost certainly register initialization values, which are data, and there
> is no requirement in the DFSG that arbitrary bits of data (which are too
> short and lacking in originality to be covered by copyright anyway) be
> distributed in a textual source form.

Hi Steve

You might have a point here; the root of the problem seems to be the definition
of "source code", and the DFSG doesn't resolve this ambiguity. Some think
"source code" is the preferred form of modification for any form of data, some
think it only applies to certain types of data, etc. And then even "preferred"
doesn't mean the same to everyone!

But at least since 2004 we don't have to discuss what "software" is ;-)

Overall, it sounds like a gray area to me. Has this been discussed in -legal?

> You need to find yourself a more appropriate way to express your concerns
> about such files

Well, I usually express that I found a bug (or in some -rare!- cases, that I
mistakenly think I found one) by filing it to the BTS.

My concerns/opinions are not in this bug, but I sent them to -kernel; I think
it'd be good if you participate in the discussion in that thread:

http://lists.debian.org/debian-kernel/2008/08/msg00112.html

> than by unilaterally declaring them to be release-critical
> bugs.

As usual, my assesment of severities is "best-effort". If a severity is
wrong, we can surely discuss it!

Do you mind if I reopen with non-RC severity, untill my question above has
been clarified?

Thanks,

--
Robert Millan

The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Robert Millan wrote:

On Thu, Aug 07, 2008 at 09:34:31AM -0700, Steve Langasek wrote:

drivers/media/dvb/frontends/tda10021.c (licensed under GPLv2+) contains a
small chunk of binary code:
static u8 tda10021_inittab[0x40]=
{
0x73, 0x6a, 0x23, 0x0a, 0x02, 0x37, 0x77, 0x1a,
0x37, 0x6a, 0x17, 0x8a, 0x1e, 0x86, 0x43, 0x40,
[...]
Since the licensing terms allow redistribution, shipping it is not illegal but
is a DFSG violation.
By "small chunk", you mean 64 bytes of data. That's not a program; that's
almost certainly register initialization values, which are data, and there

is no requirement in the DFSG that arbitrary bits of data (which are too
short and lacking in originality to be covered by copyright anyway) be
distributed in a textual source form.


Hi Steve

You might have a point here; the root of the problem seems to be the definition
of "source code", and the DFSG doesn't resolve this ambiguity. Some think
"source code" is the preferred form of modification for any form of data, some
think it only applies to certain types of data, etc. And then even "preferred"
doesn't mean the same to everyone!



Overall, it sounds like a gray area to me. Has this been discussed in -legal?


It may be a gray area, but normally we expect people to make sane
judgements...


Feel free to discuss this in -legal, though that doesn't change the fact
that we currently don't expect textual source for arbitrary bits of data.



You need to find yourself a more appropriate way to express your concerns
about such files


Well, I usually express that I found a bug (or in some -rare!- cases, that I
mistakenly think I found one) by filing it to the BTS.


Ah I expect noone is perfect, but you're close to be an exception?


than by unilaterally declaring them to be release-critical
bugs.


As usual, my assesment of severities is "best-effort". If a severity is
wrong, we can surely discuss it!


It was not only about the severity, but also about it being a bug...


Do you mind if I reopen with non-RC severity, untill my question above has
been clarified?


No, we don't want to wait till you clarify your question...

Cheers

Luk



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 07, 2008 at 09:02:33PM +0200, Luk Claes wrote:
>
> Feel free to discuss this in -legal, though that doesn't change the fact
> that we currently don't expect textual source for arbitrary bits of data.

Okay, I will (eventually). I don't expect you consider this corner-case
release critical untill it's been properly discussed.

And I assume by your reply that this discussion hasn't happened yet, so as
far as I'm concerned there's no time to do that before Lenny. I _do_ think
it is necessary, though.

> > or in some -rare!- cases, that I mistakenly think I found one
>
> Ah I expect noone is perfect, but you're close to be an exception?

That was a joke of course! I mess things up about as much as anyone else,
perhaps even more :-)

> but also about it being a bug...

One could make the point that it is a wishlist bug... but we don't need to
spend time nitpicking about such things.

I'll proceed my inspection, and exclude problems that appear to fall in the
cathegory of "small chunk of non-code" from being filed as bugs.

Thanks,

--
Robert Millan

The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 07, 2008 at 07:52:36PM +0200, Robert Millan wrote:
> > By "small chunk", you mean 64 bytes of data. That's not a program; that's
> > almost certainly register initialization values, which are data, and there
> > is no requirement in the DFSG that arbitrary bits of data (which are too
> > short and lacking in originality to be covered by copyright anyway) be
> > distributed in a textual source form.

> You might have a point here; the root of the problem seems to be the
> definition of "source code", and the DFSG doesn't resolve this ambiguity.
> Some think "source code" is the preferred form of modification for any
> form of data, some think it only applies to certain types of data, etc.
> And then even "preferred" doesn't mean the same to everyone!

No, this entirely misses the point, which is that the DFSG does not require
source code for works which are not programs.

> Overall, it sounds like a gray area to me. Has this been discussed in
> -legal?

I don't remember, but it doesn't matter. -legal is an advisory body only.
It's been discussed on -legal, -kernel, and -release for sure.

> > You need to find yourself a more appropriate way to express your concerns
> > about such files

> Well, I usually express that I found a bug (or in some -rare!- cases, that
> I mistakenly think I found one) by filing it to the BTS.

For a matter such as this that you've acknowledged is a sensitive one, it
would be helpful if you would inform yourself of the currently applicable
guidelines before filing bug reports.

> > than by unilaterally declaring them to be release-critical
> > bugs.

> As usual, my assesment of severities is "best-effort". If a severity is
> wrong, we can surely discuss it!

> Do you mind if I reopen with non-RC severity, untill my question above has
> been clarified?

Yes, I mind. If there's not a DFSG violation here, then there is no bug
that the kernel team has any reason to fix. It is definitely not in our
interests to diverge from upstream over such an issue.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Steve,

I think we're wasting our time here; the bug is closed and I don't intend to
reopen it. However you said some inaccuracies that I feel need to be
corrected.

On Thu, Aug 07, 2008 at 11:07:31PM -0700, Steve Langasek wrote:
> > You might have a point here; the root of the problem seems to be the
> > definition of "source code", and the DFSG doesn't resolve this ambiguity.
> > Some think "source code" is the preferred form of modification for any
> > form of data, some think it only applies to certain types of data, etc.
> > And then even "preferred" doesn't mean the same to everyone!
>
> No, this entirely misses the point, which is that the DFSG does not require
> source code for works which are not programs.

Perhaps you're referring to DFSG #2 "The program must include source code".
In this context the "program" is Linux, the kernel. The only remaining
question is what is the "source code" of Linux, and I don't see that the
DFSG resolves that in one or the other way.

Or perhaps you're referring to SC #1. It used to be that it explicitly
required "software" to be free, and then we used to have a lot of fun
argueing about what "software" means. Fortunately, GR 2004/003 resolved
this by removing that word (btw I acknowledge your merit in being one of
the seconders of that GR). This is the reason we've been appliing DFSG to
all kind of works: firmware, documentation, artwork...

IMHO, the problem we have here is that we're so worried about the literal
interpretation of the foundation documents, that when we see an ambiguity
we fail to recognise it, and pretend it doesn't exist.

> > Overall, it sounds like a gray area to me. Has this been discussed in
> > -legal?
>
> I don't remember, but it doesn't matter. -legal is an advisory body only.
> It's been discussed on -legal, -kernel, and -release for sure.

Yes, -legal is an advisory body, that's why I suggest checking with -legal
when we want to obtain advice. Are you impliing that their opinion is not
relevant?

This links to what I said above about ambiguities; I believe the only way to
resolve them is through discussion and consensus. -legal is IMHO the right
place to discuss DFSG interpretation; -kernel sounds like the right place to
discuss a specific application of that interpretation, once a consensus is
built on it. -release does AFAICT have nothing to do with either of these
things.

--
Robert Millan

The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org