[ECOS] License restrictions

[ECOS] License restrictions

[Robert Ritchey]

How do the licenses for Linux and eCos intertwine, if at all.  If I wanted 
to use a
driver in Linux as a starting point for an eCos driver is there a problem 
with that?
What restrictions do I need to be aware of?  Thanks.

Robert Ritchey
Phoenix, AZ
(480) 460-2652

Re: [ECOS] License restrictions

[Jonathan Larmour]

Robert Ritchey wrote:
> 
> How do the licenses for Linux and eCos intertwine, if at all.  If I wanted
> to use a
> driver in Linux as a starting point for an eCos driver is there a problem
> with that?
> What restrictions do I need to be aware of?  Thanks.

If you own the copyright you can change the licence is you see fit. However
if you use code from someone else (i.e. with their copyright), then you
have to follow the terms of the licence, be it GPL or RHEPL.

So if *you* write it, you can use it in either. But if it contains anybody
elses code, it will be incompatible with the other unless the "anybody
else" explicitly allows for it (e.g. if they put their code in the public
domain (in the legal sense)).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] License restrictions

[Bill Arbaugh]

Has anyone looked at providing some "glue" such that UNIX drivers could
easily be used with eCOS ala OSKit?  I've thought about it, but haven't
had time to fully investigate.

thanks, bill

> 
> 
> How do the licenses for Linux and eCos intertwine, if at all.  If I wanted 
> to use a
> driver in Linux as a starting point for an eCos driver is there a problem 
> with that?
> What restrictions do I need to be aware of?  Thanks.
> 
> Robert Ritchey
> Phoenix, AZ
> (480) 460-2652
> 
> 

Re: [ECOS] License restrictions

[Robert Ritchey]

That seems like a great idea to me and I was going to explore it as I am new
to both Linux and eCos but not if Linux drivers are restricted in some way
that this is not legal.

At 01:28 PM 3/21/01 -0500, Bill Arbaugh wrote:
>Has anyone looked at providing some "glue" such that UNIX drivers could
>easily be used with eCOS ala OSKit?  I've thought about it, but haven't
>had time to fully investigate.
>
>thanks, bill
>
> > How do the licenses for Linux and eCos intertwine, if at all.  If I 
> wanted  to use a
> > driver in Linux as a starting point for an eCos driver is there a 
> problem  with that?
> > What restrictions do I need to be aware of?  Thanks.
> >
> > Robert Ritchey
> > Phoenix, AZ
> > (480) 460-2652
> >
> >

Robert Ritchey
Phoenix, AZ
(480) 460-2652

Re: [ECOS] License restrictions

[Bill Arbaugh]

The license shouldn't be a problem with most drivers.  Take a look at
OSKit from the Univ. of Utah. They essentially did that with a FreeBSD
kernel as the base rather than eCos.

Bill

On Wed, 21 Mar 2001, Robert Ritchey wrote:

> That seems like a great idea to me and I was going to explore it as I am new
> to both Linux and eCos but not if Linux drivers are restricted in some way
> that this is not legal.
> 
> At 01:28 PM 3/21/01 -0500, Bill Arbaugh wrote:
> >Has anyone looked at providing some "glue" such that UNIX drivers could
> >easily be used with eCOS ala OSKit?  I've thought about it, but haven't
> >had time to fully investigate.
> >
> >thanks, bill
> >
> > > How do the licenses for Linux and eCos intertwine, if at all.  If I 
> > wanted  to use a
> > > driver in Linux as a starting point for an eCos driver is there a 
> > problem  with that?
> > > What restrictions do I need to be aware of?  Thanks.
> > >
> > > Robert Ritchey
> > > Phoenix, AZ
> > > (480) 460-2652
> > >
> > >
> 
> Robert Ritchey
> Phoenix, AZ
> (480) 460-2652
> 
> 

Re: [ECOS] License restrictions

[Bart Veer]

>>>>> "Bill" == Bill Arbaugh <waa@cs.umd.edu> writes:

    Bill> The license shouldn't be a problem with most drivers. Take a
    Bill> look at OSKit from the Univ. of Utah. They essentially did
    Bill> that with a FreeBSD kernel as the base rather than eCos.

If you are talking about BSD drivers, there should not be a problem.
In fact the current eCos TCP/IP stack is BSD code. However, it is not
clear to me that many low-level BSD drivers would actually be useful.
If you are developing eCos on an x86 PC or similar hardware, and want
support for e.g. a specific ethernet chip, it would probably be ok.
However if you are developing on something like an SH or an AM33,
a driver intended for use inside a PC might not be all that useful.

There may also be problems when it comes to what those device drivers
expect from the kernel. If the device driver expects to be able to
make BSD kernel calls, manipulate mbufs, etc. then there will be
problems because those facilities will not be provided automatically
by eCos (although some of the required glue may be provided already by
the TCP/IP stack).

Obviously an existing driver can prove a very useful source of
information about hardware bugs and the like, and it is certainly
worthwhile looking at existing sources before attempting to write an
eCos device driver, but that is not the same as directly re-using an
existing driver.

When it comes to Linux there are serious licensing problems. A typical
existing Linux device driver will be licensed under the GPL. With eCos
application code is linked directly to the kernel and hence to the
device drivers, rather than being separated via a system call
interface. Therefore all of the code in the system, including all of
your application, needs to be under a license that is compatible with
the GPL. Typically this means that you would have to release all of
the application source code under an open source license. For most
eCos developers that would be unacceptable.

Bart


    Bill> On Wed, 21 Mar 2001, Robert Ritchey wrote:

    >> That seems like a great idea to me and I was going to explore
    >> it as I am new to both Linux and eCos but not if Linux drivers
    >> are restricted in some way that this is not legal.
    >> 
    >> At 01:28 PM 3/21/01 -0500, Bill Arbaugh wrote:
    >> >Has anyone looked at providing some "glue" such that UNIX drivers could
    >> >easily be used with eCOS ala OSKit?  I've thought about it, but haven't
    >> >had time to fully investigate.
    >> >
    >> >thanks, bill
    >> >
    >> > > How do the licenses for Linux and eCos intertwine, if at all.  If I 
    >> > wanted  to use a
    >> > > driver in Linux as a starting point for an eCos driver is there a 
    >> > problem  with that?
    >> > > What restrictions do I need to be aware of?  Thanks.
    >> > >
    >> > > Robert Ritchey
    >> > > Phoenix, AZ
    >> > > (480) 460-2652
    >> > >
    >> > >
    >> 
    >> Robert Ritchey
    >> Phoenix, AZ
    >> (480) 460-2652
    >> 
    >> 

Re: [ECOS] License restrictions

[Wilson Kwan]

Another question on this topic....

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

Thanks,
Wilson


> Robert Ritchey wrote:
> >
> > How do the licenses for Linux and eCos intertwine, if at all.  If I
wanted
> > to use a
> > driver in Linux as a starting point for an eCos driver is there a
problem
> > with that?
> > What restrictions do I need to be aware of?  Thanks.
>
> If you own the copyright you can change the licence is you see fit.
However
> if you use code from someone else (i.e. with their copyright), then you
> have to follow the terms of the licence, be it GPL or RHEPL.
>
> So if *you* write it, you can use it in either. But if it contains anybody
> elses code, it will be incompatible with the other unless the "anybody
> else" explicitly allows for it (e.g. if they put their code in the public
> domain (in the legal sense)).
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
>

Re: [ECOS] License restrictions

[Lewin A.R.W. Edwards]

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

At its worst, this becomes a "clean-room" exercise like AMI performed on 
the original PC BIOS in order to clone it.

The easiest way to ensure that you've got a provable case is to hire an 
outside entity to look at the existing code and draw up a spec document. 
The spec document should contain no code, it should just document data 
structures and expected behavior.

You then write your driver to conform to the spec document.

It seems a shame that the free software movement should cause such legal 
tangling... *sigh*

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] License restrictions

[Jonathan Larmour]

"Lewin A.R.W. Edwards" wrote:
> 
> It seems a shame that the free software movement should cause such legal
> tangling... *sigh*

Normally free software authors are the ones trying to do the clean room
versions of proprietary implementations!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] License restrictions

[Lewin A.R.W. Edwards]

> > It seems a shame that the free software movement should cause such legal
> > tangling... *sigh*
>
>Normally free software authors are the ones trying to do the clean room
>versions of proprietary implementations!

:) Heheh yes. BTW now I think about it again, it might have been Phoenix 
who did the original PC BIOS clean-rooming.

I wish there was a way around this, there are occasionally bits of Linux in 
particular that would be very handy... I'm like a cat gazing into the 
goldfish bowl - all this tasty free code that works well, but I can't use it.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] License restrictions

[Wilson Kwan]

What are the restrictions on looking at the code and then going off and
completely rewritting it?

What about just looking at the header files and supplied API documentation
and none of the source code?

----- Original Message -----
From: "Lewin A.R.W. Edwards" <larwe@larwe.com>
To: "Jonathan Larmour" <jlarmour@redhat.com>
Cc: "Wilson Kwan" <wilson@kinesphere.com>; <ecos-discuss@sources.redhat.com>
Sent: Friday, March 23, 2001 10:23 AM
Subject: Re: [ECOS] License restrictions


>
> > > It seems a shame that the free software movement should cause such
legal
> > > tangling... *sigh*
> >
> >Normally free software authors are the ones trying to do the clean room
> >versions of proprietary implementations!
>
> :) Heheh yes. BTW now I think about it again, it might have been Phoenix
> who did the original PC BIOS clean-rooming.
>
> I wish there was a way around this, there are occasionally bits of Linux
in
> particular that would be very handy... I'm like a cat gazing into the
> goldfish bowl - all this tasty free code that works well, but I can't use
it.
>
> === Lewin A.R.W. Edwards (Embedded Engineer)
> Work: http://www.digi-frame.com/
> Personal: http://www.zws.com/ and http://www.larwe.com/
>
> "Und setzet ihr nicht das Leben ein,
> Nie wird euch das Leben gewonnen sein."
>
>

Re: [ECOS] License restrictions

[Lewin A.R.W. Edwards]

>What are the restrictions on looking at the code and then going off and
>completely rewritting it?
>What about just looking at the header files and supplied API documentation
>and none of the source code?

The problem is that should it ever come down to a lawsuit, it would be very 
hard for you to prove that you didn't just rewrite the code from memory. 
And if you read the original code, then you will find it hard to avoid 
thinking in the same lines (or at least I know I do) so there is a good 
possibility that sections of your code will closely resemble the original, 
even if there is no actual cut and paste at work.

It is much easier to cover your rear if you can point to a paper trail that 
says "The team that wrote our code have never been allowed to read the 
original code you claim we are infringing. Any similarities are 
coincidental and due entirely to the fact that we are writing an 
equivalently functional piece of software".

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] License restrictions

[Bart Veer]

>>>>> "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

Re: [ECOS] License restrictions

[Bart Veer]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> When it comes to Linux there are serious licensing problems. A
    >> typical existing Linux device driver will be licensed under the
    >> GPL. With eCos application code is linked directly to the
    >> kernel and hence to the device drivers, rather than being
    >> separated via a system call interface. Therefore all of the
    >> code in the system, including all of your application, needs to
    >> be under a license that is compatible with the GPL. Typically
    >> this means that you would have to release all of the
    >> application source code under an open source license. For most
    >> eCos developers that would be unacceptable.

    Andrew> This is probably a hard question to answer....

    Andrew> From what i understand, You can develop code for Linux and
    Andrew> not have to distribute the sources because libc is not
    Andrew> GPL, it uses some other licence. The application does not
    Andrew> directly call the GPL kernel.

Actually, applications can access the kernel directly without going
via glibc. For example the eCos synthetic target makes system calls
directly, not via glibc, but does not need to worry about GPL. See
below.

    Andrew> Now with eCos something similar is true. My application
    Andrew> code calls the eCos KAPI. This is covered by the eCos
    Andrew> licence. My application code does not directly call into
    Andrew> the device driver which could contain GPL code.

    Andrew> So, in terms of the licencing conditions, whats the
    Andrew> difference between a Linux system call interface and the
    Andrew> eCos function call interface?

Linking any application with GPL'd code creates a derived work under
the terms of the GPL. Therefore you must satisfy clause 2b of the GPL:

    "b) You must cause any work that you distribute or publish, that
    in whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License."

However, Linus Torvalds has added a special exemption to the GPL as it
applies to the Linux sources, see /usr/src/linux/COPYING:

   "NOTE! This copyright does *not* cover user programs that use
    kernel services by normal system calls - this is merely considered
    normal use of the kernel, and does *not* fall under the heading of
    "derived work". Also note that the GPL below is copyrighted by the
    Free Software Foundation, but the instance of code that it refers
    to (the Linux kernel) is copyrighted by me and others who actually
    wrote it.
			Linus Torvalds"

This means that application code can use Linux system calls without
having to worry about the GPL. The key issue is that Linux has a very
clearly defined set of system calls, i.e. the traps, so the above
exemption is unambiguous. For eCos this is not true: everything ends
up linked together in a single executable. Your application will not
just use the interface defined in <cyg/kernel/kapi.h>, it will
typically also use the C library package, the TCP/IP stack, etc. In
some cases it may in fact access device drivers directly, for example
if you develop a USB-based application for the SA1110 then your
application will need to reference variables specific to the device
driver such as usbs_sa11x0_ep0 during initialization.

I suppose that theoretically it is possible to claim that the eCos
kernel services are the sum of everything in the exported header
files, and hence are covered by the Linus Torvalds exemption. However
IMHO that is playing word games, and I do not think it matches either
the spirit or the legal letter of the GPL. I am afraid that you would
find little or no support for such a claim from anybody involved in
Linux kernel development, let alone from the FSF.

Bart

Re: [ECOS] License restrictions

[Andrew Lunn]

> When it comes to Linux there are serious licensing problems. A typical
> existing Linux device driver will be licensed under the GPL. With eCos
> application code is linked directly to the kernel and hence to the
> device drivers, rather than being separated via a system call
> interface. Therefore all of the code in the system, including all of
> your application, needs to be under a license that is compatible with
> the GPL. Typically this means that you would have to release all of
> the application source code under an open source license. For most
> eCos developers that would be unacceptable.

This is probably a hard question to answer....

From what i understand, You can develop code for Linux and not have to
distribute the sources because libc is not GPL, it uses some other
licence. The application does not directly call the GPL kernel.

Now with eCos something similar is true. My application code calls the
eCos KAPI. This is covered by the eCos licence. My application code
does not directly call into the device driver which could contain GPL
code. 

So, in terms of the licencing conditions, whats the difference between
a Linux system call interface and the eCos function call interface?

        Andrew