public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* Copyright resolution
@ 2003-03-21  4:27 Jonathan Larmour
  2003-03-21 18:56 ` Gary Thomas
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jonathan Larmour @ 2003-03-21  4:27 UTC (permalink / raw)
  To: eCos Maintainers

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-21  4:27 Copyright resolution Jonathan Larmour
@ 2003-03-21 18:56 ` Gary Thomas
  2003-03-21 20:45   ` Jonathan Larmour
  2003-03-21 22:28 ` Bart Veer
  2003-03-25 16:37 ` John Dallaway
  2 siblings, 1 reply; 8+ messages in thread
From: Gary Thomas @ 2003-03-21 18:56 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: eCos Maintainers

On Thu, 2003-03-20 at 21:25, Jonathan Larmour wrote:
> 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.;

I'm in favor of this, but it must be seen as vendor neutral, i.e. not
favoring any commercial participant (eCosCentric or MLB or Mind or ...)

> or
> b) Drop the copyright assignment requirement for patches entirely.
> 

I see this as a last resort because it basically can turn things into
a free-for-all.

 <snip>

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

By "tomorrow", I assume that you mean Friday, March 21?

I'm ready to discuss this at length whenever y'all are.  I note that 
it's been 15 hours since Jonathan sent this, and AFAICT this is the
only response so far.

> 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 :-) :-(.

Yup, pretty safe.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-21 18:56 ` Gary Thomas
@ 2003-03-21 20:45   ` Jonathan Larmour
  0 siblings, 0 replies; 8+ messages in thread
From: Jonathan Larmour @ 2003-03-21 20:45 UTC (permalink / raw)
  To: Gary Thomas; +Cc: eCos Maintainers

Gary Thomas wrote:
> On Thu, 2003-03-20 at 21:25, Jonathan Larmour wrote:
>>
>>a) Create our own "eCos Foundation" whether not-for-profit or otherwise, 
>>and possibly then try to do a deal with Red Hat.;
> 
> I'm in favor of this, but it must be seen as vendor neutral, i.e. not
> favoring any commercial participant (eCosCentric or MLB or Mind or ...)

We can thrash out the details to ensure this, but to be honest, with 
licensing deals off the table it won't be that relevant... it will just be 
a repository for IP.

There are some other considerations with this one: if we want to make it a 
proper not-for-profit company we may have some difficulties with setting 
it up. Also NFP companies require approval I believe, which can take many 
months.

Finally, we may well require a lawyer to set up the appropriate articles 
of association or whatever since our situation won't be appropriate for 
something "off the shelf".

These aspects highlight one issue: this will take money to set up.

One disadvantage I omitted to mention is that some companies are reluctant 
to make assignments, or may even object outright. There's one big one 
(starts with 'I' :-)) that I know falls into the latter category.

One other option I didn't consider till now is the FSF. With the licensing 
suggestion gone, we don't have the same impediments. Perhaps we should 
consider approaching them after all. Would they take us under their wing 
even if we had dual copyright with Red Hat? Would we _want_ to be an FSF 
project with the potential influence from above that that may entail?

[snip]
>>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.
> 
> By "tomorrow", I assume that you mean Friday, March 21?

I just meant I'd send my views then, not a phone conference. We'll need 
more notice to be sure of getting everyone for that.

> I'm ready to discuss this at length whenever y'all are.  I note that 
> it's been 15 hours since Jonathan sent this, and AFAICT this is the
> only response so far.

I know Bart's opinion from IRC, but I'll let him speak for himself.

For me, I have a pretty clear view of the advantages and disadvantages 
both ways, but that doesn't make it a clear-cut answer :-). I think on the 
whole I'm for keeping assignments to a single entity, not least because I 
don't think we can accept contributions without the "company disclaimer" 
document thingy mentioned before, and frankly I think most developers will 
have that type of contract.... at which point we may as well just continue 
with assignments as the _extra_ bureaucratic hurdle is minimal (with the 
exception of companies beginning with "I" :-)).

I'm still not decided on the details of that. I'd be interested in other's 
views on the FSF, but I'm certainly wary of the financial and bureaucratic 
obligations of doing our own. It may be easier and/or cheaper to set up in 
the UK rather than the US (thinking of lawyer's fees as well here). It 
probably _wouldn't_ need to be explicitly not-for-profit, with the extra 
burdens that has, as we can enshrine something good enough in the articles 
of association and the entity wouldn't be handling money.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-21  4:27 Copyright resolution Jonathan Larmour
  2003-03-21 18:56 ` Gary Thomas
@ 2003-03-21 22:28 ` Bart Veer
  2003-03-26 15:15   ` Jonathan Larmour
  2003-03-25 16:37 ` John Dallaway
  2 siblings, 1 reply; 8+ messages in thread
From: Bart Veer @ 2003-03-21 22:28 UTC (permalink / raw)
  To: jifl; +Cc: ecos-maintainers

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

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

    <snip>

My preference is for option (b), dropping copyright assignments
completely. I am neutral on the need for some sort of disclaimer form.
A couple of points:

  1) re. legal flaws in the license, we have a certain amount of
     protection via "(at your option) any later version." Any problem
     with the license text is likely to be with the GPL as a whole
     rather than with the exception, so would be a resolved by a GPL
     V3. This is not a panacea, it does not handle the case where the
     current license proves to be less restrictive than what we
     actually want. We may also have the possibility of adding new
     files to the system with a better license and adjust the rest of
     the system such that those new files become critical to eCos
     generally - e.g. a new HAL macro of some sort.

  2) software patents are a high risk irrespective of whether or not
     we do assignments. We may be infringing any number of existing
     software patents already, patents developed independently of
     eCos, and that may well be a larger risk than anything IP
     related.

The problem with setting up an eCos foundation is the effort involved,
both initially and long term. I believe that the time would be better
spent hacking code. We would also need to worry about the running
costs - without licenses there is no obvious revenue source other than
corporate sponsorship. I don't object strongly to setting up such a
foundation, but I don't think the gains are worth the effort involved.

The FSF route is worth exploring further, they already have all the
bureaucracy in place. I like the idea of eCos becoming the GNU
embedded OS. One possible stumbling block is the exception to the GPL,
we would have to make sure that the FSF is happy to preserve this
exception on code it would own. Another possible problem is policy
decisions, for example the recent discussion about whether vhdl output
files should be treated as data or as object files. Such issues would
have to be passed up the hierarchy and we might not like the results.

Bart

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-21  4:27 Copyright resolution Jonathan Larmour
  2003-03-21 18:56 ` Gary Thomas
  2003-03-21 22:28 ` Bart Veer
@ 2003-03-25 16:37 ` John Dallaway
  2003-03-25 16:41   ` Gary Thomas
  2 siblings, 1 reply; 8+ messages in thread
From: John Dallaway @ 2003-03-25 16:37 UTC (permalink / raw)
  To: ecos-maintainers

Jonathan Larmour wrote:

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

I don't see option (a) as realistic unless someone is prepared to pay the 
legal fees or we can find sponsorship. These fees are likely to be 
considerable given the unusual nature of the proposed foundation.

I think option (b) is the most realistic way forward and agree with Jifl 
that this should definitely be accompanied by a company disclaimer process. 
In fact, we should maintain a database detailing all code contributions, 
company names, contact details, etc.

John Dallaway

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-25 16:37 ` John Dallaway
@ 2003-03-25 16:41   ` Gary Thomas
  0 siblings, 0 replies; 8+ messages in thread
From: Gary Thomas @ 2003-03-25 16:41 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Maintainers

On Tue, 2003-03-25 at 09:38, John Dallaway wrote:
> Jonathan Larmour wrote:
> 
> > 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.
> 
> I don't see option (a) as realistic unless someone is prepared to pay the 
> legal fees or we can find sponsorship. These fees are likely to be 
> considerable given the unusual nature of the proposed foundation.
> 
> I think option (b) is the most realistic way forward and agree with Jifl 
> that this should definitely be accompanied by a company disclaimer process. 
> In fact, we should maintain a database detailing all code contributions, 
> company names, contact details, etc.

After more thought, I tend to agree, although I would like to
explore the FSF option (which could go hand-in-hand with this 
change).

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-21 22:28 ` Bart Veer
@ 2003-03-26 15:15   ` Jonathan Larmour
  2003-03-28 18:07     ` Nick Garnett
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Larmour @ 2003-03-26 15:15 UTC (permalink / raw)
  To: ecos-maintainers

Bart Veer wrote:
[snip]

Although we haven't yet heard from Nick or Mark yet, there does seem to be 
a feeling that we should approach the FSF, from myself, Bart, Gary and 
Andrew at least.

I will do so tentatively now then, although Nick's and Mark's thoughts are 
still relevant.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Copyright resolution
  2003-03-26 15:15   ` Jonathan Larmour
@ 2003-03-28 18:07     ` Nick Garnett
  0 siblings, 0 replies; 8+ messages in thread
From: Nick Garnett @ 2003-03-28 18:07 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Bart Veer wrote:
> [snip]
> 
> Although we haven't yet heard from Nick or Mark yet, there does seem
> to be a feeling that we should approach the FSF, from myself, Bart,
> Gary and Andrew at least.
> 
> I will do so tentatively now then, although Nick's and Mark's thoughts
> are still relevant.
> 

My thoughts are that it is probably too difficult and too expensive to
set up a non-profit organization of our own. Approaching the FSF seems
like a good thing to try. My only reservation is that this will put
more delay into the resolution of this issue, and we really need to
get this sorted sooner rather than later.

If the FSF route doesn't work, then we should take Plan B. In that
case we must also be more careful about what we accept and police
checkins very thoroughly.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2003-03-28 18:07 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-21  4:27 Copyright resolution Jonathan Larmour
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

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