This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Re: drivers with proprietary code
>>>>> 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