public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: "Øyvind Harboe" <oyvind.harboe@zylin.com>
Cc: Edgar Grimberg <edgar.grimberg@zylin.com>,
	   Alex Schuilenburg <alexs@ecoscentric.com>,
	   eCos Disuss <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] APB - Copyright assignment
Date: Wed, 07 Oct 2009 00:29:00 -0000	[thread overview]
Message-ID: <4ACBE0D6.6010601@jifvik.org> (raw)
In-Reply-To: <c09652430910060826u1dbb0c4cj43434107ccae1cfd@mail.gmail.com>

Ø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).

This is why the copyright assignment is quite important for eCos - not so 
much for the assignment itself, but for the accompanying company 
disclaimer. The fact that the code was published under the eCos GPL is 
irrelevant - if it wasn't his code to publish, then theoretically the 
employer can pursue both the FSF and eCos users who possess the driver. 
Even worse if they have deployed it in a product.

The fact the modifications took place in a GPL'd file does not, 
unfortunately help. In a hypothetical situation, imagine I stole some code 
from a company and posted it on the net, with the GPL licence on, or even 
added on to an existing GPL'd file. The company has not lost its rights to 
stop (or charge) users using that code because of the actions of someone 
who was not entitled to post it in the first place.

It's possible there could be some sort of extenuating circumstances where 
we may be able to be more flexible, but without even being able to contact 
him, I for one wouldn't be happy.

We have been more flexible when it's part of an established GPL-licence 
compatible open source project. There are still risks though, and for that 
matter we have some existing resulting problems there already, such as 
non-UCB BSD advertising clauses in the BSD stacks. It's not a route to 
indulge in.

> If in the future FSF wants to tinker with the eCos license, then the TSE
> becomes a problem, because without Graham's consent(or copyright
> assignment), the licensing for his changes can't be changed.

That's correct.

>>Of course, the best solution is for me to delete the files that were
>>touched by Graham Henderson and rewrite them. This just got high on my
>>priority list.
> 
> 
> Since the current situation is unproblematic, we can just wait to
> see if Graham comes out of the woodwork...

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

> (The biggest problem with nios2ecos, IMHO, is that quartus
> must be installed to build. This makes it impossible e.g. to put
> build tool binaries under version control... I'm not 100% convinced
> that uClinux required quartus installed to build...)

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.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- 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

  reply	other threads:[~2009-10-07  0:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06  9:17 Øyvind Harboe
2009-10-06 13:34 ` Alex Schuilenburg
2009-10-06 14:31   ` Øyvind Harboe
2009-10-06 15:06     ` Alex Schuilenburg
2009-10-06 15:19       ` Øyvind Harboe
2009-10-06 16:04         ` Alex Schuilenburg
2009-10-06 14:37   ` Edgar Grimberg
2009-10-06 15:12     ` Alex Schuilenburg
2009-10-06 15:26     ` Øyvind Harboe
2009-10-07  0:29       ` Jonathan Larmour [this message]
2009-10-07  5:31         ` Øyvind Harboe
2009-10-07 14:34           ` [ECOS] " Grant Edwards
2009-10-07 16:31             ` Paul D. DeRocco
2009-10-07 18:30               ` Grant Edwards
2009-10-07 23:10           ` [ECOS] " Alex Schuilenburg
2009-10-08  0:31             ` Paul D. DeRocco
2009-10-08 13:20               ` Alex Schuilenburg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACBE0D6.6010601@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=alexs@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=edgar.grimberg@zylin.com \
    --cc=oyvind.harboe@zylin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).