drivers with proprietary code

drivers with proprietary code

[Mark Salter]

I'm working on a board that has proprietary network hardware. The
CPU contains dedicated "network engines" that require binary-only
microcode to run. The interface between this microcode and the CPU
core is provided by a proprietary library which is available in
source form but under a license that requires permission for use
and distribution. I have written an eCos driver which incorporates
parts of this library to support the builtin ethernet ports in
RedBoot.

I'd like to get a sense of how folks feel about this sort of thing.
Its clear to me that such code goes against the tenets of s.r.c, so
I don't see this driver ever being hosted there. I think in this
case the board manufacturer should supply the driver as a .epk file.
So, I'm thinking that a link from the board's info page on s.r.c to
the board maker's site along with some instructions on building and
using the driver would be okay. What to others think?

--Mark

Re: drivers with proprietary code

[Gary Thomas]

On Wed, 2003-04-02 at 06:13, Mark Salter wrote:
> I'm working on a board that has proprietary network hardware. The
> CPU contains dedicated "network engines" that require binary-only
> microcode to run. The interface between this microcode and the CPU
> core is provided by a proprietary library which is available in
> source form but under a license that requires permission for use
> and distribution. I have written an eCos driver which incorporates
> parts of this library to support the builtin ethernet ports in
> RedBoot.
> 
> I'd like to get a sense of how folks feel about this sort of thing.
> Its clear to me that such code goes against the tenets of s.r.c, so
> I don't see this driver ever being hosted there. I think in this
> case the board manufacturer should supply the driver as a .epk file.
> So, I'm thinking that a link from the board's info page on s.r.c to
> the board maker's site along with some instructions on building and
> using the driver would be okay. What to others think?

This can work, and even be OK with the rest of the license
as I read it.  The way I would handle this would be to set
up a parallel repository for just these drivers, including
the CDL to create them, etc.  With the latest ecosconfig
changes, this should work just like a merged repository.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: drivers with proprietary code

[Jonathan Larmour]

Gary Thomas wrote:
> On Wed, 2003-04-02 at 06:13, Mark Salter wrote:
> 
>>I'm working on a board that has proprietary network hardware. The
>>CPU contains dedicated "network engines" that require binary-only
>>microcode to run. The interface between this microcode and the CPU
>>core is provided by a proprietary library which is available in
>>source form but under a license that requires permission for use
>>and distribution. I have written an eCos driver which incorporates
>>parts of this library to support the builtin ethernet ports in
>>RedBoot.
>>
>>I'd like to get a sense of how folks feel about this sort of thing.
>>Its clear to me that such code goes against the tenets of s.r.c, so
>>I don't see this driver ever being hosted there. I think in this
>>case the board manufacturer should supply the driver as a .epk file.
>>So, I'm thinking that a link from the board's info page on s.r.c to
>>the board maker's site along with some instructions on building and
>>using the driver would be okay. What to others think?
> 
> 
> This can work, and even be OK with the rest of the license
> as I read it.

You mean pointing at it separately I presume, not incorporating the eCos 
driver which uses parts of the library into main CVS.

I take it Mark would also have to seek permission for the use and 
distribution of this driver as well. One interesting problem is if the 
driver is *both* derived from eCos, i.e. using anything GPL+exception, and 
this library. If it is, then the two licenses are incompatible and it 
could never be distributed *at all*.

If he's lucky, Mark might have based it off a driver that is still 100% 
(C) Red Hat, in which case Mark can ask RH legal (or whatever responsible 
company officer) for permission to alter the licence of that driver to 
something more liberal and thus compatible e.g. non-advertising clause BSD 
licence.

 >  The way I would handle this would be to set
> up a parallel repository for just these drivers, including
> the CDL to create them, etc.  With the latest ecosconfig
> changes, this should work just like a merged repository.

I'm not entirely happy about setting up such a repository until we have 
the CDL extensions in place to support licence approval when installing 
and using packages. Right now those aren't yet on the roadmap admittedly - 
just that they were part of the earlier design. I was hoping/assuming that 
would be part of what we'd add for 2.1 or whatever release we decide to be 
truly package based - (i.e. no monolithic repository).

I wouldn't have such a big issue with a separate EPK in the FTP area with 
an accompanying README and so on, because people are more likely to read 
the README there than just use a package out of CVS without considering 
the licence properly.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: drivers with proprietary code

[Mark Salter]

>>>>> Jonathan Larmour writes:

> Gary Thomas wrote:
>> On Wed, 2003-04-02 at 06:13, Mark Salter wrote:
>> 
>>> I'm working on a board that has proprietary network hardware. The
>>> CPU contains dedicated "network engines" that require binary-only
>>> microcode to run. The interface between this microcode and the CPU
>>> core is provided by a proprietary library which is available in
>>> source form but under a license that requires permission for use
>>> and distribution. I have written an eCos driver which incorporates
>>> parts of this library to support the builtin ethernet ports in
>>> RedBoot.
>>> 
>>> I'd like to get a sense of how folks feel about this sort of thing.
>>> Its clear to me that such code goes against the tenets of s.r.c, so
>>> I don't see this driver ever being hosted there. I think in this
>>> case the board manufacturer should supply the driver as a .epk file.
>>> So, I'm thinking that a link from the board's info page on s.r.c to
>>> the board maker's site along with some instructions on building and
>>> using the driver would be okay. What to others think?
>> 
>> 
>> This can work, and even be OK with the rest of the license
>> as I read it.

> You mean pointing at it separately I presume, not incorporating the eCos 
> driver which uses parts of the library into main CVS.

> I take it Mark would also have to seek permission for the use and 
> distribution of this driver as well.

Not really. I haven't thought about distributing it. What I was thinking
was that the library copyright holder would distribute the driver. They
already have a mechanism for a user of their part to get the library
source code. I was thinking along the lines of them also offering a
.epk package with the driver.

> One interesting problem is if the 
> driver is *both* derived from eCos, i.e. using anything GPL+exception, and 
> this library. If it is, then the two licenses are incompatible and it 
> could never be distributed *at all*.

> If he's lucky, Mark might have based it off a driver that is still 100% 
> (C) Red Hat, in which case Mark can ask RH legal (or whatever responsible 
> company officer) for permission to alter the licence of that driver to 
> something more liberal and thus compatible e.g. non-advertising clause BSD 
> licence.

I don't think I have a problem there, but correct me if I'm wrong. This
driver is so unlike an other because the driver interfaces to a library,
not to hardware. The library API actually fits pretty well with the
existing eCos eth driver structure. So, the eCos driver sources that I
created were not based on anything beyond the driver API function
protoypes.

Now, I did do a copy/paste/edit to get the driver .cdl file. So maybe
there is an issue there. I don't know. It doesn't get mixed with the
proprietary pieces, so I think I'm okay.

>> The way I would handle this would be to set
>> up a parallel repository for just these drivers, including
>> the CDL to create them, etc.  With the latest ecosconfig
>> changes, this should work just like a merged repository.

> I'm not entirely happy about setting up such a repository until we have 
> the CDL extensions in place to support licence approval when installing 
> and using packages. Right now those aren't yet on the roadmap admittedly - 
> just that they were part of the earlier design. I was hoping/assuming that 
> would be part of what we'd add for 2.1 or whatever release we decide to be 
> truly package based - (i.e. no monolithic repository).

> I wouldn't have such a big issue with a separate EPK in the FTP area with 
> an accompanying README and so on, because people are more likely to read 
> the README there than just use a package out of CVS without considering 
> the licence properly.

I also didn't consider a CVS repository for this code other than a
local one that I use. The distributed code would just be an EPK and
maybe prebuilt RedBoot binaries for some boards. These would be
kept on the manufacturer's site, not s.r.c. I don't think we want
to have any proprietary stuff with distribution restrictions there.

--Mark

Re: drivers with proprietary code

[Jonathan Larmour]

Mark Salter wrote:
> Not really. I haven't thought about distributing it. What I was thinking
> was that the library copyright holder would distribute the driver. They
> already have a mechanism for a user of their part to get the library
> source code. I was thinking along the lines of them also offering a
> .epk package with the driver.

Ah, okay.

>>One interesting problem is if the 
>>driver is *both* derived from eCos, i.e. using anything GPL+exception, and 
>>this library. If it is, then the two licenses are incompatible and it 
>>could never be distributed *at all*.
> 
> 
>>If he's lucky, Mark might have based it off a driver that is still 100% 
>>(C) Red Hat, in which case Mark can ask RH legal (or whatever responsible 
>>company officer) for permission to alter the licence of that driver to 
>>something more liberal and thus compatible e.g. non-advertising clause BSD 
>>licence.
> 
> I don't think I have a problem there, but correct me if I'm wrong. This
> driver is so unlike an other because the driver interfaces to a library,
> not to hardware. The library API actually fits pretty well with the
> existing eCos eth driver structure. So, the eCos driver sources that I
> created were not based on anything beyond the driver API function
> protoypes.

Using *just* the prototypes associated with an API may be considered "fair 
use" since there's only really one way to do an API. But I'm not sure 
about this, and IANAL.

I know for sure the FSF has taken the position that you can't just get 
round, say, the LGPL by adding code that the LGPL code is absolutely 
dependent on. A reasonably clear equivalent in eCos would be if, for 
example, someone wrote a new HAL but tried to get round the GPL by say 
having a HAL that at one point called my_proprietary_stuff() in a 
different file not covered by the GPL+exception. While it is a separate 
file, it is difficult to argue that it is a different work, in the legal 
sense, and the FSF have certainly been fairly clear about that, since the 
alternative would be an easy workaround for a lot of LGPL stuff. And 
similarly the GPL+exception is pretty close to the LGPL in this respect 
and would potentially suffer the same problem.

None of this has been tested in court of course :-). It's one of the 
classic grey areas of the GPL.

Now, for something like an ethernet driver, there is (pretty much) a 
defined API, and indeed the function prototypes pretty much directly 
follow from that (although care should be taken about copying even 
comments!). However for anything more we have to be pretty clear about the 
origin of the code... or more interestingly the origin of the *idea* of 
the code, since it is intellectual property we are talking about.

If you copy code directly, it's cut and dried - it's GPL+ex. But it's also 
a problem even if you just used the old code as a guide for how to write 
the new code. Sitting here, without seeing the code in question it's 
difficult to judge if that's the case of course!

For example, it's now essentially impossible to create a new HAL that 
isn't GPL+exception since the standard way to do ports is to base it off 
another one. Even if you only kept the "API" definitions and substituted 
in new content, if you used the old content as a guide for how to write 
new content, you would have legal problems. People just *remembering* how 
other HALs are written would be a problem. Witness the problems with 
tainting and Sun JAVA.

You would instead need to write a new "clean room" HAL from scratch using 
only documented API functions.

> Now, I did do a copy/paste/edit to get the driver .cdl file. So maybe
> there is an issue there. I don't know. It doesn't get mixed with the
> proprietary pieces, so I think I'm okay.

Yes that would be okay, although the "code" for that .cdl file (by 
itself!) would have to be shipped with any binaries as per the 
GPL+exception licence as it was still used as a "script used to control 
compilation" thus falling under Section 3 of the GPL.

>>I wouldn't have such a big issue with a separate EPK in the FTP area with 
>>an accompanying README and so on, because people are more likely to read 
>>the README there than just use a package out of CVS without considering 
>>the licence properly.
> 
> I also didn't consider a CVS repository for this code other than a
> local one that I use. The distributed code would just be an EPK and
> maybe prebuilt RedBoot binaries for some boards. These would be
> kept on the manufacturer's site, not s.r.c. I don't think we want
> to have any proprietary stuff with distribution restrictions there.

Right okay.

And to answer Gary:
> I wasn't suggesting that we try to include this in the common CVS
> at all.

I guessed probably not, although I thought you might want to set up a 
separate parallel CVS tree on s.r.c for "non-official-licence" code, e.g. 
code we never got assignments for, or fully GPL'd stuff. This is something 
that we might want to consider down the road with full caveat emptor 
warnings of course - I've certainly talked about it before as a 
possibility (which I'm not 100% about myself either); but I definitely 
didn't want to go this route without a way to notifying people about what 
licence a package _is_ under, so no-one can fail to notice that something 
is e.g. full GPL.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: drivers with proprietary code

[Gary Thomas]

On Wed, 2003-04-02 at 10:06, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > On Wed, 2003-04-02 at 06:13, Mark Salter wrote:
> > 
> >>I'm working on a board that has proprietary network hardware. The
> >>CPU contains dedicated "network engines" that require binary-only
> >>microcode to run. The interface between this microcode and the CPU
> >>core is provided by a proprietary library which is available in
> >>source form but under a license that requires permission for use
> >>and distribution. I have written an eCos driver which incorporates
> >>parts of this library to support the builtin ethernet ports in
> >>RedBoot.
> >>
> >>I'd like to get a sense of how folks feel about this sort of thing.
> >>Its clear to me that such code goes against the tenets of s.r.c, so
> >>I don't see this driver ever being hosted there. I think in this
> >>case the board manufacturer should supply the driver as a .epk file.
> >>So, I'm thinking that a link from the board's info page on s.r.c to
> >>the board maker's site along with some instructions on building and
> >>using the driver would be okay. What to others think?
> > 
> > 
> > This can work, and even be OK with the rest of the license
> > as I read it.
> 
> You mean pointing at it separately I presume, not incorporating the eCos 
> driver which uses parts of the library into main CVS.
> 
> I take it Mark would also have to seek permission for the use and 
> distribution of this driver as well. One interesting problem is if the 
> driver is *both* derived from eCos, i.e. using anything GPL+exception, and 
> this library. If it is, then the two licenses are incompatible and it 
> could never be distributed *at all*.
> 
> If he's lucky, Mark might have based it off a driver that is still 100% 
> (C) Red Hat, in which case Mark can ask RH legal (or whatever responsible 
> company officer) for permission to alter the licence of that driver to 
> something more liberal and thus compatible e.g. non-advertising clause BSD 
> licence.
> 
>  >  The way I would handle this would be to set
> > up a parallel repository for just these drivers, including
> > the CDL to create them, etc.  With the latest ecosconfig
> > changes, this should work just like a merged repository.
> 
> I'm not entirely happy about setting up such a repository until we have 
> the CDL extensions in place to support licence approval when installing 
> and using packages. Right now those aren't yet on the roadmap admittedly - 
> just that they were part of the earlier design. I was hoping/assuming that 
> would be part of what we'd add for 2.1 or whatever release we decide to be 
> truly package based - (i.e. no monolithic repository).
> 
> I wouldn't have such a big issue with a separate EPK in the FTP area with 
> an accompanying README and so on, because people are more likely to read 
> the README there than just use a package out of CVS without considering 
> the licence properly.

I wasn't suggesting that we try to include this in the common CVS
at all.  I was thinking that rather than dealing with an .epk file,
he could just have a parallel repository with whatever drivers, files,
included.  Then there would be no more magic involved than:
  * download repository XYZ
  * Add XYZ to the ECOS_REPOSITORY path
  * Add appropriate packages, etc.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------