GPL violation? - Page 8

HarryT · 03-09-2008, 05:04 AM

Quote:

Originally Posted by JSWolf

So does Bookeen HAVE to give the Mobipocket code out along with the OS code under the terms of GPL? Can anyone give a definitive answer?

I'm sure that MobiPocket's lawyers would have something to say about that! There's no such thing as a "definitive answer" when it comes to legal stuff, is there?

JSWolf · 03-09-2008, 05:14 AM

Quote:

Originally Posted by HarryT

I'm sure that MobiPocket's lawyers would have something to say about that! There's no such thing as a "definitive answer" when it comes to legal stuff, is there?

Can they only distribute pieces of the code? Could they get away with only giving out the bits that link to the GPL libraries?

igorsk · 03-09-2008, 08:49 AM

Here's a nice article
http://www.groklaw.net/article.php?s...31214210634851
One of the commenters makes a good summary:

Quote:

Originally Posted by Weeble

If you misappropriate GPL code into a proprietary product and get caught, you
have several choices, among which include;

1) release the product under the GPL. It's an option, but as the article
states, it's not a requirement--you just have to choose another valid option if
you don't.

2) remove the GPL'ed code and do either 3) or 4).

3) replace the code with code that is in the public domain or released under a
less restrictive license (such as a BSD license).

4) WRITE YOUR *OWN* DANG CODE!

HarryT · 03-09-2008, 08:56 AM

I'm curious as to what the practical difference is between statically and dynamically linking to a library in an embedded system such as the Gen3. Suppose you were to find a bug in the C runtime library - you couldn't do anything about it. Why does it therefore matter, from purely practical considerations, if you statically link the library?

I fully accept, by the way, that the LGPL says that you shouldn't. I'm asking here about the practical rather than the "legal" implications of doing so.

igorsk · 03-09-2008, 09:15 AM

Dynamic linking to a library allows you to:
1) replace the library without relinking the complete application (e.g. to fix the bug you mention)
2) (on some systems) share the library's code between several processes instead of having a complete copy in each process's memory space.
If you're more familiar with Windows programming, calling a DLL is an example of dynamic linking.

I've read somewhere a comparison involving books: dynamic linking would be something akin to a reference to another book in a footnote while static linking is like including the complete text in its entirety.

HarryT · 03-09-2008, 09:18 AM

Hi igorsk,

Yes, I completely understand what dynamic linking is, and that it both allows you to easily fix a bug in an RTL, and potentially reduce memory needs too. All I was wondering though is, from a practical perspective, as users o the CyBook, why does it matter, given that we have to reply on Bookeen to replace libraries, etc; we can't do so ourselves.

tompe · 03-09-2008, 09:22 AM

Quote:

Originally Posted by HarryT

I'm curious as to what the practical difference is between statically and dynamically linking to a library in an embedded system such as the Gen3. Suppose you were to find a bug in the C runtime library - you couldn't do anything about it. Why does it therefore matter, from purely practical considerations, if you statically link the library?

The goal of the LGPL is that you should be able to do something about it so if you cannot then the license is not complied with. The same thing with the GPL:ed kernel. You should be able to rebuild it.

HarryT · 03-09-2008, 09:31 AM

Quote:

Originally Posted by tompe

The goal of the LGPL is that you should be able to do something about it so if you cannot then the license is not complied with. The same thing with the GPL:ed kernel. You should be able to rebuild it.

But that's generally not the case true, in a practical sense, with embedded systems, is it? Suppose you find a bug in the Linux kernel in, say, the Sony Reader (which does fully comply with the GPL). Can you re-flash the ROM even if you do fix the bug? Imagine the support nightmare that would result if everyone had their own "customised" version of the firmware!

That's why I'm asking if this has any practical implication rather than legal ones?

tompe · 03-10-2008, 07:47 AM

This might be a case were version 3 of the LGPL is much clearer. Version 3 says explicitly that you have to provide installation instructions. Version 2 does not say that explicitly which probably was a motivation to do a version 3. But I have not followed that debate so I am guessing.

Snuffi · 03-10-2008, 08:44 AM

I am not a programmer but in theory it would be well possible to exchange a library in a firmware. I can give you a specific example:
A hardware mediaplayer (sold amongst others by Freecom) had/has a firmware which consist of open source libraries, hardware drivers (not sure whether they were open or closed source, nobody messed around with them), a single piece of closed source software (the player) plus quite a few scripts, graphics files and some such.
After experimenting around people managed to take apart the firmware into the above mentioned parts (as already stated, I'm not a programmer, but from following that thread for over a year I assume that there are only so many ways to pack stuff into a firmware file and people who work in that field are certain to get to the point sooner or later where they can take it apart).
Once the files were available there was a number of uses which the various people found:
1) one of the simplest was to change the graphics (to something prettier, or in another language -> as the buttons were all just graphics)
2) change the scripts to modify the behaviour of the system
3) include additional libraries called from modifies parts of the script (they managed to include an ftp and telnet server that way so you could remote control the system via telnet)
4) exchange libraries for less buggy ones or maybe just smaller ones to speed things up or make room for other stuff

So, basically, there IS practical use for dynamically linked libraries, at least in theory, because you never know when it will be possible to change stuff.

A customer service nightmare would be out of the question as usually every vendor clearly states somewhere in all that legalese that if you tamper with the device (both hardware and software) the warranty is null and void and no court on earth would rule that the manufacturer could be held responsible if some idiot bricked their device by re-flashing or suffered some other mis-behaviour from some altered firmware.

Of course, one shouldn't be so naive as to assume that there aren't those who brick their device and still try to get the manufacturer to do something about it. Whether the company will be very strict or not will probably also depend on their sales: If a device sells extremely well because people know that you can customize your firmware, exchange graphics and such, the company could possibly be rather lenient because they also benefit from their customers work through increased sales...

drwowe · 04-20-2008, 11:42 PM

Quote:

Originally Posted by HarryT

But that's generally not the case true, in a practical sense, with embedded systems, is it? Suppose you find a bug in the Linux kernel in, say, the Sony Reader (which does fully comply with the GPL). Can you re-flash the ROM even if you do fix the bug? Imagine the support nightmare that would result if everyone had their own "customised" version of the firmware!

That's why I'm asking if this has any practical implication rather than legal ones?

There's plenty of precedent for devices based on Linux and other GPL code where users DO create their own firmware. It is NOT a support nightmare. Lookup the WRT54G for a prominent example. Basically, companies have no requirement to "support" devices in unauthorized configurations, and users make modifications at their own risk. Yet, many thousands of users find the risk worth it.

I have been considering buying this device, I like the design and features, but I'm glad I found this thread. Now I will not even consider it until the GPL violation is fixed.

It amazes me that people who would scream bloody murder about people selling bootleg copies of CDs or ebooks are so willing to forgive device manufacturers for doing the exact same thing. Both cases are copyright infringement. The only difference is that most GPL copyright owners are not organized with armies of lawyers and lobbyists whereas media companies are.

HarryT · 04-21-2008, 02:28 AM

Quote:

Originally Posted by drwowe

It amazes me that people who would scream bloody murder about people selling bootleg copies of CDs or ebooks are so willing to forgive device manufacturers for doing the exact same thing. Both cases are copyright infringement. The only difference is that most GPL copyright owners are not organized with armies of lawyers and lobbyists whereas media companies are.

You need to contact Netronix (the manufacturers of the Gen3) and "scream bloody murder" at them if this upsets you. They are the ones who are refusing to release the Linux source, not Bookeen.

tompe · 04-21-2008, 08:24 AM

Quote:

Originally Posted by HarryT

You need to contact Netronix (the manufacturers of the Gen3) and "scream bloody murder" at them if this upsets you. They are the ones who are refusing to release the Linux source, not Bookeen.

I do not get the reasoning here. It is Bookeen that is distributing the device without having the source to distribute. It is Bookeen that is doing wrong at least as much as Netronix if not more since Bookeen did not tell the customers about this. Netronix did tell Bookeen about it.

HarryT · 04-21-2008, 09:33 AM

What did Netronix tell Bookeen? All I've heard (and it might even have been from you!) is that Bookeen have said that they are unable to get the source from the hardware manufacturer - Netronix.

On a practical level, what do you expect Bookeen to do about it? Stopping selling the Gen3 and go bust?

delphidb96 · 04-21-2008, 11:17 AM

Quote:

Originally Posted by HarryT

You need to contact Netronix (the manufacturers of the Gen3) and "scream bloody murder" at them if this upsets you. They are the ones who are refusing to release the Linux source, not Bookeen.

From what I've heard from Netronix, they're not making anything "hidden" about the version of Linux they're using. And it might well be that they've been concentrating more on upgrading than on keeping people abreast. Right now, they're moving from embedded Linux 2.4 to 2.6. I should know more about the version they're using this week.

Derek

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
iRex in violation of Credit Card agreements?	Kakyou	iRex	24	07-21-2006 11:17 AM

03-09-2008, 08:56 AM	#109
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	I'm curious as to what the practical difference is between statically and dynamically linking to a library in an embedded system such as the Gen3. Suppose you were to find a bug in the C runtime library - you couldn't do anything about it. Why does it therefore matter, from purely practical considerations, if you statically link the library? I fully accept, by the way, that the LGPL says that you shouldn't. I'm asking here about the practical rather than the "legal" implications of doing so.

03-09-2008, 09:15 AM	#110
igorsk Wizard Posts: 3,442 Karma: 300001 Join Date: Sep 2006 Location: Belgium Device: PRS-500/505/700, Kindle, Cybook Gen3, Words Gear	Dynamic linking to a library allows you to: 1) replace the library without relinking the complete application (e.g. to fix the bug you mention) 2) (on some systems) share the library's code between several processes instead of having a complete copy in each process's memory space. If you're more familiar with Windows programming, calling a DLL is an example of dynamic linking. I've read somewhere a comparison involving books: dynamic linking would be something akin to a reference to another book in a footnote while static linking is like including the complete text in its entirety.

03-09-2008, 09:18 AM	#111
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Hi igorsk, Yes, I completely understand what dynamic linking is, and that it both allows you to easily fix a bug in an RTL, and potentially reduce memory needs too. All I was wondering though is, from a practical perspective, as users o the CyBook, why does it matter, given that we have to reply on Bookeen to replace libraries, etc; we can't do so ourselves.

03-10-2008, 07:47 AM	#114
tompe Grand Sorcerer Posts: 7,452 Karma: 7185064 Join Date: Oct 2007 Location: Linköpng, Sweden Device: Kindle Voyage, Nexus 5, Kindle PW	This might be a case were version 3 of the LGPL is much clearer. Version 3 says explicitly that you have to provide installation instructions. Version 2 does not say that explicitly which probably was a motivation to do a version 3. But I have not followed that debate so I am guessing.

03-10-2008, 08:44 AM	#115
Snuffi Addict Posts: 245 Karma: 718 Join Date: Dec 2007 Location: Vienna Device: Pocketbook Pro 612, Bookeen Cybook Gen3	I am not a programmer but in theory it would be well possible to exchange a library in a firmware. I can give you a specific example: A hardware mediaplayer (sold amongst others by Freecom) had/has a firmware which consist of open source libraries, hardware drivers (not sure whether they were open or closed source, nobody messed around with them), a single piece of closed source software (the player) plus quite a few scripts, graphics files and some such. After experimenting around people managed to take apart the firmware into the above mentioned parts (as already stated, I'm not a programmer, but from following that thread for over a year I assume that there are only so many ways to pack stuff into a firmware file and people who work in that field are certain to get to the point sooner or later where they can take it apart). Once the files were available there was a number of uses which the various people found: 1) one of the simplest was to change the graphics (to something prettier, or in another language -> as the buttons were all just graphics) 2) change the scripts to modify the behaviour of the system 3) include additional libraries called from modifies parts of the script (they managed to include an ftp and telnet server that way so you could remote control the system via telnet) 4) exchange libraries for less buggy ones or maybe just smaller ones to speed things up or make room for other stuff So, basically, there IS practical use for dynamically linked libraries, at least in theory, because you never know when it will be possible to change stuff. A customer service nightmare would be out of the question as usually every vendor clearly states somewhere in all that legalese that if you tamper with the device (both hardware and software) the warranty is null and void and no court on earth would rule that the manufacturer could be held responsible if some idiot bricked their device by re-flashing or suffered some other mis-behaviour from some altered firmware. Of course, one shouldn't be so naive as to assume that there aren't those who brick their device and still try to get the manufacturer to do something about it. Whether the company will be very strict or not will probably also depend on their sales: If a device sells extremely well because people know that you can customize your firmware, exchange graphics and such, the company could possibly be rather lenient because they also benefit from their customers work through increased sales...

04-21-2008, 09:33 AM	#119
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	What did Netronix tell Bookeen? All I've heard (and it might even have been from you!) is that Bookeen have said that they are unable to get the source from the hardware manufacturer - Netronix. On a practical level, what do you expect Bookeen to do about it? Stopping selling the Gen3 and go bust?