Re: drivers with proprietary code

[Jonathan Larmour <jifl@eCosCentric.com>]

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