Ø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
