Re: drivers with proprietary code

[Gary Thomas <gary@mlbassoc.com>]

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