Re: drivers with proprietary code

[Mark Salter <msalter@redhat.com>]

>>>>> 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