This is the mail archive of the ecos-discuss@sourceware.org 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: Are copyright assignments detrimental to eCos?


Øyvind Harboe wrote:
> I believe that a sluggish patch + commit process is detrimental to eCos.

Contributors need to make assignments just one time. Other projects are
plenty busy enough with their regular contributors. We don't seem to have
quite as many that stick around, but that's not the fault of the process.

> Clearly copyright assignments slow things down.
> 
> Why copyright assignments at this point?
> 
> Is it an anachronism?

Legal protection. Probably most embedded engineers have contracts that lay
down that work done by them is owned by their employer - certainly during
company time, and often outside company time too. This is more true for the
embedded space than most others because there are comparatively few
hobbyists compared to other projects - for us, the vast majority of
users/developers will be using it as part of their work.

Therefore in most cases, it is not the employee's choice whether to
contribute something - they don't own it to begin with. Many OSS projects
are treading on thin legal ice because they are accepting stuff
willy-nilly. They could have problems if just one employer turns round and
says "Hey, that's our code!". If you're lucky you can get away with
removing the code, rather than having to pay damages, although the latter
is a legal option.

For us in the embedded world, the consequences are a thousand times worse -
deployed embedded devices in the field using eCos would have to be
recalled. (For example, every Playstation 3).

A company could use this to effectively extort money. The IBM vs. SCO case
affecting Linux shows what could happen with uncertain ownership, and SCO
was very clear that they were going to charge. Luckily it worked out for
everyone. This time. People have said many times that the lack of clear
code ownership in Linux is a time-bomb.

Single ownership also sorts out GPL license enforcement. Breaking the
license on a large amount of eCos code is easy to enforce; but how about
when someone copies just bits and pieces. Functions here and there, but
breaks the GPL and doesn't distribute source. You need to be able to know
who specifically owns the copyright to those *specific* pieces of code, and
it is the authors of that code, and no-one else, who have to enforce the
license. No-one else can do it on their behalf. The FSF will of course
happily enforce the GPL for us.

> Why should *all* of eCos require copyright assignments?

All contributions at any rate.

> What about other projects imported to eCos? Do they too have copyright
> assignments in order? jffs2? zlib?

We relax it for self-contained established open source projects - in that
case it's a port of the code we're really trying to deal with, not the code
itself. It's not up to us to enforce their assignment rules. Sure, it's not
desirable, but we're forced into a corner. We certainly shouldn't make it
worse. It would be better if we had clearer explanations of licensing and
copyright affecting code. eCosCentric has been approached before to develop
a licensing management tool, but it hasn't happened yet.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

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


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