This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PPP status?


>>>>> "Gustav" writes:

    >> > Porting GPL'd code to eCos would violate the GPL license or
    >> > require eCos to be GPL'd as well. E.g. the Kaffe port to eCos
    >> > can not be considered to be legal.
    >> 
    >> IANAL, but why couldn't GPL'd source code be ported to eCos
    >> without violating the license? The GPL doesn't prohibit
    >> modifications, it only controls how those modifications are
    >> distributed. Porting GPL'd code to eCos then distributing it
    >> seperately from eCos as source code shouldn't be a problem,
    >> should it?

    Gustav> The GPL'd code "infects" the non-GPL'd code as soon as
    Gustav> it's linked to it. That is very hard to avoid in an
    Gustav> embedded system such as eCos.

    Gustav> There is one exception and that is the GPL lib license
    Gustav> which is used for libc which allows you to link the lib to
    Gustav> another code without infecting. But that is not the case
    Gustav> here.

IANAL either, but hopefully I can clear up some of the confusion here.

It is not entirely correct that use of GPL'd code "infects" all
non-GPL'd code it is linked with, requiring all such code to be GPL'd
as well. As an example consider Gnome. A typical gnome application
will be GPL'd. However it will be linked with X11 libraries which are
not GPL'd, instead they are under a BSD-style license. This is
perfectly legal, because the relevant license is GPL-compatible: the
X11 code is freely available and anybody can modify it as desired.

Now consider a typical embedded application. In a simple case this
involves linking together some application code, some eCos code, and
the compiler support library libgcc. libgcc is licensed under the GPL
plus an exception, which means that for all practical purposes anybody
can just use libgcc without worrying about licensing issues. eCos is
now licensed under GPL plus a different exception. Neither eCos nor
libgcc "infect" the application code, so that code can be kept
proprietary/secret if desired.

Next suppose an embedded developer also wants to use an additional
library, e.g. PPP code or Kaffe, that is only available under vanilla
GPL with no exceptions. There are now four bits of code in the system:
application, PPP, eCos and libgcc. Both eCos and libgcc are under a
license that is GPL-compatible, so there is no conflict there. The
application code must also be released under a GPL-compatible license.
The basic requirement is that any end user must be able to examine and
modify all code that goes into the final executable, so that bugs can
be fixed and functionality can be improved. Usually the simplest way
to achieve this is to release the application code under the GPL as
well, so in this scenario "infection" does occur. It would also be
possible to e.g. release the application code under a BSD license or
make it public domain.

The RHEPL had been ruled incompatible with the GPL. Therefore it was
impossible to combine eCos code with GPL'd code and distribute the
resulting application. The eCos license change makes it possible to
use GPL'd code if desired, for those application developers willing to
release their own code. This gives developers more choice than before.

However it is accepted that most embedded application developers will
want to keep much of their own code proprietary. If we were to
incorporate vanilla GPL code into the main eCos repository, there
would be a real risk that some application developers would
accidentally use that code without understanding the implications of
what they were doing. Keeping such code out of the repository greatly
reduces the risk of such accidents: instead of just adding another
package via the config tool or the ecosconfig command line, they would
have to download a separate file, unpack it, figure out how to build
it, link it with the application as a separate library, etc. Mistakes
may still happen, but cannot be blamed on eCos and its configuration
technology.

There are other and less stringent approaches, e.g. having the tools
display a big warning and require user confirmation when a GPL'd
package is added to the configuration. The code for that does not
exist yet, so IMO a ban on GPL'd code in the repository is the right
thing for now.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]