Re: [ECOS] APB - Copyright assignment

[Ãyvind Harboe <oyvind dot harboe at zylin dot com>]

On Wed, Oct 7, 2009 at 2:29 AM, Jonathan Larmour <jifl@jifvik.org> wrote:
> Ãyvind Harboe wrote:
>>>
>>> Actually, this case is a bit special. Graham Henderson modified files
>>> that are under eCos (FSF) copyright. I don't know what the legal
>>> status of the files is now, but they are covered by the GPL (with
>>> exceptions, as defined by eCos).
>>
>>
>> The legal status is that FSF *and* Graham has a copyright claim
>> to the files. The code was originally copyright to FSF and eCos
>> license. The fact that Graham has a copyright claim to it is unproblematic
>> for now.
>
> Actually, that's not true. Graham may not have been entitled to submit such
> changes. He may not own what he writes - it may well be that his employer
> does. His employer may include an assignment of intellectual property in his
> contract. In our line of work, and with the typical background of
> contributors, this sort of contractual stipulation is common (not universal
> I know).

So you're saying that someone can, mistakingly or otherwise, submit
a piece of code to an open source project and that that person, even
if we wrote it from scratch, was not at liberty to do so.

Copyright assignments are great, but opinions do differ on whether
GPL + exception alone gives sufficient protection or not. Risks are
everywhere when doing business.

I think it's good to have an enlightened discussion on this without contributing
to open source FUD. Given a choice, I use eCos code w/copyright
assignment, but otherwise GPL + exception and a reasonable confidence
in that the original author was in his right to contribute the code suffices.
Especially for smaller changes.

It's great that the eCos CVS repository has everything thoroughly
straighted out here.

I think 5% of the code in Linux is from anonymous donors, i.e. anonymous
copyright holders. The Linux crowd and eCos obviously have *very* different
views on the risks here. Clearly the Linux crowd *knows* that heavy hitters
will go after the ilk of SCO. Linux is "too big to fail" :-)

eCos is not as fortunate and must look after itself.

I don't want to belittle Graham's work, but he had tinkered with the
TSE driver, abandoned it and then we made it work. Redoing the TSE driver
or omitting it from nios2ecos is not a big deal, but since I believe the
specific risk here is very slight, I'm more inclined to just wait.

> If he comes out of the woodwork, that would definitely be best. Perhaps you
> could search the niosforum for a new email address?
>
> I don't know if this may be able to lead to anything useful:
> http://www.latticesemi.com/forums/forum/messageview.cfm?catid=523&threadid=5302&enterthread=y

Same email address.

Would it be an idea to have a "missing persons" page on eCos?

> AIUI (although I haven't touched nios stuff before thank goodness),
> versioning would certainly be an issue with Quartus as IIRC they changed
> hardware configuration formats frequently between versions. Although I guess
> that as long as a currently supported and available version is used, that
> may be ok.

That's pretty much fixed now with the nios2ecos approach. If some new
scheme should surface eventually, then we can deal with it at that point.

nios2ecos works w/quartus 9 and probably as far back as 7 at least(which
is probably as far back as anyone is likely to need to go...).

Since we use scripts from quartus, we should be a bit more resilient against
version changes than if we parsed the ptf ourselves.



-- 
Ãyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

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