Linus, others...
I'm working for as a consultant for a large hardware company porting
Linux to their new cpu-architecture and everything is pretty much
up and running. Now they want us to develop a closed-source (to
protect their IP) ethernet driver for their proprietary Ethernet MAC.
My question is: Is there a fair way to do this and still comply to
the intent and spirit of the Linux licensing ?
If yes, how ?
/Fredrik
Fredrik Markstr?m wrote:
> Linus, others...
>
> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.
>
> My question is: Is there a fair way to do this and still comply to
> the intent and spirit of the Linux licensing ?
>
> If yes, how ?
In a word, I would say: no.
When developing a non-GPL kernel driver, one finds themselves on very
shaky legal ground. Unless one is 100% sure their code is not legally
considered a derived work from the kernel, it's likely a GPL violation.
One could point out the pile of other Ethernet drivers in the kernel
from the likes of Intel, Broadcom, etc. and ask why those companies did
not feel the need to "protect their IP" in this manner.. as well as the
significant advantages of having their driver in the mainline kernel,
and the horrible disadvantages of trying to manage closed-source drivers..
Thanks for the prompt respons.
I do agree that it would be better for everyone to release it under
GPL and I have already expressed that to our customer.
At this point I feel that we have two possibilities, help our customer
violate GPL or say no to the project. I'd prefer a third option where
I could tell the customer that we can setup the project in a certain
way (some "cleanroom" setup ?) to ensure that the results can not be
considered derived work.
Is your short answer also the definite answer considering this ?
/Fredrik
2008/11/18 Robert Hancock <[email protected]>:
> Fredrik Markstr?m wrote:
>>
>> Linus, others...
>>
>> I'm working for as a consultant for a large hardware company porting
>> Linux to their new cpu-architecture and everything is pretty much
>> up and running. Now they want us to develop a closed-source (to
>> protect their IP) ethernet driver for their proprietary Ethernet MAC.
>>
>> My question is: Is there a fair way to do this and still comply to
>> the intent and spirit of the Linux licensing ?
>>
>> If yes, how ?
>
> In a word, I would say: no.
>
> When developing a non-GPL kernel driver, one finds themselves on very shaky
> legal ground. Unless one is 100% sure their code is not legally considered a
> derived work from the kernel, it's likely a GPL violation.
>
> One could point out the pile of other Ethernet drivers in the kernel from
> the likes of Intel, Broadcom, etc. and ask why those companies did not feel
> the need to "protect their IP" in this manner.. as well as the significant
> advantages of having their driver in the mainline kernel, and the horrible
> disadvantages of trying to manage closed-source drivers..
>
Fredrik Markstr?m wrote:
> Thanks for the prompt respons.
>
> I do agree that it would be better for everyone to release it under
> GPL and I have already expressed that to our customer.
>
> At this point I feel that we have two possibilities, help our customer
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.
The problem is that if it's coded specifically for Linux it's pretty
much inherently a derived work. Things like the NVIDIA binary graphics
driver, the old Atheros madwifi HAL stuff, etc. are on a little more
solid ground as their binary part is theoretically OS-independent and
there's an open-source shim layer to interface to the kernel, but some
would say even they are taking some legal risk.
>
> Is your short answer also the definite answer considering this ?
I don't think anyone on this list is a lawyer, and since this is a legal
question, legal advice would be what I would suggest you and/or this
company should have before considering going down the non-GPL driver
road. The risk is mainly that a kernel contributor (or one of their
employers like IBM, Red Hat, etc.) could sue them for violating the GPL.
>
> /Fredrik
>
>
>
>
> 2008/11/18 Robert Hancock <[email protected]>:
>> Fredrik Markstr?m wrote:
>>> Linus, others...
>>>
>>> I'm working for as a consultant for a large hardware company porting
>>> Linux to their new cpu-architecture and everything is pretty much
>>> up and running. Now they want us to develop a closed-source (to
>>> protect their IP) ethernet driver for their proprietary Ethernet MAC.
>>>
>>> My question is: Is there a fair way to do this and still comply to
>>> the intent and spirit of the Linux licensing ?
>>>
>>> If yes, how ?
>> In a word, I would say: no.
>>
>> When developing a non-GPL kernel driver, one finds themselves on very shaky
>> legal ground. Unless one is 100% sure their code is not legally considered a
>> derived work from the kernel, it's likely a GPL violation.
>>
>> One could point out the pile of other Ethernet drivers in the kernel from
>> the likes of Intel, Broadcom, etc. and ask why those companies did not feel
>> the need to "protect their IP" in this manner.. as well as the significant
>> advantages of having their driver in the mainline kernel, and the horrible
>> disadvantages of trying to manage closed-source drivers..
>>
>
On Tue, 2008-11-18 at 17:52 +0100, Fredrik Markstr?m wrote:
> Thanks for the prompt respons.
>
> I do agree that it would be better for everyone to release it under
> GPL and I have already expressed that to our customer.
>
> At this point I feel that we have two possibilities, help our customer
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.
>
> Is your short answer also the definite answer considering this ?
Why not distributing the driver to your client under the same licence
terms as the kernel (i.e. GPLv2, tell him you're legally tied to it),
and then let your client handle distribution to the end-user the way it
sees fit ?
That way you come out clean, and your client gets to resolve the
eventual legal troubles himself.
Xav
Fredrik Markstr?m wrote:
> At this point I feel that we have two possibilities, help our customer
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.
>
> Is your short answer also the definite answer considering this ?
I'm not a lawyer, and you need to consult one.
There isn't really a "definate answer" since it depends on copyright
law, which varies by region. The key question is whether the driver is
a derivative work of the kernel under copyright law. For the purposes
of copyright law this is primarily a legal question, not a technical one.
There are some that claim that a driver written for another OS and
running in linux via a shim layer could qualify (especially if the
closed-source portion is written without any knowledge of linux
internals). Nvidia is one company that does this, but there are others
as well.
Also, releasing the driver under the GPL doesn't necessarily mean
"released to the world". Technically, they would only need to provide
source code to their customers. Of course, their customers would be
free to redistribute, but it's unlikely that most of them would bother.
Chris
On Tue, 18 Nov 2008 17:16:44 +0100
"Fredrik Markstr?m" <[email protected]> wrote:
> Linus, others...
>
> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.
>
> My question is: Is there a fair way to do this and still comply to
> the intent and spirit of the Linux licensing ?
Ask a lawyer not a kernel hacker. The license is quite clear that if its
a derivative work it must be GPL. Whether it is derivative is a matter
for lawyers to ascertain and you should consult a good one if you wish to
go dancing in minefields. In particular it is wise to remember that the
copyright holders including almost every other large cpu vendor and so
will include their competitors....
As to the spirit, the answer I think is: no.
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.
>
> Is your short answer also the definite answer considering this ?
If you plan to do that kind of engineering you really really need to talk
to lawyers not software developers.
Radhakrishnan wrote:
> Am I therefore right in assuming that this is a specific case where the
> open source nature of Linux is being used with great effect but the very
> nature of the licensing denies ANYONE ELSE from being a party to this
> transaction ?
Actually, I think the GPL is still satisfied. There's nothing that says
that changes need to be passed upstream, only downstream.
1) Presumably you won't be distributing the binary drivers to anyone
else, and you gave Organization A the code, so the license is satisfied.
2) Organization A has no other customers, so is not going to be
distributing the binaries to anyone else.
3) The end-user (the Navy) was provided the source code for the GPL'd
software that they purchased.
As far as I can tell, this is all fully GPL-compliant.
Chris
On Tue, 18 Nov 2008, Chris Friesen wrote:
> Radhakrishnan wrote:
>
>> Am I therefore right in assuming that this is a specific case where the
>> open source nature of Linux is being used with great effect but the very
>> nature of the licensing denies ANYONE ELSE from being a party to this
>> transaction ?
>
> Actually, I think the GPL is still satisfied. There's nothing that says
> that changes need to be passed upstream, only downstream.
>
> 1) Presumably you won't be distributing the binary drivers to anyone
> else, and you gave Organization A the code, so the license is satisfied.
>
> 2) Organization A has no other customers, so is not going to be
> distributing the binaries to anyone else.
>
> 3) The end-user (the Navy) was provided the source code for the GPL'd
> software that they purchased.
>
> As far as I can tell, this is all fully GPL-compliant.
>
> Chris
> --
BTW, Bally, the slot-machine company uses Linux. I have
watched the machines boot. It has driver(s) to interface
with the reels (stepper motors) and the user-interface,
(buttons, money entry, etc.) I'm fairly certain that
if I asked them for the source-code for their drivers
I would not get it. They could claim that, in their
definition of the law, I am not a "qualified end-user."
However, if a casino using the machines were to request
the source-code it is likely that they would comply and
provide it.
It is all about interpretation of law, based upon some
theory claimed for that instant.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.25.17 on an i686 machine (4787.11 BogoMips).
My book : http://www.AbominableFirebug.com/
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 18 Nov 2008 17:16:44 +0100, =?ISO-8859-1?Q?Fredrik_Markstr=F6m?= said:
> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.
Am I the only one that's boggled by the concept of a company that can develop
an entire CPU architecture and be OK on the GPL licensing of all the code
in arch/new-foo-cpu that exposes the IP of the cpu design, but they're worried
about the special sauce in a freakin' *ethernet controller*?
> an entire CPU architecture and be OK on the GPL licensing of all the code
> in arch/new-foo-cpu that exposes the IP of the cpu design, but they're worried
> about the special sauce in a freakin' *ethernet controller*?
Not entirely. There are several reasons this may occur
- They could have something genuinely new - unlikely to be honest
- They could think they have something genuinely new but don't
- They may not yet have filed some relevant patent applications in which
case they have to worry about secrecy
and other reasons.
Probably they should talk to the Linux Foundation. I'm not sure that
assuming they are clueless is the first step. Understanding the problem
as they see it is more important and probably something the Linux
Foundation can help with and under a business to business framework.
On Tue, Nov 18, 2008 at 07:29:42PM +0000, Alan Cox wrote:
>
> Not entirely. There are several reasons this may occur
> - They could have something genuinely new - unlikely to be honest
> - They could think they have something genuinely new but don't
> - They may not yet have filed some relevant patent applications in which
> case they have to worry about secrecy
>
> and other reasons.
>
If I had to guess, they're probably doing some kind variant of TCP,
Crypto, or some other kind of networking offland trick. There really
isn't much else you can do that might be considered new in an ethernet
controller. And it's probably not new.
> Probably they should talk to the Linux Foundation. I'm not sure that
> assuming they are clueless is the first step. Understanding the problem
> as they see it is more important and probably something the Linux
> Foundation can help with and under a business to business framework.
Well, I'm from the Linux Foundation, and I'm here to help. :-)
Seriously, if they are willing to talk to someone, we're certainly
willing to give them some free advice. My guess is that's not very
likely, however.
- Ted
Hello Ted,
I'm the one that started this thread (I'm also responsible for the
screwed up subject :)
Unfortunately I can't disclose our client simply because I have not
asked for their permission.
Anyway strongly doubt they want to do something illegal or wrong, but
a lot of people obviously thinks binary drivers are accepted by the
Linux community and licensing. It sure would be nice if this could be
stated more explicit in some official FAQ.
Your (the Linux Foundations) web gives the impression that you protect
Linux against external interests (like my clients), but do you have
to authority to work the other way ? Can you make deals or promises on
behalf of the copyright owners of the Linux kernel ? I doubt that but
might be wrong.
Anyway, I'm not sure how the Linux Foundation can help in this case,
if you can explain that, I sure will bring it up with our client.
/Fredrik
On Tue, Nov 18, 2008 at 9:20 PM, Theodore Tso <[email protected]> wrote:
> On Tue, Nov 18, 2008 at 07:29:42PM +0000, Alan Cox wrote:
>>
>> Not entirely. There are several reasons this may occur
>> - They could have something genuinely new - unlikely to be honest
>> - They could think they have something genuinely new but don't
>> - They may not yet have filed some relevant patent applications in which
>> case they have to worry about secrecy
>>
>> and other reasons.
>>
>
> If I had to guess, they're probably doing some kind variant of TCP,
> Crypto, or some other kind of networking offland trick. There really
> isn't much else you can do that might be considered new in an ethernet
> controller. And it's probably not new.
>
>> Probably they should talk to the Linux Foundation. I'm not sure that
>> assuming they are clueless is the first step. Understanding the problem
>> as they see it is more important and probably something the Linux
>> Foundation can help with and under a business to business framework.
>
> Well, I'm from the Linux Foundation, and I'm here to help. :-)
>
> Seriously, if they are willing to talk to someone, we're certainly
> willing to give them some free advice. My guess is that's not very
> likely, however.
>
> - Ted
>
>
On Tue, Nov 18, 2008 at 10:13:30PM +0100, Fredrik Markstr?m wrote:
>
> Unfortunately I can't disclose our client simply because I have not
> asked for their permission.
Understood, of course not. All you can do is suggest that they might
want to contact us.
> Anyway strongly doubt they want to do something illegal or wrong, but
> a lot of people obviously thinks binary drivers are accepted by the
> Linux community and licensing. It sure would be nice if this could be
> stated more explicit in some official FAQ.
There are many different ways to use the word "wrong". There is
"morally wrong" (as in, goes against the spirit of the license and of
the development community). There is "legally wrong", which depends
on the legal jurisdiction (of you, the company, and the end user),
which will require a lawyer's input. And then there's "pragamatically
wrong", as in, regardless of whether it's legal, there are significant
technical downsides in trying to trying to develop binary-only drivers
that in the long run will cost you money.
> Your (the Linux Foundations) web gives the impression that you protect
> Linux against external interests (like my clients), but do you have
> to authority to work the other way ? Can you make deals or promises on
> behalf of the copyright owners of the Linux kernel ? I doubt that but
> might be wrong.
No, of course not. That being said, there are binary modules out
there, and there are ways which are "safer" in terms of whether you
are likely to get sued, if the company you are working with wants to
skate close to the dark side and live in the same legal grey zone as
Nvidia and Broadcom.
> Anyway, I'm not sure how the Linux Foundation can help in this case,
> if you can explain that, I sure will bring it up with our client.
We can give advice; but it's well informed advice.
- Ted
There is an interesting situation that seemingly meets the GPL clause
but is also used for developing proprietory drivers, and it works as
under :
Consider an organization A ( the Technical organization ) that is
contracted with developing specific hardware & software for an
organization B that happens to be the Navy.
Also assume that both the organizations ( A & B ) are under the Ministry
of Defence.
Organization A now contracts me, a freelancer, for developing some linux
kernel drivers for an embedded defence related project.
I develop the drivers and hand them over to Organization A and clearly
mark my code as GPL since I believe in the spirit of GPL.
However, Organization A now bundles the code with the specially
'manufactured' hardware and sells it to their ONLY customer,
Organization B ( The Navy ).
Now, Organization B ( The Navy ) who is also the CUSTOMER, INSISTS that
Organization A NOT REVEAL the source code to anybody else and this is
agreed upon by Organization A since the software can ONLY work on the
specific hardware supplied to the Navy and this is a highly classified
project, and cannot/will not be sold to anyone else.
Under this scenario,
a) The software is GPL-ed
b) No-one can get to see the software unless I the developer squeal.
A 3rd party cannot pop-up and demand to see the software since the 3rd
party is not a customer or in any way related to any transaction.
c) If I squeal, I may disappear. Since I am paid for my hard work lets
say I do not have any desire to squeal.
Am I therefore right in assuming that this is a specific case where the
open source nature of Linux is being used with great effect but the very
nature of the licensing denies ANYONE ELSE from being a party to this
transaction ?
V. Radhakrishnan
http://www.atr-labs.com
On Tue, 2008-11-18 at 11:17 -0600, Chris Friesen wrote:
> Fredrik Markström wrote:
>
> > At this point I feel that we have two possibilities, help our customer
> > violate GPL or say no to the project. I'd prefer a third option where
> > I could tell the customer that we can setup the project in a certain
> > way (some "cleanroom" setup ?) to ensure that the results can not be
> > considered derived work.
> >
> > Is your short answer also the definite answer considering this ?
>
> I'm not a lawyer, and you need to consult one.
>
> There isn't really a "definate answer" since it depends on copyright
> law, which varies by region. The key question is whether the driver is
> a derivative work of the kernel under copyright law. For the purposes
> of copyright law this is primarily a legal question, not a technical one.
>
> There are some that claim that a driver written for another OS and
> running in linux via a shim layer could qualify (especially if the
> closed-source portion is written without any knowledge of linux
> internals). Nvidia is one company that does this, but there are others
> as well.
>
> Also, releasing the driver under the GPL doesn't necessarily mean
> "released to the world". Technically, they would only need to provide
> source code to their customers. Of course, their customers would be
> free to redistribute, but it's unlikely that most of them would bother.
>
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Nov 18, 2008 at 05:16:44PM +0100, Fredrik Markstr?m wrote:
> Linus, others...
>
> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.
Ethernet MACs are a commodity these days. Who is dumb enough to think
their ethernet MAC needs to be protected these days?
You make an ethernet MAC... good for you. You have not invented
anything new and amazing that needs protecting. Really. Get over it,
you are not that special. :)
> My question is: Is there a fair way to do this and still comply to
> the intent and spirit of the Linux licensing ?
>
> If yes, how ?
Probably not, but I think the real issue is the previous one.
--
Len Sorensen
Well, who knows ? If you read my email carefully enough you should see
that that is not the question or issue here.
This was my first question to this list ever and I'm impressed with
the good and constructive answers I've gotten, but I really do not
understand the purpose of your response.
/Fredrik
On Wed, Nov 19, 2008 at 7:38 PM, Lennart Sorensen
<[email protected]> wrote:
>
> On Tue, Nov 18, 2008 at 05:16:44PM +0100, Fredrik Markstr?m wrote:
> > Linus, others...
> >
> > I'm working for as a consultant for a large hardware company porting
> > Linux to their new cpu-architecture and everything is pretty much
> > up and running. Now they want us to develop a closed-source (to
> > protect their IP) ethernet driver for their proprietary Ethernet MAC.
>
> Ethernet MACs are a commodity these days. Who is dumb enough to think
> their ethernet MAC needs to be protected these days?
>
> You make an ethernet MAC... good for you. You have not invented
> anything new and amazing that needs protecting. Really. Get over it,
> you are not that special. :)
>
> > My question is: Is there a fair way to do this and still comply to
> > the intent and spirit of the Linux licensing ?
> >
> > If yes, how ?
>
> Probably not, but I think the real issue is the previous one.
>
> --
> Len Sorensen
On Wed, Nov 19, 2008 at 11:32:04PM +0100, Fredrik Markstr?m wrote:
> Well, who knows ? If you read my email carefully enough you should see
> that that is not the question or issue here.
> This was my first question to this list ever and I'm impressed with
> the good and constructive answers I've gotten, but I really do not
> understand the purpose of your response.
I am one of the (apparently few) people that think when someone asks me
to do something counter productive and most likely misguided, I should
help them by educating them in how they are wrong, not just go do what
they want.
So if your client (or potential client) asks you to write a closed
source driver which would potentially be a licence violation (don't ask
me, ask a lawyer, etc), when there is no reason it should be closed
source, then you should go educate them about why it makes no sense to
make it closed source. If they get educated and hence now know more,
hopefully they will be smart enough to now not ask for a closed source
driver, and now the legal problems evaporate and you don't have to deal
with lawyers at all (always a good thing).
The customer is NOT always right. Sometimes the customer just doesn't
have all the facts to know what is the right choice.
So that was my point.
In the case of an ethernet mac, there can't be anything new that needs
protecting (not that reverse engineering the binary for the driver is
necesarily that hard either, so at best it is slowing down, not
protecting really), although I suppose for a wireless ethernet device
some people would claim the FCC and the like insist on not letting users
be able to change some stuff, and again they claim they are protecting
the device by using closed drivers.
You asked a good question, and got a bunch of answers. I hope the end
result is another fully open source driver that can end up included in
the kernel. That of course is another bonus worth pointing out.
Drivers included in the kernel are easily an order of magnitude less
work to maintain, since large kernel structure changes are done for you,
rather than you having to catch up later when it is harder to figure out
what they change was done and what you have to do to fix it.
--
Len Sorensen
* Fredrik Markstr?m ([email protected]) wrote:
> Thanks for the prompt respons.
>
> I do agree that it would be better for everyone to release it under
> GPL and I have already expressed that to our customer.
>
> At this point I feel that we have two possibilities, help our customer
> violate GPL or say no to the project. I'd prefer a third option where
> I could tell the customer that we can setup the project in a certain
> way (some "cleanroom" setup ?) to ensure that the results can not be
> considered derived work.
A 3rd option I think would be for them to put the bits that they worry about
the IP in firmware executed in a processor on the ether chip, then make
a nice clean interface that a GPL'd driver talks to.
Of course that relies on there being a suitable processor in the
chip; if not then perhaps you should remind them to think about
the software before spinning their chip!
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
* Fredrik Markstr?m <[email protected]> wrote:
Hi,
> I'm working for as a consultant for a large hardware company porting
> Linux to their new cpu-architecture and everything is pretty much
> up and running. Now they want us to develop a closed-source (to
> protect their IP) ethernet driver for their proprietary Ethernet MAC.
Much of this already had been answered, but just to summarize:
* technically, binary drivers are a very bad idea - just look at
the utterly broken nv crap.
* IMHO, as soon as you include some kernel-internal headers, you've
got an derived work, thus violating GPL (IANAL!)
* binary-only drivers DON NOT protect IP, just delay the process
of revealing a little bit.
* try to find out whether the customer *really* has some valueble
IP to protect or if it's just it's default oppionion
* *if* the customer still wants an binary-only driver, you check
whether the logic to hide can be moved to userland (let the userland
part talk to the in-kernel driver via 9P)
* let your customer know that binary-only drivers tend to heavily
damage a company's reputation in the OSS world, *BAD* for marketing.
just my 0.02,-
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------