This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Re: drivers with proprietary code
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 at mlbassoc dot com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------