Opus Pocketbook 360 firmware on Opus

[Godzil]

Snuffi, What does Bookeen use that they does not deliver?

Tompe, if I'm correct the drivers that bookeen have as proprietary are compiled as module, not embedded inside the kernel.

[HarryT]

I seem to recall that there were some concerns that Bookeen were statically linking to some libraries to which they should have linked dynamically.

[Godzil]

I wasn't aware if this fact

[HarryT]

I'm sure that someone (Tommy?) can fill in the details. I have only a vague memory of it, I'm afraid. If I recall correctly, the issue was that, according to the GPL, if you statically link with a GPL library, then that makes the entire module GPL'd, and you have to supply all its source code, which Bookeen weren't. Or something like that...

[Godzil]

That's why I hate the GPL

[Snuffi]

Originally Posted by Godzil

Snuffi, What does Bookeen use that they does not deliver?

Tompe, if I'm correct the drivers that bookeen have as proprietary are compiled as module, not embedded inside the kernel.

Sorry for the delay in answering, was busy...

My information comes from the "Developer's corner" forum. Last status was that dottedmag reported:

"As it turned out, Bookeen "forgot" to add eink driver source code (and several other files) to zip file. As this code is compiled into the kernel, not as module, this is a serious violation."

and

"There are lots of changes in kernel beside removed files, and provided source can't be compiled. Jekhor and me are working on finding out what exactly has been omitted (Bookeen did not provide pointers for the toolchain (another problem!), and this makes situation harder)."

It's been a while but I haven't heard anything since so I suppose the situation is still the same...

[Godzil]

But maybe they does not use the PVI eInk driver and use their own proprietary driver? and for me its look like it is present. There are a FB driver for eInk but it seems to not be compiled by default on the configurations they provide.
And I don't think the code may need to be compiled inside the kernel, the driver can be in the userland.

[Snuffi]

Originally Posted by HarryT

I'm sure that someone (Tommy?) can fill in the details. I have only a vague memory of it, I'm afraid. If I recall correctly, the issue was that, according to the GPL, if you statically link with a GPL library, then that makes the entire module GPL'd, and you have to supply all its source code, which Bookeen weren't. Or something like that...

If you statically link a driver into the kernel it is considered part of the kernel and therefore the GPL covering the kernel extends to the driver and covers that code as well. If you do not want your code covered by the GPL you can dynamically link it so it is not an integral part of the code.

The idea behind handling this that way is that it should be possible for everyone to compile and use GPLed code. If you statically link then it is not possible for someone else to compile the kernel (at least not without major hacking) without the code you held back and therefore you made use of GPLed code for free but gave nothing back in return (as the released code is not useable without your code).

Of course, the option to dynamically link has a couple of drawbacks but there has to be some incentive to share your code with the community... :-)

[Snuffi]

Originally Posted by Godzil

But maybe they does not use the PVI eInk driver and use their own proprietary driver? and for me its look like it is present. There are a FB driver for eInk but it seems to not be compiled by default on the configurations they provide.
And I don't think the code may need to be compiled inside the kernel, the driver can be in the userland.

Sorry, compiling kernels is quite above my head. I know the theory but haven't really done that myself so I can't really see for myself. The information I have about them being in violation of the GPL is a bit dated but I supposed that if something had changed in the meantime that I would have heard about it in the forums here. But if you have first hand experience that everything is there now that's great news!

About the driver: Yes, you are right, it does not have to be in the kernel. That's what dynamically linking is and in that case you don't have to provide your source code as that does not count as a change to the GPLed code. Statically linking, however, is more efficient as your code is directly compiled into the kernel and therefore usually if you are tight on RAM, CPU power, etc. you would rather like to statically link. But unless you plan to release your source code that's a forbidden road :-)

[T_Frain_K]

That´s exactly why GPL is considered a "viral" license.
Honestly, as a paying costumer I cannot understand how resources are beeing wasted to avoid such - to the majority of the world - irrelevant problems.
Then again, beeing a geek, I can...

[Snuffi]

Originally Posted by T_Frain_K

That´s exactly why GPL is considered a "viral" license.
Honestly, as a paying costumer I cannot understand how resources are beeing wasted to avoid such - to the majority of the world - irrelevant problems.
Then again, beeing a geek, I can...

It might be boring behind-the-scenes stuff to a customer but it's not irrelevant.

Bookeen basically has two scenarios:
1) If they open source the whole thing someone might get the idea to buy the hardware cheap from a competitor and just use their FW. That might limit their financial possibilities.

2) If they keep their self-developed stuff closed source that might mean that they have to solve some things differently which could mean a whole range of problems: from annoying issues which are hard to fix due to design reasons to limitations of what they can implement altogether (of course there is a solution for everything in theory, but in practice it's "if it's too complicated and time consuming to do then skip it").

The decision for one or the other will always impact the customer in one way or the other...

[user_none]

Originally Posted by Snuffi

Statically linking, however, is more efficient as your code is directly compiled into the kernel and therefore usually if you are tight on RAM, CPU power, etc. you would rather like to statically link.

The only drawback of using a module vs static is load time (it takes longer to load a module than to initialize a static component). Once a module is loaded there is no performance difference between the two.

Originally Posted by T_Frain_K

Honestly, as a paying costumer I cannot understand how resources are beeing wasted to avoid such - to the majority of the world - irrelevant problems.

The savings from using Linux as the base system often far out weigh the effort to comply with the license. If this is not the case then licensing something like VxWorks would have been a better choice. But even then they would still have to comply with the license and still spend resources ensuring compliance. The only difference would be how the public sees and the ratio of time/money spent on compliance vs licensing vs man power to implement.

[Seventh Son]

I hate to interrupt this wonderful discussion, but I'm still interested in the original topic of this thread
Maybe somebody adventurous could try obtaining/extracting the FW from 360 and flashing it to Opus?

[EowynCarter]

Conclusion last time was the cybook and pocketbook don't use the same process for install. Pooketbook won't see cybook installer and vice versa.
It's not possible to do that. Period.
If you want the poketbook firmware, go buy a pocketbook.

[Godzil]

Using drivers as a modules have some interesting effect for embedded devices. They allow the kernel to boot speedier, reduce the size of kernel, allow you to fine tune the memory footprint (by inserting only usefull modules and removing the non useful one) etc...

Even if that sound strange for some, the kernel modularity have some usefullness even on embedded programming (for thoses who are insterested I recommand this website : http://elinux.org/Main_Page )

And for installing the PocketBook firmware on the opus, you have another choice: working for Bookeen or for PocketBook, you may have access to some informations that are not publicly available