From: Jonathan Larmour <jifl@eCosCentric.com>
To: Mark Salter <msalter@redhat.com>
Cc: gary@mlbassoc.com, ecos-maintainers@sources.redhat.com
Subject: Re: drivers with proprietary code
Date: Wed, 02 Apr 2003 21:02:00 -0000 [thread overview]
Message-ID: <3E8B3184.3070507@eCosCentric.com> (raw)
In-Reply-To: <20030402180123.ABE3C78849@deneb.localdomain>
Mark Salter wrote:
> 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.
Ah, okay.
>>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.
Using *just* the prototypes associated with an API may be considered "fair
use" since there's only really one way to do an API. But I'm not sure
about this, and IANAL.
I know for sure the FSF has taken the position that you can't just get
round, say, the LGPL by adding code that the LGPL code is absolutely
dependent on. A reasonably clear equivalent in eCos would be if, for
example, someone wrote a new HAL but tried to get round the GPL by say
having a HAL that at one point called my_proprietary_stuff() in a
different file not covered by the GPL+exception. While it is a separate
file, it is difficult to argue that it is a different work, in the legal
sense, and the FSF have certainly been fairly clear about that, since the
alternative would be an easy workaround for a lot of LGPL stuff. And
similarly the GPL+exception is pretty close to the LGPL in this respect
and would potentially suffer the same problem.
None of this has been tested in court of course :-). It's one of the
classic grey areas of the GPL.
Now, for something like an ethernet driver, there is (pretty much) a
defined API, and indeed the function prototypes pretty much directly
follow from that (although care should be taken about copying even
comments!). However for anything more we have to be pretty clear about the
origin of the code... or more interestingly the origin of the *idea* of
the code, since it is intellectual property we are talking about.
If you copy code directly, it's cut and dried - it's GPL+ex. But it's also
a problem even if you just used the old code as a guide for how to write
the new code. Sitting here, without seeing the code in question it's
difficult to judge if that's the case of course!
For example, it's now essentially impossible to create a new HAL that
isn't GPL+exception since the standard way to do ports is to base it off
another one. Even if you only kept the "API" definitions and substituted
in new content, if you used the old content as a guide for how to write
new content, you would have legal problems. People just *remembering* how
other HALs are written would be a problem. Witness the problems with
tainting and Sun JAVA.
You would instead need to write a new "clean room" HAL from scratch using
only documented API functions.
> 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.
Yes that would be okay, although the "code" for that .cdl file (by
itself!) would have to be shipped with any binaries as per the
GPL+exception licence as it was still used as a "script used to control
compilation" thus falling under Section 3 of the GPL.
>>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.
Right okay.
And to answer Gary:
> I wasn't suggesting that we try to include this in the common CVS
> at all.
I guessed probably not, although I thought you might want to set up a
separate parallel CVS tree on s.r.c for "non-official-licence" code, e.g.
code we never got assignments for, or fully GPL'd stuff. This is something
that we might want to consider down the road with full caveat emptor
warnings of course - I've certainly talked about it before as a
possibility (which I'm not 100% about myself either); but I definitely
didn't want to go this route without a way to notifying people about what
licence a package _is_ under, so no-one can fail to notice that something
is e.g. full GPL.
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
next prev parent reply other threads:[~2003-04-02 21:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-02 13:13 Mark Salter
2003-04-02 15:06 ` Gary Thomas
2003-04-02 17:06 ` Jonathan Larmour
2003-04-02 18:01 ` Mark Salter
2003-04-02 21:02 ` Jonathan Larmour [this message]
2003-04-02 18:24 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E8B3184.3070507@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=ecos-maintainers@sources.redhat.com \
--cc=gary@mlbassoc.com \
--cc=msalter@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).