From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8173 invoked by alias); 2 Apr 2003 17:06:24 -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 8148 invoked from network); 2 Apr 2003 17:06:23 -0000 Message-ID: <3E8B188F.3060303@eCosCentric.com> Date: Wed, 02 Apr 2003 17:06:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030314 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Gary Thomas Cc: Mark Salter , eCos Maintainers Subject: Re: drivers with proprietary code References: <20030402131333.0427E7884A@deneb.localdomain> <1049295972.16195.7723.camel@hermes.chez-thomas.org> In-Reply-To: <1049295972.16195.7723.camel@hermes.chez-thomas.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00005.txt.bz2 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