need proprietary alternative to GPL-licensed functions in linux/drivers/base/class.c
lightdee
functions in linux/drivers/base/class.c to work with sysfs & udev:
class_create(), class_device_create(), etc.
I'm using the Centos 5.2 release with Linux kernel 2.6.24.7-65. I had
to change the license to GPL
MODULE_LICENSE("GPL");
to get the driver to compile because of the
EXPORT_SYMBOL_GPL(class_create);
in class.c.
I need to keep the driver proprietary, so how do I work with udev and
sysfs without using the functions in class.c? Is there another non-gpl
interface to those systems?
It looks like I'm going to run into this same issue with the lower-
level functions that class_create() calls, like sysfs_create_file(),
kobject_uevent(), etc, so I can't just do an end-run around those
functions.
Chris Friesen
> I'm developing a driver for my employer and am using some of the
> functions in linux/drivers/base/class.c to work with sysfs & udev:
> class_create(), class_device_create(), etc.
> I'm using the Centos 5.2 release with Linux kernel 2.6.24.7-65. I had
> to change the license to GPL
> MODULE_LICENSE("GPL");
> to get the driver to compile because of the
> EXPORT_SYMBOL_GPL(class_create);
> in class.c.
>
> I need to keep the driver proprietary, so how do I work with udev and
> sysfs without using the functions in class.c? Is there another non-gpl
> interface to those systems?
Are you planning on distributing the driver? If not, you can do
whatever you want. If so, then the short answer is that you can't
easily do what you want to do. This is by design--the intent of
specifying EXPORT_SYMBOL_GPL on those interfaces is to indicate that
anything using them is very likely a derived work of the kernel.
Why does the driver need to be kept proprietary? Most hardware isn't
all that original, and many hardware vendors are realizing that improved
linux support gets them more than proprietary drivers.
One possibility if you have a section that must remain proprietary for
regulatory reasons is to first implement that section independently of
linux and then write a GPL'd open source shim layer to handle the
interaction with linux. This is the route that Nvidia uses. However it
must be obvious to all that the proprietary section is not a derived
work of linux for this to even have a chance.
In any case, if you intend to do anything other than a full GPL driver
you should obtain qualified legal advice first.
Chris
lightdee
using it. So there's
no community linux support either.
It seems strange that the udev and sysfs interfaces shut out
proprietary drivers -
it seems that most driver developers would
want to use those interfaces, instead of statically creating device
nodes & manually loading -
doesn't seem to have anything to do with being a "derived work" any
more than
using any other basic kernel interface, like printk().
thanks for your response, btw.
Chris Friesen
> The hardware is in a medical device, so only our customers will be
> using it. So there's no community linux support either.
There is no need to make the source code available to the community at
large. To abide by the GPL it is sufficient to ship the source code
with the product itself.
If you did decide to submit the code to mainline, in a case like yours
the community obviously can't test it, but they will generally at least
update the driver's API usage when the core APIs change. Uncommon
hardware is not a barrier to submission to mainline. There is at least
one driver in the kernel for which only one device exists in the world.
> It seems strange that the udev and sysfs interfaces shut out
> proprietary drivers -
> it seems that most driver developers would
> want to use those interfaces, instead of statically creating device
> nodes & manually loading -
> doesn't seem to have anything to do with being a "derived work" any
> more than
> using any other basic kernel interface, like printk().
Many of the core kernel developers are ideologically against
closed-source drivers, and as such see no need to make it easy to
develop them.
There are people that think even using something like printk() could
result in the module being a derived work. That's a legal issue though,
not a technical one, and as such the answer may change depending on
where exactly your company is doing business.
You still haven't answered why your company wants to keep the driver
proprietary. Do they think that providing the driver source to your
customers is going to somehow give an advantage to your competitors?
Chris
Joe Pfeiffer
> hardware is not a barrier to submission to mainline. There is at least
> one driver in the kernel for which only one device exists in the
> world.
I'm curious -- which one is that?
--
Klingon programs don't have parameters. They have arguments and win
them (Walter Bushell)
David Schwartz
> Are you planning on distributing the driver? If not, you can do
> whatever you want. If so, then the short answer is that you can't
> easily do what you want to do. This is by design--the intent of
> specifying EXPORT_SYMBOL_GPL on those interfaces is to indicate that
> anything using them is very likely a derived work of the kernel.
It doesn't matter. Even if it's a derived work, he can still
distribute it without complying with the GPL terms. You cannot use
copyright to restrict the only way of accomplishing a particular
function. The merger doctrine creates an exception to copyright in
this case. Only a patent can cover the only way of accomplishing a
particular functional task.
If it is literally the only practical way to make your driver work,
then you can do it. And you need not comply with the GPL.
Copyright only covers one a large number of equally-good, equally-
practical ways of accomplishing a task.
IANAL. This is not legal advice. Copyrights are not patents.
DS
Chris Friesen
> Chris Friesen <cbf...@mail.usask.ca> writes:
>> hardware is not a barrier to submission to mainline. There is at least
>> one driver in the kernel for which only one device exists in the
>> world.
>
> I'm curious -- which one is that?
The particular case I'm thinking of was mentioned by Greg K-H at linux
symposium a while back...can't remember the actual device.
However, I seem to recall that Intel submitted drivers for some of their
dma engine hardware before it was actually available to anyone outside
the company.
Chris
Teemu Likonen
> On 08/18/2009 06:19 PM, Joe Pfeiffer wrote:
>> Chris Friesen <cbf...@mail.usask.ca> writes:
>>> hardware is not a barrier to submission to mainline. There is at
>>> least one driver in the kernel for which only one device exists in
>>> the world.
>>
>> I'm curious -- which one is that?
>
> The particular case I'm thinking of was mentioned by Greg K-H at linux
> symposium a while back...can't remember the actual device.
In Grep Kroah-Hartman's speak "Myths, Lies, and Truths about the Linux
kernel" there's this myth "My driver is only for an obscure piece of
hardware, it would never be accepted into the main kernel."
Kroah-Hartman answers:
This just is not true at all. We have a whole sub-architecture that
only has 2 users in the world out there. We have drivers that I know
have only one user, as there was only one piece of hardware ever
made for it. It just isn't true, we will take drivers for anything
into our tree, as we really want it.
Joe Pfeiffer
lightdee
linux in a commercial product, and the management is more comfortable
with keeping as much code as possible proprietary. However, I think
that the option of shipping the driver source code with the product
itself might be fine with them, since it will only end up with
customers.
Joe Pfeiffer
Much as I hate to do anything to discourage what seems like a good
approach to me, you should be aware that if you GPL your driver you will
not be able to put restrictions on the customers further distributing
the source.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
David Schwartz
> lightdee <light...@gmail.com> writes:
> > Thanks for all the responses guys. My company is kind of new to using
> > linux in a commercial product, and the management is more comfortable
> > with keeping as much code as possible proprietary. However, I think
> > that the option of shipping the driver source code with the product
> > itself might be fine with them, since it will only end up with
> > customers.
> Much as I hate to do anything to discourage what seems like a good
> approach to me, you should be aware that if you GPL your driver you will
> not be able to put restrictions on the customers further distributing
> the source.
Or your competitors redistributing your source with their own
hardware. However, that almost always turns out to be an overblown
fear. GPLing your driver is almost always the best solution. If
nothing else, it increases the value of your hardware because
customers can understand, debug, and customize the driver if they need
to. They can also customize Linux without breaking (or fearing they
broke) your driver.
What happens in 8 years when you stop maintaining the driver? Does
your hardware now become worthless?
You are taking from Linux, it makes sense to give back. It's very hard
to sell Linux hardware when the driver's not publicly available.
Even if this is an appliance and those issues don't apply, there are
other similar arguments that do.
DS
Chris Cox
It DOES NOT have to ship with the product itself. It just has to be
made available. It's somewhat of an obscure thing in the GPL with
regards to delivery mechansism. Some are easier than others.
However, once I (myself) get a copy of your source (by whatever means),
I can make that source available however I wish.
Also, in most all cases, people don't want to take over the development
of the driver for your product... they figure, you're the experts...
Many will choose to make the source available online.... this is
probably best since you might patch the driver someday.
With regard to "IP" fears... worst case is that your competition
uses/exploits something you are doing since your source is visible. But
arguably, that's just a bug in the source code itself.
Chris Friesen
> It DOES NOT have to ship with the product itself. It just has to be
> made available. It's somewhat of an obscure thing in the GPL with
> regards to delivery mechansism. Some are easier than others.
The linux kernel is licensed GPLv2. Thus, the options for commercial
distribution are:
1) Ship the source with the product. Obligation done.
2) Ship the product with a written offer to provide the source. If this
option is chosen, then you need to provide the source to anyone that
asks for a period of three years. As interpreted by the company that I
work fork this would require you to keep track of which versions of
source code apply to which versions of your product to ensure that you
can deliver the source code for the specific binary version that any
given person may be running.
Given these two options, the first is significantly simpler and less hassle.
Chris
David Schwartz
> The linux kernel is licensed GPLv2. Thus, the options for commercial
> distribution are:
>
> 1) Ship the source with the product. Obligation done.
>
> 2) Ship the product with a written offer to provide the source. If this
> option is chosen, then you need to provide the source to anyone that
> asks for a period of three years. As interpreted by the company that I
> work fork this would require you to keep track of which versions of
> source code apply to which versions of your product to ensure that you
> can deliver the source code for the specific binary version that any
> given person may be running.
>
> Given these two options, the first is significantly simpler and less hassle.
Though others disagree, IMO, a URL is a medium customarily used for
software exchange and providing a URL at which the source code can be
downloaded complies with the requirements under 3a. This, of course,
assume the URL gives the complete source code for the exact version
distributed and doesn't require registration or other hoop jumping.
DS
Chris Friesen
> On Aug 24, 6:49 am, Chris Friesen <cbf...@mail.usask.ca> wrote:
>
>> The linux kernel is licensed GPLv2. Thus, the options for commercial
>> distribution are:
>>
>> 1) Ship the source with the product. Obligation done.
> Though others disagree, IMO, a URL is a medium customarily used for
> software exchange and providing a URL at which the source code can be
> downloaded complies with the requirements under 3a. This, of course,
> assume the URL gives the complete source code for the exact version
> distributed and doesn't require registration or other hoop jumping.
I think an argument could be made that such a URL might satisfy the
intent of the GPL.
On the other hand, there's no time limit for 3a so if you included a URL
instead of physical media you're committed to perpetually keeping that
address valid.
Chris
David Schwartz
> On the other hand, there's no time limit for 3a so if you included a URL
> instead of physical media you're committed to perpetually keeping that
> address valid.
It's equally unreasonable to read that since there's no time limit,
you're not required to keep it valid for any time at all. I think a
reasonable place to meet in the middle is that the URL has to be valid
for a reasonable time. Since 3b sets out a three-year validity time
frame for another way to meet the same requirement, a three-year time
frame is presumptively reasonable for 3a as well.
DS
Chris Friesen
The point of 3a is that the source is distributed with the app itself,
and is thus always available to anyone who obtains the app at any point
in the future.
If you choose to not distribute the source with the app, 3b allows you
to include a written offer to make the source available to any third
party within the next three years.
On further reflection, I suspect that accompanying the product with an
unrestricted URL could be argued to fulfill the requirements of 3b in
any case[1], so it's probably better to consider that scenario as
falling under 3b instead of 3a. In that case it would be sufficient to
keep the URL active for three years.
Chris
[1] 3b reads:
"Accompany it with a written offer, valid for at least three years, to
give any third party, for a charge no more than your cost of physically
performing source distribution, a complete machine-readable copy of the
corresponding source code, to be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange;"
It would seem that a written offer pointing to a URL would satisfy this.
David Schwartz
> The point of 3a is that the source is distributed with the app itself,
> and is thus always available to anyone who obtains the app at any point
> in the future.
No, the point is that it's reasonable available. There is no known
source distribution mechanism that lasts forever. When that clause was
written, floppies were probably envisioned, which last about 8 years
at best.
> If you choose to not distribute the source with the app, 3b allows you
> to include a written offer to make the source available to any third
> party within the next three years.
Right, because the authors felt that three years was a reasonable
amount of time to guarantee validity.
> On further reflection, I suspect that accompanying the product with an
> unrestricted URL could be argued to fulfill the requirements of 3b in
> any case[1], so it's probably better to consider that scenario as
> falling under 3b instead of 3a. In that case it would be sufficient to
> keep the URL active for three years.
It's not quite a perfect fit under any of the clauses, but I think I
agree with you that looking at the URL as a written offer to provide
the source code, with the Internet being the customary medium for
software interchange, is the best fit.
DS
aame...@gmail.com
> I need to keep the driver proprietary, so how do I work with udev and
> sysfs without using the functions in class.c? Is there another non-gpl
> interface to those systems?
Then from your proprietary driver call those functions instead of sysfs/udev functions, and voila!
I call this driver "gplf" for "GPL f***er". ;)
If there are any lawyers around, they will hopefully tell if this is legal or not in terms of GPL. But technically, it works.