Questions on GPL application for embedded product

[Schmitz, Carsten]

Many thanks Harald (and again also to all the others who replied to
date).

I will post on their discussion board again one of the coming days (have
to make a new account since they seem to have "evicted" my previous one
;) and ask for them to provide tools/scripts/processes to flash the
image to the device. Won't mention anything about this conversation on
their boards for the moment.

I will let this list know when I get any replies.

Nice weekend to everyone.

Cheers,
Carsten



-----Original Message-----
From: Harald Welte [mailto:laforge at gnumonks.org] 
Sent: Donnerstag, 25. Mai 2006 12:59
To: Schmitz, Carsten
Cc: legal at lists.gpl-violations.org
Subject: Re: Questions on GPL application for embedded product

On Wed, Apr 12, 2006 at 03:37:28PM +0200, Schmitz, Carsten wrote:

> I have posted on their boards asking for GPL'ed sources in January, 
> and the reply I got was the same that other posters got - claiming 
> that the manufacturer has proprietary elements in the device which 
> need to be stripped before making any sources available.

That's not a valid reason for delaying source availability.  It has to
be available at the same time the object code is distributed.

> I was furthermore told that a CD with the source code could be 
> prepared specificially for me and shipped to me if I would be willing 
> to cover the costs. I know the GPL allows charging for media and 
> duplication costs, but not (as the undertone of these messages at 
> least sometimes indicated) for me covering the cost of manpower of the

> manufacturer to separate "their" code from the communities code.

You are right, they cannot charge you for their work to separate the
proprietary from the source bits

> The manufacturer finally released source code for the components under

> the GPL on his web site (afaik years after his products have hit the 
> market), which is a step in the right direction (certainly they should

> have made this available a lot earlier). I don't know though if these 
> sources are the one used in the latest release of the binaries.

they need to make available the corresponding source code for every
version of object code that was distributed.

> Now, the GPL 2 to my knowledge requires that beside the source code, 
> the entire build environment is made available. Which brings me to the

> first actual question to the list: Does this mean the manufacturer has

> to provide some way to actually transfer the software to the device?

the gpl states 'including scripts to control compilation and
installation of the executable'.  This does not say "build enviroment",
but specificall includes a "script" to install the executable. 

So yes, there needs to be a way to install the software on the device.

This is pretty clear in the GPL, so this is not really a question of
interpretation.  The only question is: What if that process is not
implemented as a script?   Then you would have to do a license
interpretation and deduce that the intent of the license is not to
specificall provide "scripts" but "whatever tools" to install the
executable.

> Going further, if this is correct under the GPL, hypothetically what 
> prevents a manufacturer from embedding in the device a closed-source 
> or "hard-wired" mechanism (say PKI) that allows only binary images 
> compiled by him and marked with a special tag to work, and just throws

> an innocent error message for anyone else who tries?

This is a question of interpretation.  My interpretation, which is
backed by the most prominent legal experts on the GPL in Germany, is
that this is not possible, because it prevents the purpose to enable the
user to run modified versions of the program.

> In summary, the first question is whether the manufacturer must 
> provide tools to actually "flash" the chip in the device with the 
> resulting binary?

according to the gpl-violations.org legal position: yes.

> Which brings me to the second question: Without saying that this is 
> actual fact, and just assuming that this password "randomization"
> mechanism IS part of what the manufacturer calls one of his 
> "proprietary modules", and just assuming that they outsourced this in 
> separate source files or (layman speaking) implemented it as a kernel 
> module or such, could they claim that they will not ship the sources 
> for this part because this is "proprietary"?

technical comment: password handling is definitely very unlikely to be
implemented in the kernel.  

whether or not a derivative work exists, depends on many factors and can
not be answered in a general way without looking at the specific case.

> In other words, can they cripple a binary resulting from GPL code by 
> limiting (root) access in the final product by some component they do 
> not release?

yes. It's free software. you can do anything to/with it, as long as you
follow the license.  since you're supposed to get the source code (plus
scripts), you're free to get rid of such annoyances, though.

-- 
- Harald Welte <laforge at gnumonks.org>
http://gnumonks.org/
========================================================================
====
We all know Linux is great...it does infinite loops in 5 seconds. --
Linus