From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10628 invoked by alias); 2 Apr 2003 18:01:34 -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 10620 invoked from network); 2 Apr 2003 18:01:34 -0000 From: Mark Salter To: jifl@eCosCentric.com Cc: gary@mlbassoc.com, ecos-maintainers@sources.redhat.com In-reply-to: <3E8B188F.3060303@eCosCentric.com> (message from Jonathan Larmour on Wed, 02 Apr 2003 18:06:23 +0100) Subject: Re: drivers with proprietary code References: <20030402131333.0427E7884A@deneb.localdomain> <1049295972.16195.7723.camel@hermes.chez-thomas.org> <3E8B188F.3060303@eCosCentric.com> Message-Id: <20030402180123.ABE3C78849@deneb.localdomain> Date: Wed, 02 Apr 2003 18:01:00 -0000 X-SW-Source: 2003-04/txt/msg00006.txt.bz2 >>>>> Jonathan Larmour writes: > 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. Not really. I haven't thought about distributing it. What I was thinking was that the library copyright holder would distribute the driver. They already have a mechanism for a user of their part to get the library source code. I was thinking along the lines of them also offering a .epk package with the driver. > 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. I don't think I have a problem there, but correct me if I'm wrong. This driver is so unlike an other because the driver interfaces to a library, not to hardware. The library API actually fits pretty well with the existing eCos eth driver structure. So, the eCos driver sources that I created were not based on anything beyond the driver API function protoypes. Now, I did do a copy/paste/edit to get the driver .cdl file. So maybe there is an issue there. I don't know. It doesn't get mixed with the proprietary pieces, so I think I'm okay. >> 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 also didn't consider a CVS repository for this code other than a local one that I use. The distributed code would just be an EPK and maybe prebuilt RedBoot binaries for some boards. These would be kept on the manufacturer's site, not s.r.c. I don't think we want to have any proprietary stuff with distribution restrictions there. --Mark