Qtopia-interest Archive, March 2007
Greenphone with a untainted kernel
Message 1 in thread
Hello,
I'm the lucky owner of a Greenphone and looked into the available
Linux kernel. It is a 2.4 kernel and contains 17 binary only modules.
I believe that 16 out of these 17 are derived work and needs to be
relicensed to a GPL compatible license. I think you (Trolltech)
should push your vendor to open them. Module 17 contains a patented
technology for wear leveling and bad block marking which can't be
considered derived work but is not interesting to us anyway.
My initial plan was to add the kernel to OpenEmbedded (http://
www.openembedded.org) but sadly I have 17 binary reasons against
doing so. So I had to alter the plan. The current idea is to go
straight for a Free untainted Linux2.6 kernel.
The current initial patchset can be found at http://page.mi.fu-
berlin.de/~freyther/greenphone/ and it should create a bootable
kernel with usb support. I have not yet tried to run this kernel and
you shouldn't do that as well.
Once this kernel boots I will work on the low hanging fruits like
MMC, getting the modem talk with me, bluetooth.
As I consider the 16 modules derived work, I will decompile them,
extract i2c addresses and commands, GPIO settings and timings and
will write proper 2.6 device drivers for them.
so who wants to join? Feel like helping with decompiling, finding the
JTAG port with me?
h.
--
[ signature omitted ]
Message 2 in thread
Holger Freyther wrote:
> The current initial patchset can be found at
> http://page.mi.fu-berlin.de/~freyther/greenphone/ and it should create
> a bootable kernel with usb support. I have not yet tried to run this
> kernel and you shouldn't do that as well.
Going to be hard to test if everyone follows your advice. :)
> As I consider the 16 modules derived work, I will decompile them,
> extract i2c addresses and commands, GPIO settings and timings and will
> write proper 2.6 device drivers for them.
On what evidence do you conclude that the 16 modules are derived works?
b.g.
--
[ signature omitted ]
Message 3 in thread
Am 02.03.2007 um 14:57 schrieb Bill Gatliff:
>
>> As I consider the 16 modules derived work, I will decompile them,
>> extract i2c addresses and commands, GPIO settings and timings and
>> will write proper 2.6 device drivers for them.
>
> On what evidence do you conclude that the 16 modules are derived
> works?
>
Hi Bill,
I have consulted the magic eight ball. These 16 modules have been
specially written for this linux kernel and the device.
kind regards
h.
--
[ signature omitted ]
Message 4 in thread
Holger Freyther wrote:
>
> I have consulted the magic eight ball. These 16 modules have been
> specially written for this linux kernel and the device.
Ok. But have you seen this?
http://www.linuxjournal.com/article/6366
In particular, Rosen's opinion:
"3) Derivative works are not going to encompass plugins and device
drivers that are designed to be linked from off-the-shelf, unmodified,
programs. If a GPL-covered program is designed to accept separately
designed plugin programs, you don't create a derivative work by merely
running such a plugin under it, even if you have to look at the source
code to learn how."
So in the opinion of at least one noteworthy lawyer, the observation
that the modules were written specifically for a Linux kernel does not
make them de-facto derived works. A point on which Linus appears to agree:
http://lkml.org/lkml/2006/12/14/218
"And no, including one header file in order to compile against something
does not automatically make something a 'derived work'. It may, or it
may not. It really isn't up to you to decide whether it does (and notice
how I'm not saying that it's up to _me_ either!)."
Note the date, and read that whole thread for the context. My point?
Your comment:
"As I consider the 16 modules derived work, I will decompile them,
extract i2c addresses and commands, GPIO settings and timings and will
write proper 2.6 device drivers for them. "
Don't do it because they appear to you to be derived works (they
probably aren't, according to Rosen and Torvalds). Instead, just do it
because you want to, because it's something you enjoy, because you have
a problem to solve, etc. Do it even if they aren't derived works. Do
it "Because You Can".
Save the "let's stick it to The Man"-talk for times when serious
Man-sticking is in order. :)
Trolltech has done a lot of good for the Free Software community, I
don't think they're The Man here. I don't know their reasons for using
binary-only modules, but it doesn't look to me like there's anything
nefarious to it. Claims that their Greenphone uses derived works of
GPL-licensed code, without evidence to support them, suggests
otherwise. I don't think that's what you meant to do.
And for the record, I'm just a wee bit jealous. I wish I had the time
(and the hardware) to help!
b.g.
--
[ signature omitted ]
Message 5 in thread
Am 02.03.2007 um 15:47 schrieb Bill Gatliff:
>
> Save the "let's stick it to The Man"-talk for times when serious
> Man-sticking is in order. :)
>
> Trolltech has done a lot of good for the Free Software community, I
> don't think they're The Man here. I don't know their reasons for
> using binary-only modules, but it doesn't look to me like there's
> anything nefarious to it. Claims that their Greenphone uses
> derived works of GPL-licensed code, without evidence to support
> them, suggests otherwise. I don't think that's what you meant to do.
Hey Bill,
a lot of stuff, and I know the heated debat of this topic but I feel
the need to clarify one thing. I don't blame it on Trolltech, they
should try to get their vendor to open up.
On the derived work topic. I'm 100% sure that no kernel developer
will consider these 16 modules as legal instances of binary modules.
And I think I use this http://linuxmafia.com/faq/Kernel/proprietary-
kernel-modules.html as my background.
"That doesn't mean that I would accept just any kind of binary-only
module: there are cases where something would be so obviously Linux-
specific that it simply wouldn't make sense without the Linux kernel.
In those cases, it would also obviously be a derived work, and as
such the above excuses don't really apply any more, and it falls
under the GPL license."
I think that something that ties into the mmc subsystem (using the
hooks provided) that enables power for the MMC card is specially
written for the Linux kernel. And clearly is not a preexisting driver
that is ported to Linux.
And yes it is for the fun of it, and I think I'm morally allowed to
do it. E.g. I won't decompile the wear leveling stuff as their is a
datasheet for the g3 flash chip freely available.
>
> And for the record, I'm just a wee bit jealous. I wish I had the
> time (and the hardware) to help!
hehe, get one :)
--
[ signature omitted ]
Message 6 in thread
Holger Freyther wrote:
> On the derived work topic. I'm 100% sure that no kernel developer will
> consider these 16 modules as legal instances of binary modules.
... which is why I asked for your evidence. Even Linus himself has
said, as recently as Dec06, that being a kernel module alone is not
enough to make it a derived work. You must know something you haven't
mentioned yet.
> I think that something that ties into the mmc subsystem (using the
> hooks provided) that enables power for the MMC card is specially
> written for the Linux kernel. And clearly is not a preexisting driver
> that is ported to Linux.
The former is directly addressed by Rosen's opinion, which is probably
legally sound. The latter is irrelevant.
Regarding the posts you cite, they're dated 1995. When compared with
the 2006 posts I mentioned, it's clear that Linus' position has evolved
somewhat since then. It's also clear, especially considering Rosen,
that his example of a driver that "had a life of its own regardless of
any Linux development" is technically flawed.
> And yes it is for the fun of it, and I think I'm morally allowed to do it.
If your "moral allowance" is based exclusively on the modules being
derivative works, then you're on shaky ground.
But honestly, you're "morally allowed" to do so whether they're
derivative works or not. The Greenphone is a tangible thing, and you
apparently own one. Unless it's on loan from Trolltech.
>>
>> And for the record, I'm just a wee bit jealous. I wish I had the
>> time (and the hardware) to help!
>
> hehe, get one :)
The hardware can be bought, the time to hack it can't. A typical
night's sleep for me is only four hours already!
So I'll wait for your patches, THEN dive in. And complain when it
doesn't all work out-of-the-box.
And you'll jump right on fixing that, I'm sure. 'Cause I convinced you
to do it "for love". :)
Go forth and conquer, nothing more to see here.
b.g.
--
[ signature omitted ]
Message 7 in thread
Am 02.03.2007 um 17:11 schrieb Bill Gatliff:
> Holger Freyther wrote:
Hey Bill,
this makes fun as well
>> I think that something that ties into the mmc subsystem (using the
>> hooks provided) that enables power for the MMC card is specially
>> written for the Linux kernel. And clearly is not a preexisting
>> driver that is ported to Linux.
>
> The former is directly addressed by Rosen's opinion, which is
> probably legally sound. The latter is irrelevant.
>
> Regarding the posts you cite, they're dated 1995. When compared
> with the 2006 posts I mentioned, it's clear that Linus' position
> has evolved somewhat since then. It's also clear, especially
> considering Rosen, that his example of a driver that "had a life of
> its own regardless of any Linux development" is technically flawed.
The point is I would not call the modules drivers in the first place.
Either the function is carried out in hardware (like the PXA MCI or
PXA FB), or the Linux Framework is used to carry out the work. So the
modules (the ones I had a quick look into) mostly sets a register in
the PMU or toggle a GPIO to power up a certain piece of the hardware.
>
>> And yes it is for the fun of it, and I think I'm morally allowed
>> to do it.
>
> If your "moral allowance" is based exclusively on the modules being
> derivative works, then you're on shaky ground.
hehe, well I think an Open Platform should have a free and complete
Linux kernel. And the device has spoken to me and asked for liberation.
kind regards
h.
PS: And I know you will order one ;)
--
[ signature omitted ]
