public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@eCosCentric.com>
To: eCos Maintainers <ecos-maintainers@sources.redhat.com>
Subject: Copyright resolution
Date: Fri, 21 Mar 2003 04:27:00 -0000	[thread overview]
Message-ID: <3E7A9442.8000607@eCosCentric.com> (raw)

The time has come to bring this to a conclusion. The beta is now out, and 
we want this to be resolved for 2.0 final.

I gave Red Hat repeated reminders and finally a deadline of last week to 
give a response to the mail I had sent (which you've all seen). But there 
was no answer.

At FOSDEM I talked to Martin Michlmayer about SPI and copyright 
assignments and stuff, and from that I found out that despite my very 
explicit statements in almost all my mails, it is almost certain they 
unfortunately didn't quite understand our proposal with licensing 
opt-outs. Martin's view from knowing the individuals on the SPI board (he 
doesn't speak for SPI so this *isn't* a definitive SPI response though) is 
that many of them would be deeply against such license opt-outs.

Add to that that SPI are only now even _considering_ how to deal with 
copyright assignments (although admittedly we were only proposing before 
them delegating the paperwork to us), and that their approach in general, 
while well-intentioned, is unfortunately.... er... amateurish, I don't 
believe any chance of license deals between Red Hat and SPI is plausible.

So as I see it, and from what y'all have already indicated preferences 
for, there are essentially two conclusions:

a) Create our own "eCos Foundation" whether not-for-profit or otherwise, 
and possibly then try to do a deal with Red Hat.;
or
b) Drop the copyright assignment requirement for patches entirely.

There are many advantages to a). Reducing the number of copyright holders 
to at most two means licence enforcement becomes easier, along with the 
possibility of deals resulting in potential improvements for the eCos 
community. Maintaining copyright assignments (and corporate disclaimers) 
also adds legal security against risks to the integrity of the IP, 
primarily whether someone was actually entitled to give us the code.

Against a) is the burden of doing copyright assignments, and that setting 
up and running such a foundation has adminstrative and bureaucratic 
overheads. But also key new factors to consider are that Red Hat have been 
unfortunately unresponsive at this stage, so how could we ever manage to 
do deals with potential "customers" in future, where negotiation time is 
limited if this would be standard practice? Also, from FOSDEM, although 
the audience wasn't very representative of wider industry, being 
intrinsically more free software oriented, no-one would foresee a great 
demand for the license opt-outs anyway - people seemed happy with the 
GPL+exception.

For b) is losing the burden of assignments, and the stalls for submissions 
it causes etc. Against b) is the risk of loss of IP integrity, increased 
difficulty of enforcement, and that this step is *irrevocable*. Once we go 
down this route we're stuck with the decision forever. And that includes 
keeping the existing GPL+exception forever, even if it is found down the 
road to be legally flawed.

It seems to me that the idea of license opt-outs etc. is dead, one way or 
the other. The only issue really to consider is the integrity of the IP, 
defending against potential lawsuits, patents (EU software patents are 
unfortunately probably round the corner :-( ), and enforcing the eCos 
licence among users. Some people hold up the Linux kernel as an example of 
how it can work; others hold up the Linux kernel as an accident waiting to 
happen, and with many grey areas just begging to be tried out in court 
such as whether the GPL affects modules, and Linus's unilateral change of 
the licence.

One great consideration the maintainers have to reflect on is that *we* 
can easily divest ourselves of troublesome patches if they turned out to 
have legal problems. However we have a responsibility to eCos users, and 
many of them may have used such patches in their products, and recalling a 
million MP3 players or something or pay royalties/face a lawsuit is not 
something we would ever want for users.

One of the big concerns I had was that it is standard operating practice 
for software companies to insist that they own everything their employees 
write. This would mean that the person contributing the code is _not_ the 
entity who owns it; which means that entity can later turn round and say 
"that's mine - remove it or face lawsuit, and if you've used it in 
products pay us royalties". This type of clause in employment contracts is 
so common it can't be ignored.

A compromise suggested in the maintainers meeting in Belgium was a sort of 
half way house... all contributors could electronically submit a form that 
explicitly says that they owned the code and they have checked their 
employment contract and their employer doesn't own it. If their employer 
does own their code, then they must send us (via some PO box we set up) 
the company disclaimer from http://sources.redhat.com/ecos/assign.html. So 
not the assignment itself, but the disclaimer that usually goes with it. 
This may well hit many people, but gives us a degree of legal safety. 
After all, if the contributor doesn't own the code, it would definitely be 
wrong to accept it.

Personally I don't think I could even _consider_ accepting option b) 
unless we added this policy (the corollary being that we would be prepared 
to accept code that inevitably sometimes must be owned by employers, not 
contributors). However, if such clauses in employment contracts are as 
pervasive as I think they may well be, one could easily argue that we may 
as well just keep the assignments.

So we need to get a conclusion. I've made a few assumptions above, but if 
anyone disagrees please do say. Similarly, if people think we should be 
considering other options, say so too.

I would like to hear from every maintainer in this thread. Unless we get 
complete consensus, I would suggest thrashing things out here a little, 
and then setting up a phone conference to reach the conclusion.

I won't say what my favoured personal preference is until tomorrow as I 
want to prevent this post appearing biased :-P.

What I would say is that if Red Hat presented the option of assigning all 
their copyright to a _single_ not-for-profit entity on a plate, I'd go for 
that. But that's safe to say since it isn't an option :-) :-(.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

             reply	other threads:[~2003-03-21  4:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-21  4:27 Jonathan Larmour [this message]
2003-03-21 18:56 ` Gary Thomas
2003-03-21 20:45   ` Jonathan Larmour
2003-03-21 22:28 ` Bart Veer
2003-03-26 15:15   ` Jonathan Larmour
2003-03-28 18:07     ` Nick Garnett
2003-03-25 16:37 ` John Dallaway
2003-03-25 16:41   ` Gary Thomas

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=3E7A9442.8000607@eCosCentric.com \
    --to=jifl@ecoscentric.com \
    --cc=ecos-maintainers@sources.redhat.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).