 |
|
| Linux Forum Index » Linux Embedded » Do you know how to cope against GPL/LGPL in embedded... |
|
Page 1 of 1 |
|
| Author |
Message |
| demiahn... |
 Posted: Wed Jul 15, 2009 7:15 pm |
|
|
|
Guest
|
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? |
|
|
| Back to top |
|
|
|
| Michael Schnell... |
| Posted: Thu Jul 16, 2009 12:31 am |
|
|
|
Guest
|
Quote:
1) Should we open kernel device driver source codes we've developed for our
device?
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)
Quote:
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?
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.
Quote: If we links to the LGPL Library dynamically(shared library), should we
open it also?
Seemingly no problem here.
Quote:
3) How do you cope against GPL/LGPL in embedded linux?
:)
-Michael |
|
|
| Back to top |
|
|
|
| David Brown... |
| Posted: Thu Jul 16, 2009 2:46 am |
|
|
|
Guest
|
Michael Schnell wrote:
Quote:
1) Should we open kernel device driver source codes we've developed
for our device?
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)
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.
Quote:
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?
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.
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).
Quote: If we links to the LGPL Library dynamically(shared library),
should we open it also?
Seemingly no problem here.
3) How do you cope against GPL/LGPL in embedded linux?
You *work with* the (L)GPL, not *cope against* it! |
|
|
| Back to top |
|
|
|
| Michael Schnell... |
| Posted: Thu Jul 16, 2009 1:36 pm |
|
|
|
Guest
|
Quote: binary-only drivers from Nvidia
and ATI for examples.
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.
-Michael |
|
|
| Back to top |
|
|
|
| David Brown... |
| Posted: Fri Jul 17, 2009 2:53 am |
|
|
|
Guest
|
Michael Schnell wrote:
Quote: binary-only drivers from Nvidia and ATI for examples.
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.
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. |
|
|
| Back to top |
|
|
|
| 7... |
| Posted: Fri Jul 17, 2009 2:01 pm |
|
|
|
Guest
|
demiahn wrote:
Quote: 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 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. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Tue Dec 01, 2009 7:49 am
|
|