This is the mail archive of the ecos-maintainers@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: Future code ownership


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

    >> 3) A commercial entity interested in picking up the eCos "banner", such as 
    >> eCosCentric.

    Andrew> Does this mean eCosCentric is actually willing to do this?

    Andrew> Has Mind been approached? What is their opinion on this. 

In general, after the Cygnus/Red Hat situation I am now rather
sceptical about any commercial organization holding exclusive
copyright on an open source project. Companies merge, or get bought,
or change in other ways. Even if a company is currently committed to a
project such as eCos, there is no way of predicting the situation five
years from now.

For GPL'd code IP ownership only gives limited control. In particular
it is not possible to retroactively change the license on past
releases, and the code can be forked. However it is still possible to
damage the project by e.g. spreading FUD. I do not want a situation
where a company like WindRiver manages to buy all eCos IP and treats
it the way they have some of their other acquisitions.

Copyright assignment serves a number of purposes. One of these is
protecting the legal status of the whole code base by ensuring that
people only contribute code they are legally entitled to contribute.
That has some value in that there will be corporate legal departments
who worry about such details, but it will rarely be a decisive factor.
Another purpose is that it allows the IP owners to make license
changes to meet the needs of the community, if for example a court
decided that the GPL was not a valid software license. This is largely
covered already by the "or (at your option) any later version" clause
in the copyright banner.

There are disadvantages. In the past some contributions have had to be
rejected because we did not get an assignment, and there is no way of
knowing how many contributions were never submitted because the author
did not want the hassle of discussing the issue with management and
the legal department. This in turn may have forced some potential
users to choose a proprietary OS because eCos was not supported on a
given target or platform, or lacked some functionality that was never
contributed. Another disadvantage is the added bureaucracy.

That leaves alternative licensing: some companies are unhappy about
the obligations imposed by the current license (or the previous RHEPL)
and are willing to pay money for an exemption. The money itself is
useful, but in addition such companies have also funded various
valuable improvements to eCos. We risk losing out on such funding as
well - although quite possibly those companies would still have chosen
eCos even if no alternative license was available.

On the whole I think the pros and cons are finely balanced. Dropping
copyright assignments is fine with me. Assigning to SPI would also be
fine. I don't think the other options are viable.

However, that assumes that a deal is possible between Red Hat and SPI
on licensing exceptions. Without such a deal the balance shifts and
copyright assignments are no longer worthwhile. Based on the
experience of the past n months I think it unlikely that a reasonable
deal is possible, and I do not want much more time wasted on such
discussions.

So we should approach Red Hat management one last time, explaining the
possibility of the SPI scenario, proposing an outline deal, and asking
if they would be interested. There would have to be a time limit on
this, perhaps a month. If Red Hat agree then we can take the whole
proposal to SPI. If Red Hat fail to reply in time, or try to make
things horribly complicated again, then we give up on the whole idea
of license deals and we drop copyright assignments.

Note that we may still want to become an SPI project for other
reasons, e.g. as a way for the maintainers to get legal advice from
experts.

Bart


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