Re: [ECOS] Licensing of OpenSource code and eCos

[Peter Vandenabeele <peter dot vandenabeele at mind dot be>]

On Fri, Sep 27, 2002 at 01:51:19AM +0200, Iztok Zupet wrote:
> On Thu, 2002-09-26 at 22:36, Peter Vandenabeele wrote:
> > The philosophy of FSF is different and very precise on this matter. You 
> > can read the motivation of the FSF on this page:
> >   http://www.gnu.org/philosophy/why-not-lgpl.html
> > This discussion on LGPL defines exactly why FSF strongly prefers to use 
> > GPL as much as possible and avoid an LGPL (and for that matter ECOS-style)
> > license when possible. This is a deliberate, political choice for "Freedom" 
> > as defined by FSF.
> 
> That is true for Linux. The applications there are run as processes and
> drivers can be loaded as modules. This scheme allows for proprietary
> applications and drivers.

The ECOS 2.0 license also allows for proprietary applications, linked with 
eCos as a library. This is exactly the point of the modifications of the 
ECOS 2.0 license with respect to GPL: of cleary defining and limiting the
scope of Copyleft. A universal advantage of the _clear definition_, is that 
it avoids some potential discussions over the "whole work" concept as 
worded in the GPL. The mention to not being allowed to link from a non-GPL
work to a GPL library is only mentioned as a comment on the end, that points
to the LGPL license that could be used if that is your intention. The base
concept that is named in article 2 of GPL 2.0 is much more general in the 
sense that, if some part of the "whole work" was received under a GPL 
license, the whole work can only redistributed as GPL.

>From the GPL 2.0 license:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work based
  on the Program, the distribution of the whole must be on the terms of
  this License, whose permissions for other licensees extend to the
  entire whole, and thus to each and every part regardless of who wrote 
  it.

The _limitation_ of the scope of Copyleft in the ECOS 2.0 license to not 
include others works through linking, is not a general advantage, but 
a deliberate "political" choice, to allow practical commercial use of eCos. 
Some people will be in favor, others will object it, based on political 
views of how "Free Software" should be promoted best. My personal view 
(for what its worth), is that in this context of embedded systems, the 
ECOS 2.0 license makes a lot of sense.

May I conclude from the exact text of the ECOS 2.0 license that prorietary
drivers that are in a separate source tree file, would be allowed by the
ECOS 2.0 license ?

> To achieve that "freedom" with the eCos as an OS, perhaps we need:
> 
> 1. a system/user space program loader with memory protection support
> 2. a funny OS interrupt/exception
> 3. a driver module loader/unloader
> 
> Only then it could be fully GPL-ed.
> 
> Otherwise, the eCos can still follow the common practice, that is being
> available under two licenses one fully GPL-ed and the other fully
> commercial.

I think that for a project that has already reached a critical mass, such 
as eCos, the ECOS 2.0 license is much better than the dual license concept.
I would strongly argue against any change to the license on eCos. I explained 
before why I have an issue with the mandatory Copyright Assignment practice, 
but that is a completely different aspect of it.

Peter

> iz

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