From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22651 invoked by alias); 2 Apr 2003 18:24:22 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 22638 invoked from network); 2 Apr 2003 18:24:22 -0000 Subject: Re: drivers with proprietary code From: Gary Thomas To: Jonathan Larmour Cc: Mark Salter , eCos Maintainers In-Reply-To: <3E8B188F.3060303@eCosCentric.com> References: <20030402131333.0427E7884A@deneb.localdomain> <1049295972.16195.7723.camel@hermes.chez-thomas.org> <3E8B188F.3060303@eCosCentric.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: Wed, 02 Apr 2003 18:24:00 -0000 Message-Id: <1049307861.16212.8333.camel@hermes.chez-thomas.org> Mime-Version: 1.0 X-SW-Source: 2003-04/txt/msg00007.txt.bz2 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: | gpg: http://www.chez-thomas.org/gary/gpg_key.asc ------------------------------------------------------------