This is the mail archive of the ecos-maintainers@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: drivers with proprietary code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]