Re: [ECOS] License restrictions

[Bart Veer <bartv at redhat dot com>]

>>>>> "Wilson" == Wilson Kwan <wilson@kinesphere.com> writes:

    Wilson> Another question on this topic....
    Wilson> What if someone were to emulate a library or device API of
    Wilson> a GPLd piece of code but did not use any of the GPL code?
    Wilson> Is it legal to write *from scratch* a new driver to
    Wilson> emulate the interface for interoperability, this of course
    Wilson> would involve looking at the header files at a minimum?

The more common scenario involves the other direction: producing a
free reimplementation of proprietary software. One example is the
header files provided for mingw, allowing non-cygwin Windows
applications to be written using gcc/g++. I believe these header files
were implemented using documentation that was publicly available from
Microsoft, without looking at any of the header files shipped with
Visual C++. Similarly, free software Java libraries are generally
implemented in a clean room environment, looking only at publicly
available documentation and with no access to any Java source code
from Sun.

If you wanted to reimplement an existing GPL'd library so that you
could use with proprietary code, you are certainly free to do so by
using the library's public documentation - subject to any silly laws
about reverse engineering that may have been passed wherever you
happen to be based. If you want to examine the header files the
situation becomes somewhat more murky given the mingw precedent, and I
am not aware of any official FSF opinions on this issue. For C code it
should not really be a problem (obviously that is not a legal
opinion). For C++ code, the header files typically contain much more
implementation detail than for C code, courtesy of templates and
inline functions, so things are not so clear-cut.

For a GPL'd device driver, I am not sure what you are hoping to
achieve. If you want to take an existing Linux device driver and
implement a proprietary replacement for it, that device driver would
still be linked with the Linux kernel (either statically or
dynamically) so licensing issues still arise. Assuming you can get
past that hurdle, you would still have to persuade people to use your
new driver rather than the existing GPL'd one - e.g. by offering very
significantly improved performance.

Any further discussion should probably be taken to a more appropriate
forum such as the gnu.misc.discuss newsgroup.

Bart