Our company releases the image, contains zImage and ramdisk.jffs2. We develop kernel device driver for zImage and application for ramdisk.jffs2.
1) Should we open kernel device driver source codes we've developed for our device?
2) Our application links to the LGPL Library(i.e. printf, malloc, etc) statically. In this case, Should we open our application source codes? or is it possible just to open objects? If we links to the LGPL Library dynamically(shared library), should we open it also?
3) How do you cope against GPL/LGPL in embedded linux?
You are requres to do that (i.e. you need to allow access to the source code to those, whom you provide with the running program)
There is an ongoing debate on that. While using the header files seems no problem, statically linking to LGPL libraries (i.e glibc) is depreciated, as the wording requires that you need to allow your customer to upgrade to a new version of the lgpl code, which seems to be impossible without the code of the application. That is why there are libraries that use some other license.
I believe there is some disagreement as to whether kernel modules must follow the GPL2 - look at the available binary-only drivers from Nvidia and ATI for examples. For these drivers, the "excuse" for not using the GPL is that they are originally non-native or cross-platform drivers adapted to Linux. As long as the drivers stick to a limited set of APIs (no "hacking" into other parts of the kernel) and inform the kernel of their "taint", it seems that such closed-source drivers are grudgingly accepted when there is no open-source alternative. The driver must also be a module - no static linking.
Far and away the best method, however, is to make your kernel module GPL2. For most purposes, the kernel module should be fairly minimal - any hard work should be carried out in user space by preference, since that makes debugging, upgrading and testing much easier, and makes the system safer in the event of bugs. The user space code can use whatever license you want.
It is not impossible to re-do the static linking without the source code
- what you need is the applications "obj" files. However, that's a very messy way to handle updates and upgrades, and while it's following the letter of the LGPL, it's against the spirit. So no one can sue you, but don't expect the library developers to answer your questions!
Basically, you can assume that the LGPL says you can use the headers freely, you can link dynamically with any other code, but modifications to the library and statically linked code must be (L)GPL.
Realistically, you have three sensible choices:
Make your code LGPL or GPL (or something LGPL compatible) and link statically;
Link dynamically to the LGPL library;
Use another C library with a different license (typically a BSD-style license, or a modified (L)GPL license such as used by the gcc runtime target libraries).
You *work with* the (L)GPL, not *cope against* it!
Nvidea uses an ugly trick: doing an open source Kernel-interface (which often gets compiled from the source when you install the driver) and a dynamically linked closed source driver workhorse (I don't know if same runs in user mode). But this workhorse is not considered a real Kernel driver.
If you use community code, it's fair do give something back to the community (test results, bug fixes, enhancements and code that is "based on" the community code),
This is a very useful and clever for any work that can be used by a high count of parties. Of course under certain circumstances, it does make sense, if the code that is very specific for your special application stays propriety and closed.
Whether the "workhorse" part is considered a kernel driver or not depends on who you ask - AFAIK it runs in kernel mode. I believe kernel developers are somewhat split on this issue. Some (like Linus Torvalds) see such drivers as necessary evils - they don't like them, they won't help testing or debugging, they won't help them (such as by guaranteeing a stable kernel API), but they understand that people will make them and use them until there are open source replacements. Others see them as an unnecessary evil, and a violation of the GPL, but can't do very much about them (except help write open source replacements).
The correct way to handle kernel driver development is to put as much as you can under the GPL, and anything that you feel you need to keep closed should be in user space - not linked directly to the kernel or a kernel module.
Often embedded developers seem to miss two important points about releasing their specific kernel code (or other code) under the GPL. First, doing so can be a big benefit if your code has more general use. It means that other developers may be able to help you with testing and debugging, and perhaps even developing it further and adding features. You give something away, and get a lot in return.
On the other hand, if your code is very hardware specific or specialised, you lose nothing by making it GPL - in practice, no one is going to ask you for the code, and you don't have to go out of your way to force it on people. Charging a small handling fee for access to the code is acceptable under the GPL, and will discourage the merely curious. Unless you are worried about direct competitors who can copy your hardware, releasing your code as GPL means little more than a couple of license pages at the back of the instruction manual.
Kudos to the OP for actually asking this question in the first place - many embedded (and non-embedded) developers treat open source software as public domain, and don't even learn the licensing obligations unless someone sues them.
You could and should step back a minute from the argument and look at what you got from the embedded Linux community first.
From the open source community you got busy box, the Linux kernel, the developer tools and many many other items of software which you can't do without. What are giving them back for the millions of man hours you got for free? If its nothing then poor you!
If you open source the stuff you made, then you can expect others to post improvements to your project and make it better. And then you can harness that to make your product better and more revenue from sales because your product has more features. As long as you keep improving your product, you can grow and win a lot quicker.
That is fair.
If you run a closed shop, then others can really help you. You have to write everything yourself. And your product develops more slowly and at more expense and so you are not winning much market share with it.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.