Future code ownership

Future code ownership

[Jonathan Larmour]

I think it's crunch time. We've been hmmming and hahing and we have to 
bite the bullet. We've been having discussions in the background with 
various people (you can probably guess), but with just one exception (see 
below) these have now come to nought. We must go it alone.

Us maintainers have to make a collective decision as to the future of eCos 
copyright assignments. Some people, including certainly a number of us 
maintainers, are unhappy with continuing with Red Hat as the holder for 
future assignments. Obviously nothing can change with the existing 
copyright - that's Red Hat's. But if we opted for a new additional 
copyright holder, we would no longer need to worry about the owner being 
someone who no longer has eCos's interests at heart.[1]

Some of us maintainers that have checked in code and disliked the RH 
aspect have checked in code with our own personal copyright. As 
maintainers that's not unreasonable, but it was done because of the 
informal agreement we made that we would assign it to the future copyright 
holder. But needless to say, we all therefore agree to assign to whoever 
we collectively decide. And to be clear, these are the people I definitely 
want buy-in from: Gary, Nick, Bart, Mark and Andrew, as well as myself of 
course, although other readers here are free to contribute. I would like 
to get a broad consensus if at all possible. We're not in a situation to 
deal with "votes", although if push comes to shove I suppose I'll have to 
act as a final arbiter in the case of an even split of opinion. Let's hope 
it doesn't happen :-).

What factors are needed in consideration of the best option: acceptability 
to the community; support by the future owner (if any) for eCos's Open 
Source interests; a "safe pair of hands" for any future owner; future 
viability of the owner; and potentially, the possibility of making eCos 
more acceptable to commercial companies by allowing licensing exceptions.

The latter option is contentious but I believe necessary and valuable. We 
want eCos to be as pervasive as possible, and there are a number of 
companies out there for home Open Source will _never_ be acceptable. We 
think it's dumb, and we can argue quite sensibly and logically why they 
are dumb and how they can make the burdens less onerous, but sometimes it 
just isn't possible. Trust me, companies, and especially large ones, can 
be this short-sighted.

But we can give them an option: a solution is to allow licence opt-outs, 
like Red Hat had been able to do by themselves up to earlier this year 
(but not after personal copyright from the maintainers got added of 
course). This would set us at a par with commercial OS vendors. But we 
can't compromise our integrity without a considerable pound of flesh. So 
we charge. The figures would probably depend per deal, but it could well 
be in the order of thousands of dollars. Maybe. Don't know. Haven't tried 
it :-). Unfortunately that money would have to be split with Red Hat, a 
commercial entity, but as Red Hat's role in eCos diminishes, so too is 
their leverage. It would be the eCos team driving such deals, not them.

What would happen to this money? It would absolutely be the case that such 
money must be put towards furthering the interests of eCos, the Open 
Source project. (Not giving the contributors/maintainers a salary - sorry 
guys ;-)). Whether it be test equipment, or funding important software 
development that may not happen any other way, it would be useful and IMHO 
is worth the effort.

So what are the options for the future:

1) No copyright assignments at all. This is like the Linux kernel. The 
admin overhead is reduced, as well as the hassle factor for contributors. 
However the ownership of the code is called into question, and there is a 
risk that code that is contributed may not be the copyright owners - think 
of the corporate disclaimer thing we have. Certainly the FSF are against 
it for these types of reasons, and they are the acknowledged experts in 
this field. Once this decision is made it can never be revoked. Definitely 
no potential licence revenue.

I personally do not favour this route at all.

2) Continuing with Red Hat. Some people disagree for the reasons stated 
before, and on ecos-discuss.

3) A commercial entity interested in picking up the eCos "banner", such as 
eCosCentric.

4) The FSF. I know I'm not alone in thinking the FSF can be too rabid 
sometimes, and sometimes there is too much personal intervention from the 
top. While an obvious candidate I don't see it being relevant, and we 
wouldn't really be a good fit into the GNU project anyway. Definitely no 
licence revenue option either.

5) A new not-for-profit organisation, e.g. "the eCos foundation". There is 
considerable difficulty for non-USers to set this up, and the process can 
take upwards of 6 months I believe. There may also be tedious obligations 
and overhead like accounts, board meetings, blah blah. Plus without any 
experience we may need lawyers, and therefore fees, etc. as well as any 
other charges for setting it up.

6) Software in the Public Interest, Inc. is a US not-for-profit 
organisation. <http://www.spi-inc.org/> Its goals are to advance open 
source. They are well known already as the copyright holders of many well 
known projects like Debian Linux, GNOME, LSB as well as owners of the Open 
Source marque, and so on. They are trusted.  We have already taken the 
step of asking them in principle if they could accept eCos as a project, 
even with our funky licensing proposal outlined above. And as you can see 
from 
<http://www.spi-inc.org/corporate/resolutions/resolution-2002-10-08.mgs> 
this was accepted.

Personally I favour this option. I think it is best for eCos as an Open 
Source project, and I would like to hope even Red Hat would be able to 
support it, as it would be in the long-term best interests of eCos. 
Besides if the licensing proposal does pay off, they would profit!

Note: I have no intention of forcing people with an existing Red Hat 
assignment to change. That's up to them, and I don't think it makes 
significant difference since Red Hat's copyright on a lot of the code is 
here to stay. However, I think it is in the best interests of the Open 
Source project for any significant contributions to be "moved" to the new 
system, and certainly this would become the requirement for new assignments.

Let the discussion commence. Please all do state your opinion, and also 
please do remember that as with FSF projects, the maintainer's role is a 
personal one, and people are here in their personal capacity, not in their 
roles as employees of particular companies.

Jifl
[1] If that were true the eCos team would still be in Red Hat wouldn't it :-).
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Andrew Lunn]

> Note: I have no intention of forcing people with an existing Red Hat 
> assignment to change. That's up to them, and I don't think it makes 
> significant difference since Red Hat's copyright on a lot of the code is 
> here to stay. However, I think it is in the best interests of the Open 
> Source project for any significant contributions to be "moved" to the new 
> system, and certainly this would become the requirement for new assignments.

How does this 'move' work in practice? Do we change the copywrite
headers on the source or does it keep the modified GPL?

Can existing code, which i contributed in the past, like say the DNS &
FTP client etc, be moved?

    Andrew

Re: Future code ownership

[Jonathan Larmour]

Andrew Lunn wrote:
>>Note: I have no intention of forcing people with an existing Red Hat 
>>assignment to change. That's up to them, and I don't think it makes 
>>significant difference since Red Hat's copyright on a lot of the code is 
>>here to stay. However, I think it is in the best interests of the Open 
>>Source project for any significant contributions to be "moved" to the new 
>>system, and certainly this would become the requirement for new assignments.
> 
> 
> How does this 'move' work in practice? Do we change the copywrite
> headers on the source or does it keep the modified GPL?

We change the assignment proforma and tell people to use the new 
assignment forms. We maintainers would probably switch to the new 
assignment immediately (probably by informing Red Hat the previous 
assignment is now cancelled), but as I said, I don't want to force anyone 
with an existing Red Hat assignment to sign a new one if they don't want 
to. Anyone with an existing RH assignment can and should be allowed to 
continue contributing on that basis if they want, with their code then 
becoming (C) Red Hat.

> Can existing code, which i contributed in the past, like say the DNS &
> FTP client etc, be moved?

Only if it wasn't already assigned to Red Hat. So in those specific cases, no.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Andrew Lunn]

> 3) A commercial entity interested in picking up the eCos "banner", such as 
> eCosCentric.

Does this mean eCosCentric is actually willing to do this?

Has Mind been approached? What is their opinion on this. 

    Andrew

Re: Future code ownership

[Bart Veer]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> 3) A commercial entity interested in picking up the eCos "banner", such as 
    >> eCosCentric.

    Andrew> Does this mean eCosCentric is actually willing to do this?

    Andrew> Has Mind been approached? What is their opinion on this. 

In general, after the Cygnus/Red Hat situation I am now rather
sceptical about any commercial organization holding exclusive
copyright on an open source project. Companies merge, or get bought,
or change in other ways. Even if a company is currently committed to a
project such as eCos, there is no way of predicting the situation five
years from now.

For GPL'd code IP ownership only gives limited control. In particular
it is not possible to retroactively change the license on past
releases, and the code can be forked. However it is still possible to
damage the project by e.g. spreading FUD. I do not want a situation
where a company like WindRiver manages to buy all eCos IP and treats
it the way they have some of their other acquisitions.

Copyright assignment serves a number of purposes. One of these is
protecting the legal status of the whole code base by ensuring that
people only contribute code they are legally entitled to contribute.
That has some value in that there will be corporate legal departments
who worry about such details, but it will rarely be a decisive factor.
Another purpose is that it allows the IP owners to make license
changes to meet the needs of the community, if for example a court
decided that the GPL was not a valid software license. This is largely
covered already by the "or (at your option) any later version" clause
in the copyright banner.

There are disadvantages. In the past some contributions have had to be
rejected because we did not get an assignment, and there is no way of
knowing how many contributions were never submitted because the author
did not want the hassle of discussing the issue with management and
the legal department. This in turn may have forced some potential
users to choose a proprietary OS because eCos was not supported on a
given target or platform, or lacked some functionality that was never
contributed. Another disadvantage is the added bureaucracy.

That leaves alternative licensing: some companies are unhappy about
the obligations imposed by the current license (or the previous RHEPL)
and are willing to pay money for an exemption. The money itself is
useful, but in addition such companies have also funded various
valuable improvements to eCos. We risk losing out on such funding as
well - although quite possibly those companies would still have chosen
eCos even if no alternative license was available.

On the whole I think the pros and cons are finely balanced. Dropping
copyright assignments is fine with me. Assigning to SPI would also be
fine. I don't think the other options are viable.

However, that assumes that a deal is possible between Red Hat and SPI
on licensing exceptions. Without such a deal the balance shifts and
copyright assignments are no longer worthwhile. Based on the
experience of the past n months I think it unlikely that a reasonable
deal is possible, and I do not want much more time wasted on such
discussions.

So we should approach Red Hat management one last time, explaining the
possibility of the SPI scenario, proposing an outline deal, and asking
if they would be interested. There would have to be a time limit on
this, perhaps a month. If Red Hat agree then we can take the whole
proposal to SPI. If Red Hat fail to reply in time, or try to make
things horribly complicated again, then we give up on the whole idea
of license deals and we drop copyright assignments.

Note that we may still want to become an SPI project for other
reasons, e.g. as a way for the maintainers to get legal advice from
experts.

Bart

Re: Future code ownership

[Andrew Lunn]

> So we should approach Red Hat management one last time, explaining the
> possibility of the SPI scenario, proposing an outline deal, and asking
> if they would be interested. There would have to be a time limit on
> this, perhaps a month. If Red Hat agree then we can take the whole
> proposal to SPI. If Red Hat fail to reply in time, or try to make
> things horribly complicated again, then we give up on the whole idea
> of license deals and we drop copyright assignments.

This sounds like a reasonable way to go.

     Andrew

Re: Future code ownership

[Jonathan Larmour]

Bart Veer wrote:
> 
> So we should approach Red Hat management one last time, explaining the
> possibility of the SPI scenario, proposing an outline deal, and asking
> if they would be interested. There would have to be a time limit on
> this, perhaps a month. If Red Hat agree then we can take the whole
> proposal to SPI. If Red Hat fail to reply in time, or try to make
> things horribly complicated again, then we give up on the whole idea
> of license deals and we drop copyright assignments.

Well, now that Mark is on the list (he wasn't before, oops!) perhaps this 
would be best coming from him? We know from personal experience how 
difficult it can be getting replies to "outsider's" mails.

I'll give him a chance to read this thread in the archives though :).

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Jonathan Larmour]

Andrew Lunn wrote:
>>3) A commercial entity interested in picking up the eCos "banner", such as 
>>eCosCentric.
> 
> Does this mean eCosCentric is actually willing to do this?

Only willing if that's what the maintainers want. I'm wearing a very 
different hat in eCosCentric and as a maintainer. I want to do what's best 
for eCos, even if it conflicts with what eCosCentric wants. To be honest, 
I don't think it's very likely we'll choose this option - I just threw it 
in there for completeness, but tell me if I'm wrong!

> Has Mind been approached? What is their opinion on this. 

Dunno. Gary might have the best take on that if they don't speak up 
themselves.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Gary Thomas]

On Tue, 2002-12-17 at 20:53, Jonathan Larmour wrote:
> Andrew Lunn wrote:
> >>3) A commercial entity interested in picking up the eCos "banner", such as 
> >>eCosCentric.
> > 
> > Does this mean eCosCentric is actually willing to do this?
> 
> Only willing if that's what the maintainers want. I'm wearing a very 
> different hat in eCosCentric and as a maintainer. I want to do what's best 
> for eCos, even if it conflicts with what eCosCentric wants. To be honest, 
> I don't think it's very likely we'll choose this option - I just threw it 
> in there for completeness, but tell me if I'm wrong!
> 
> > Has Mind been approached? What is their opinion on this. 
> 
> Dunno. Gary might have the best take on that if they don't speak up 
> themselves.

I can only talk loosely - I don't speak for Mind, but I know
their feelings.

Mind would prefer that copyright ownership be as non-commercial
as possible.  Since eCosCentric (as well as Red Hat) are competitors
of Mind, having the copyright be in eCosCentric's name could be
considered counter to such a goal.  A central body, such as SPI,
would be ideal.

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

Re: Future code ownership

[Andrew Lunn]

> 6) Software in the Public Interest, Inc. is a US not-for-profit 
> organisation. <http://www.spi-inc.org/> Its goals are to advance open 
> source. They are well known already as the copyright holders of many well 
> known projects like Debian Linux, GNOME, LSB as well as owners of the Open 
> Source marque, and so on. They are trusted.  We have already taken the 
> step of asking them in principle if they could accept eCos as a project, 
> even with our funky licensing proposal outlined above. And as you can see 
> from 
> <http://www.spi-inc.org/corporate/resolutions/resolution-2002-10-08.mgs> 
> this was accepted.
> 
> Personally I favour this option. I think it is best for eCos as an Open 
> Source project, and I would like to hope even Red Hat would be able to 
> support it, as it would be in the long-term best interests of eCos. 
> Besides if the licensing proposal does pay off, they would profit!

Has the opinion of RH been sought on this? 

To me, this does seem like the best option.

   Andrew

Re: Future code ownership

[Gary Thomas]

On Tue, 2002-12-17 at 02:26, Andrew Lunn wrote:
> > 6) Software in the Public Interest, Inc. is a US not-for-profit 
> > organisation. <http://www.spi-inc.org/> Its goals are to advance open 
> > source. They are well known already as the copyright holders of many well 
> > known projects like Debian Linux, GNOME, LSB as well as owners of the Open 
> > Source marque, and so on. They are trusted.  We have already taken the 
> > step of asking them in principle if they could accept eCos as a project, 
> > even with our funky licensing proposal outlined above. And as you can see 
> > from 
> > <http://www.spi-inc.org/corporate/resolutions/resolution-2002-10-08.mgs> 
> > this was accepted.
> > 
> > Personally I favour this option. I think it is best for eCos as an Open 
> > Source project, and I would like to hope even Red Hat would be able to 
> > support it, as it would be in the long-term best interests of eCos. 
> > Besides if the licensing proposal does pay off, they would profit!
> 
> Has the opinion of RH been sought on this? 
> 
> To me, this does seem like the best option.
> 

Frankly, Red Hat's opinion should not matter.  They're the ones
that caused all this ruckus in the first place.

As for me, I think this is the best solution.  My main reason
for putting my copyright in files I touch (which I believe matches 
those who followed me) was to preclude Red Hat from simply taking
work that I and others had done and selling it to the highest
bidder.  [n.b. of course the can still try to do this, but I'm
sure that some lawyer somewhere will stop them]  I would have
no problem assigning any new work I contribute to a third party
since this would have the same effect.

As Andrew has asked, how would we actually make such a change?
We can't change Red Hat's copyright notices without their consent.
Or can we get away with just assigning any new work to the SPI?

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

Re: Future code ownership

[Andrew Lunn]

> Frankly, Red Hat's opinion should not matter.  They're the ones
> that caused all this ruckus in the first place.

It may not matter, but if they do agree it adds more weight to this
option.

        Andrew

Re: Future code ownership

[Gary Thomas]

On Tue, 2002-12-17 at 09:14, Andrew Lunn wrote:
> > Frankly, Red Hat's opinion should not matter.  They're the ones
> > that caused all this ruckus in the first place.
> 
> It may not matter, but if they do agree it adds more weight to this
> option.

Indeed, but I hold little hope and we can't hold up waiting
for them to decide (IMO).

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

Re: Future code ownership

[Jonathan Larmour]

Gary Thomas wrote:
> On Tue, 2002-12-17 at 02:26, Andrew Lunn wrote:
> 
>>>6) Software in the Public Interest, Inc. is a US not-for-profit 
>>>organisation. <http://www.spi-inc.org/> Its goals are to advance open 
>>>source. They are well known already as the copyright holders of many well 
>>>known projects like Debian Linux, GNOME, LSB as well as owners of the Open 
>>>Source marque, and so on. They are trusted.  We have already taken the 
>>>step of asking them in principle if they could accept eCos as a project, 
>>>even with our funky licensing proposal outlined above. And as you can see 
>>>from 
>>><http://www.spi-inc.org/corporate/resolutions/resolution-2002-10-08.mgs> 
>>>this was accepted.
>>>
>>>Personally I favour this option. I think it is best for eCos as an Open 
>>>Source project, and I would like to hope even Red Hat would be able to 
>>>support it, as it would be in the long-term best interests of eCos. 
>>>Besides if the licensing proposal does pay off, they would profit!
>>
>>Has the opinion of RH been sought on this? 
>>
>>To me, this does seem like the best option.
> 
> Frankly, Red Hat's opinion should not matter.  They're the ones
> that caused all this ruckus in the first place.

Ostensibly true, although if they did have something to say on it, I would 
be interested. If they have constructive feedback, it's welcome. You never 
know, some accomodation could be reached. Haha :-).

> As for me, I think this is the best solution.  My main reason
> for putting my copyright in files I touch (which I believe matches 
> those who followed me) was to preclude Red Hat from simply taking
> work that I and others had done and selling it to the highest
> bidder.  [n.b. of course the can still try to do this, but I'm
> sure that some lawyer somewhere will stop them]

Only if you pay that lawyer yourself ;-). It's up to the copyright holders 
to enforce. Indeed that's one disadvantage of the "free for all, no 
assignments" approach, that it's more difficult to enforce legally.

> As Andrew has asked, how would we actually make such a change?
> We can't change Red Hat's copyright notices without their consent.

Indeed not.

> Or can we get away with just assigning any new work to the SPI?

Yes. It will have dual copyright, just like many files or dual copyright 
Red Hat and you, or Red Hat and Bart, etc.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Andrew Lunn]

> But we can give them an option: a solution is to allow licence opt-outs, 
> like Red Hat had been able to do by themselves up to earlier this year 
> (but not after personal copyright from the maintainers got added of 
> course). This would set us at a par with commercial OS vendors. But we 
> can't compromise our integrity without a considerable pound of flesh. So 
> we charge. The figures would probably depend per deal, but it could well 
> be in the order of thousands of dollars. Maybe. Don't know. Haven't tried 
> it :-). Unfortunately that money would have to be split with Red Hat, a 
> commercial entity, but as Red Hat's role in eCos diminishes, so too is 
> their leverage. 

A question which is probably out of scope of this discussion:

How do you measure RH role and hence there split of the money?
Proportion of the number of patches per year? Lines of code
contributed per year? Number of files with pure RH copywrite headers?

     Andrew

Re: Future code ownership

[Jonathan Larmour]

Andrew Lunn wrote:
>>But we can give them an option: a solution is to allow licence opt-outs, 
>>like Red Hat had been able to do by themselves up to earlier this year 
>>(but not after personal copyright from the maintainers got added of 
>>course). This would set us at a par with commercial OS vendors. But we 
>>can't compromise our integrity without a considerable pound of flesh. So 
>>we charge. The figures would probably depend per deal, but it could well 
>>be in the order of thousands of dollars. Maybe. Don't know. Haven't tried 
>>it :-). Unfortunately that money would have to be split with Red Hat, a 
>>commercial entity, but as Red Hat's role in eCos diminishes, so too is 
>>their leverage. 
> 
> 
> A question which is probably out of scope of this discussion:
> 
> How do you measure RH role and hence there split of the money?
> Proportion of the number of patches per year? Lines of code
> contributed per year? Number of files with pure RH copywrite headers?

I imagine it will be subject to negotiation at the time. Since it requires 
both parties to agree, it's in their interests to come to some fair 
accomodation. It may even be negotiated per deal, depending on where the 
prime interest comes from (newly written stuff, or old stuff). But as I 
said, as Red Hat's role diminishes, so is their entitlement. It may be 
that no deal can be made - that would be stupid for RH, but I would rather 
not go into how likely I think that would be then ;-/).

So I'm afraid there's nothing else that can be said about the specifics. 
The whole reason for the hiatus in resolving the assignment and ownership 
issue was trying to resolve this type of thing, and it's a shame that it 
came to naught.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Andrew Lunn]

> 1) No copyright assignments at all. This is like the Linux kernel. The 
> admin overhead is reduced, as well as the hassle factor for contributors. 
> However the ownership of the code is called into question, and there is a 
> risk that code that is contributed may not be the copyright owners - think 
> of the corporate disclaimer thing we have. Certainly the FSF are against 
> it for these types of reasons, and they are the acknowledged experts in 
> this field. Once this decision is made it can never be revoked. Definitely 
> no potential licence revenue.

I don't think assignments are that much of a burden on the
contributer, but i would try to ensure its a case of sign it once, it
lasts indefinatly. Having to redo the assignment everytime was APITA.

We know RH had the infrastucture in place to handle these
assignments. What about the other options. Does SPI Inc already have
this infrastructure? Do any of its other projects require such
assignments? How quickly are they processed?

      Andrew

Re: Future code ownership

[Jonathan Larmour]

Andrew Lunn wrote:
>>1) No copyright assignments at all. This is like the Linux kernel. The 
>>admin overhead is reduced, as well as the hassle factor for contributors. 
>>However the ownership of the code is called into question, and there is a 
>>risk that code that is contributed may not be the copyright owners - think 
>>of the corporate disclaimer thing we have. Certainly the FSF are against 
>>it for these types of reasons, and they are the acknowledged experts in 
>>this field. Once this decision is made it can never be revoked. Definitely 
>>no potential licence revenue.
> 
> 
> I don't think assignments are that much of a burden on the
> contributer,

Personally I agree, but I know others think differently.

 > but i would try to ensure its a case of sign it once, it
> lasts indefinatly. Having to redo the assignment everytime was APITA.

Absolutely. We just modify the existing form.

> We know RH had the infrastucture in place to handle these
> assignments. What about the other options. Does SPI Inc already have
> this infrastructure? Do any of its other projects require such
> assignments? How quickly are they processed?

No, they have no infrastructure, we would have to handle them ourselves. 
I'll volunteer FWIW. I'd probably set up a PO Box so any other maintainery 
people would be able to take over "just in case".

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Andrew Lunn]

> 5) A new not-for-profit organisation, e.g. "the eCos foundation". There is 
> considerable difficulty for non-USers to set this up, and the process can 
> take upwards of 6 months I believe. There may also be tedious obligations 
> and overhead like accounts, board meetings, blah blah. Plus without any 
> experience we may need lawyers, and therefore fees, etc. as well as any 
> other charges for setting it up.

What about the English equivalent? I guess that means getting Charity
status. Have you look at this option? I guess it still needs lawyers
etc.

        Andrew

Re: Future code ownership

[Gary Thomas]

On Tue, 2002-12-17 at 09:42, Andrew Lunn wrote:
> > 5) A new not-for-profit organisation, e.g. "the eCos foundation". There is 
> > considerable difficulty for non-USers to set this up, and the process can 
> > take upwards of 6 months I believe. There may also be tedious obligations 
> > and overhead like accounts, board meetings, blah blah. Plus without any 
> > experience we may need lawyers, and therefore fees, etc. as well as any 
> > other charges for setting it up.
> 
> What about the English equivalent? I guess that means getting Charity
> status. Have you look at this option? I guess it still needs lawyers
> etc.
> 

Yes, Jonathan looked into this at length.  It did not seem to be
a very workable (hardly possible) solution.
-- 
------------------------------------------------------------
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
------------------------------------------------------------

Re: Future code ownership

[Jonathan Larmour]

Gary Thomas wrote:
> On Tue, 2002-12-17 at 09:42, Andrew Lunn wrote:
> 
>>>5) A new not-for-profit organisation, e.g. "the eCos foundation". There is 
>>>considerable difficulty for non-USers to set this up, and the process can 
>>>take upwards of 6 months I believe. There may also be tedious obligations 
>>>and overhead like accounts, board meetings, blah blah. Plus without any 
>>>experience we may need lawyers, and therefore fees, etc. as well as any 
>>>other charges for setting it up.
>>
>>What about the English equivalent? I guess that means getting Charity
>>status. Have you look at this option? I guess it still needs lawyers
>>etc.
> 
> Yes, Jonathan looked into this at length.  It did not seem to be
> a very workable (hardly possible) solution.

Indeed, the summary was that it was a) very unlikely that an open source 
project could be considered a sufficiently good work for the purposes of 
being designated a charity, and b) out of the question for any money from 
licence revenue to be used in the way we'd want it.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Frank Ch. Eigler]

Hi -


Speaking merely as an interested individual sympathetic outsider, I
wonder if jifl correctly understands SPI's relationship to other
projects it is associated with:

> 6) Software in the Public Interest, Inc. is a US not-for-profit
> organisation. <http://www.spi-inc.org/> Its goals are to advance open
> source. They are well known already as the copyright holders of many
> well known projects like Debian Linux, GNOME, LSB as well as owners of
> the Open Source marque, and so on.

A quick cursory browse of a bunch of pieces of the gnome distribution
shows copyright notices from all sorts of players, FSF, Red Hat, and
many individuals.  I didn't actually see any SPI copyright notices.

There were a few listed drawbacks of a mixed-copyright future for
eCos.  Maybe they are not too serious:

The problem of lack of single copyright enforcement agent would not be
diminished if some of the new code was assigned to SPI or somesuch,
for there would still be Red Hat (C) code in there.  (Or is one of the
ideas to get Red Hat to reassign to SPI too?)

The problem of uncertainty about the trustworthiness of contributors to
submit code unimpeded by corporate copyright is not going to go away in
any case.  You might try requiring submitters to specify the appropriate
copyright notice for the new code, in effect making it their onus to
determine/state corporate impact.  You could then take it at face value.

The problem of shipping relicensed (non-GPL) eCos derivatives is probably
moot unless Red Hat Officials Of Great Highness see it fit to come to
an agreement with you guys.  (I clearly have no clue about this.)  If
no such agreement occurs, then license revenue matters become moot.
(... or you could rewrite all that existing code! :-)


- FChE

Re: Future code ownership

[Bart Veer]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

    Frank> Hi -
    Frank> Speaking merely as an interested individual sympathetic
    Frank> outsider, I wonder if jifl correctly understands SPI's
    Frank> relationship to other projects it is associated with:

    >> 6) Software in the Public Interest, Inc. is a US not-for-profit
    >> organisation. <http://www.spi-inc.org/> Its goals are to advance open
    >> source. They are well known already as the copyright holders of many
    >> well known projects like Debian Linux, GNOME, LSB as well as owners of
    >> the Open Source marque, and so on.

    Frank> A quick cursory browse of a bunch of pieces of the gnome
    Frank> distribution shows copyright notices from all sorts of
    Frank> players, FSF, Red Hat, and many individuals. I didn't
    Frank> actually see any SPI copyright notices.

Initial discussions with SPI have already happened, courtesy of Jifl.
AFAIK it is correct that for their other projects SPI do not bother
with copyright assignments, but the different projects can operate
under different rules. For something like GNOME, I suspect there was
never any real possibility of a single copyright holder because bits
of initial code were taken from anywhere if it helped the project.
eCos was managed differently from the beginning.

    Frank> There were a few listed drawbacks of a mixed-copyright
    Frank> future for eCos. Maybe they are not too serious:

    Frank> The problem of lack of single copyright enforcement agent
    Frank> would not be diminished if some of the new code was
    Frank> assigned to SPI or somesuch, for there would still be Red
    Frank> Hat (C) code in there. (Or is one of the ideas to get Red
    Frank> Hat to reassign to SPI too?)

Ideally Red Hat would assign to SPI as well, simplifying the whole
situation. But if they do not, copyright enforcement is still an awful
lot simpler when there only two copyright holders than when there are
hundreds. Also, if a case did arise of copyright or license
infringement then I consider it unlikely that Red Hat would interfere.
Depending on the severity of the infringement they might well choose
to cooperate, in the interest of open source generally.

    Frank> The problem of uncertainty about the trustworthiness of
    Frank> contributors to submit code unimpeded by corporate
    Frank> copyright is not going to go away in any case. You might
    Frank> try requiring submitters to specify the appropriate
    Frank> copyright notice for the new code, in effect making it
    Frank> their onus to determine/state corporate impact. You could
    Frank> then take it at face value.

The assignment process for a corporate employee also involves a
disclaimer form that has to be signed by an officer of the company, as
per the FSF. It would be very hard for a company to then claim the
assignment was invalid and sue for damages. Even if somehow a case
came to court, there would be clear documentation showing that the
maintainers had acted in good faith and had taken all reasonable
precautions. Offhand I cannot remember a single instance where an FSF
project had to remove a contributed patch because the assignment was
invalid.

    Frank> The problem of shipping relicensed (non-GPL) eCos
    Frank> derivatives is probably moot unless Red Hat Officials Of
    Frank> Great Highness see it fit to come to an agreement with you
    Frank> guys. (I clearly have no clue about this.) If no such
    Frank> agreement occurs, then license revenue matters become moot.
    Frank> (... or you could rewrite all that existing code! :-)

The relicensing issue is moot if Red Hat management choose not to
cooperate. Rewriting all the code is theoretically possible (and there
are a few bits that really should be rewritten), but working on new
functionality is a far better use of everybody's time.

Bart

Re: Future code ownership

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Hi -


On Thu, Dec 19, 2002 at 10:29:12PM +0000, Bart Veer wrote:
> [...]
> Ideally Red Hat would assign to SPI as well, simplifying the whole
> situation. But if they do not, copyright enforcement is still an awful
> lot simpler when there only two copyright holders than when there are
> hundreds.  [...]

I don't know for sure, but this belief sounds like an old wives' tale.
Why is there an impression that an infringement suit can only proceed
if *all* (vs. any) of the infringement victims want it to go ahead?


> The assignment process for a corporate employee also involves a
> disclaimer form that has to be signed by an officer of the company, as
> per the FSF. [...] there would be clear documentation showing that the
> maintainers had acted in good faith and had taken all reasonable
> precautions. [...]

Yes, I'm aware of that.  My point was that you could accept a lower
standard of paperwork (basically the submitter's affirmation, perhaps
in the form of a proposed copyright notice for the new code).  I have
heard of no contrasting outcome for infringement disputes involving
projects that use looser vs. tighter submission paperwork rules.
In other words, such "all reasonable precautions", while likely
sufficient, may not be necessary to protect yourselves.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Future code ownership

[Bart Veer]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

    Frank> On Thu, Dec 19, 2002 at 10:29:12PM +0000, Bart Veer wrote:
    >> [...]
    >> Ideally Red Hat would assign to SPI as well, simplifying the whole
    >> situation. But if they do not, copyright enforcement is still an awful
    >> lot simpler when there only two copyright holders than when there are
    >> hundreds.  [...]

    Frank> I don't know for sure, but this belief sounds like an old
    Frank> wives' tale. Why is there an impression that an
    Frank> infringement suit can only proceed if *all* (vs. any) of
    Frank> the infringement victims want it to go ahead?

I didn't intend to give any such impression. As far as I am aware any
copyright holder can launch an infringement suit, it does not require
agreement by all of them. Of course if a copyright holder has only
contributed a few lines then a court might decide that the action was
frivolous. An open source organization like SPI will be taken
seriously.

Also, from the perspective of a potential user who is worried about
open source, having lots of copyright holders is a bad thing because
any of them might sue for some perceived slight. If instead copyright
is only held by one or two reputable organizations then such risks are
greatly reduced.

It does require agreement by all copyright holders to change the
license, or to grant license exemptions.

    >> The assignment process for a corporate employee also involves a
    >> disclaimer form that has to be signed by an officer of the
    >> company, as per the FSF. [...] there would be clear
    >> documentation showing that the maintainers had acted in good
    >> faith and had taken all reasonable precautions. [...]

    Frank> Yes, I'm aware of that. My point was that you could accept
    Frank> a lower standard of paperwork (basically the submitter's
    Frank> affirmation, perhaps in the form of a proposed copyright
    Frank> notice for the new code). I have heard of no contrasting
    Frank> outcome for infringement disputes involving projects that
    Frank> use looser vs. tighter submission paperwork rules. In other
    Frank> words, such "all reasonable precautions", while likely
    Frank> sufficient, may not be necessary to protect yourselves.

Not sure about that - if we are going to bother with copyright
assignments at all then we might as well do it properly. The FSF has
defined certain procedures which it considers necessary, and it has
some very good legal advisors. If a potential eCos user has questions
about the legal status of contributions, pointing at the FSF precedent
makes things a lot simpler.

Bart

Re: Future code ownership

[Frank Ch. Eigler]

bartv wrote:

> [...]                 if we are going to bother with copyright
> assignments at all then we might as well do it properly. 

I'm still being misunderstood.  My point is that you might find a way
to go *without* formal copyright assignments to a central organization,
and still be relatively safe from corporate copyrights.


> The FSF has
> defined certain procedures which it considers necessary, and it has
> some very good legal advisors. 

Yes, whatever they have makes sense to them for their assignment-based
scheme, and there has been little "competition" to discourage excessive
barriers to contribution.


- FChE

Re: Future code ownership

[Jonathan Larmour]

Frank Ch. Eigler wrote:
> bartv wrote:
> 
> 
>>[...]                 if we are going to bother with copyright
>>assignments at all then we might as well do it properly. 
> 
> 
> I'm still being misunderstood.  My point is that you might find a way
> to go *without* formal copyright assignments to a central organization,
> and still be relatively safe from corporate copyrights.

"relatively"? It's the "relatively" that's the problem. I agree that 99% 
of the time there's no problem. It's the magnitude of the problems that 
the 1% cause that give us reason to hesitate.

>>The FSF has
>>defined certain procedures which it considers necessary, and it has
>>some very good legal advisors. 
> 
> 
> Yes, whatever they have makes sense to them for their assignment-based
> scheme, and there has been little "competition" to discourage excessive
> barriers to contribution.

But it's their legal advisors that say it's not excessive to use an 
assignment-based scheme! It's the only way to be legally sure about ownership.

Remember it's not just ass covering for the project as a whole. *We* can 
revert a patch if need be. It's ass covering for *all* users out there, 
because if they download something that shouldn't have had some bits 
included, they could be up shit creek. We have a responsibility to protect 
them. *Our* life would be easy because there is indeed little more we can 
do than put out an announcement to tell people they shouldn't use such and 
such versions of eCos, and CVS between such and such dates.

But it could create dire problems for people out there who just don't find 
out, and maybe ship a hardware product running eCos, and due to the GPL it 
will be easy to find out if it contained a "bad" patch, after which the 
copyright owner could see it and sue.

It would be easier if eCos was only shipped by itself as software, like 
GCC, GDB, SourceNav, SID etc. Recalling hardware on the other hand...

And the whole fact that this _can_ arise will scare off many companies. 
They just won't take the risk, and we've lost potential eCos users. I've 
definitely heard that said about the Linux kernel. Our commercial 
competitors could certainly use it as FUD ammunition.

Maybe despite all this we should drop the assignment requirements anyway. 
But I want to make sure everyone has their eyes opened to what it could mean.

Jifl - with a nasty cold so apologies if anything above is gibberish
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Jonathan Larmour]

Hi all,

I would like to bring the issue in this thread to a conclusion without 
much further delay. However I agree with the sentiments that we should 
seek an official position from Red Hat to consider before we make an 
irrevocable step.

To that end I am CC'ing this to two people in Red Hat I believe should be 
able to inform us, and I hope they (or some more appropriate person) will 
be able to give us an idea of Red Hat's official position. Alas, I think I 
will have to put a two week limit on this (Sun Jan 26th) - if nothing is 
received in that time, we will have to reach a conclusion without Red Hat. 
That is more than enough time for Red Hat to discuss this internally.

To Tony and Mark: in summary, the issue is the continuation of copyright 
assignments to Red Hat which a significant number of contributors now 
object to, mostly due to Red Hat no longer having any significant role in 
eCos's development and therefore little interest in its success. Some 
people also feel aggrieved by Red Hat for reasons of their own. Some feel 
that, even given assurances, Red Hat can no longer be trusted. Whatever 
the reason (and we aren't responsible for those opinions!), it is 
something that needs to be addressed in the interests of the eCos open 
source community.

To that end, a number of options were presented as per 
http://sources.redhat.com/ml/ecos-maintainers/2002-12/msg00001.html and 
followed up to in subsequent messages. Although no conclusion has yet been 
reached, the two options being considered most appear to be dropping the 
requirement for copyright assignments completely, or assigning to a 
not-for-profit entity. In the latter case, SPI (Software in the Public 
Interest) who represent many other Open Source groups (even owning the 
Open Source brand) such as Debian Linux, GNOME, etc. have been approached 
and have stated their willingness to do so.

Also in the latter case, we see some possibility of permitting exemptions 
from the usual GPL licence obligations for large companies who are too 
dumb to embrace Free Software, but at a price. That price would be put 
exclusively towards the benefit of eCos, the Open Source project. 
Restrictions would be put in place to prevent maintainer's benefitting 
from decisions about how that money would be spent in which they took part.

It is this more than anything that we seek Red Hat's opinion of. Would 
they in principle be willing to work with the maintainers and SPI to 
arrange such licensing exemptions? Would they be willing to outline what 
the likely terms in principle would be? I should probably point out that 
if we cannot come to some mutual agreement then Red Hat will not be able 
to benefit at all. I should also add that this cannot be the subject of 
long negotiation. There is a 2.0 beta release coming up, with a 2.0 final 
soon after. We will not delay the releases to have this resolved, and will 
need to reach a decision with or without Red Hat.

If you wish, you may reply in private to me and I will gladly forward to 
all maintainers, although purely for transparency it would be preferred if 
this was in the open on the ecos-maintainers mailing list (which has 
public archives) if it is commercially possible. Alternatively, you can 
phone me, and I will act as intermediary as best I can, although the final 
decision will be collective. Contact phone number available if you e-mail 
me off list.

I should add for the absence of doubt to Tony and Mark, that this is 
purely in the context of an eCos maintainer, and nothing to do with 
eCosCentric or any other commercial organisation. In this discussion, we 
the maintainers (made up of people from eCosCentric, Mind, Ascom as well 
as Red Hat) are acting purely for the benefit of the open source project, 
even if this is contrary to our employer's preferences; as with other open 
source projects.

Thanks in advance,

Jifl
// Nominal eCos chief maintainer
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Jonathan Larmour]

Hi Tony and Mark,

Is there really no interest or comment from Red Hat on the below? The 
clock is ticking.

Jifl

Jonathan Larmour wrote:
> Hi all,
> 
> I would like to bring the issue in this thread to a conclusion without 
> much further delay. However I agree with the sentiments that we should 
> seek an official position from Red Hat to consider before we make an 
> irrevocable step.
> 
> To that end I am CC'ing this to two people in Red Hat I believe should 
> be able to inform us, and I hope they (or some more appropriate person) 
> will be able to give us an idea of Red Hat's official position. Alas, I 
> think I will have to put a two week limit on this (Sun Jan 26th) - if 
> nothing is received in that time, we will have to reach a conclusion 
> without Red Hat. That is more than enough time for Red Hat to discuss 
> this internally.
> 
> To Tony and Mark: in summary, the issue is the continuation of copyright 
> assignments to Red Hat which a significant number of contributors now 
> object to, mostly due to Red Hat no longer having any significant role 
> in eCos's development and therefore little interest in its success. Some 
> people also feel aggrieved by Red Hat for reasons of their own. Some 
> feel that, even given assurances, Red Hat can no longer be trusted. 
> Whatever the reason (and we aren't responsible for those opinions!), it 
> is something that needs to be addressed in the interests of the eCos 
> open source community.
> 
> To that end, a number of options were presented as per 
> http://sources.redhat.com/ml/ecos-maintainers/2002-12/msg00001.html and 
> followed up to in subsequent messages. Although no conclusion has yet 
> been reached, the two options being considered most appear to be 
> dropping the requirement for copyright assignments completely, or 
> assigning to a not-for-profit entity. In the latter case, SPI (Software 
> in the Public Interest) who represent many other Open Source groups 
> (even owning the Open Source brand) such as Debian Linux, GNOME, etc. 
> have been approached and have stated their willingness to do so.
> 
> Also in the latter case, we see some possibility of permitting 
> exemptions from the usual GPL licence obligations for large companies 
> who are too dumb to embrace Free Software, but at a price. That price 
> would be put exclusively towards the benefit of eCos, the Open Source 
> project. Restrictions would be put in place to prevent maintainer's 
> benefitting from decisions about how that money would be spent in which 
> they took part.
> 
> It is this more than anything that we seek Red Hat's opinion of. Would 
> they in principle be willing to work with the maintainers and SPI to 
> arrange such licensing exemptions? Would they be willing to outline what 
> the likely terms in principle would be? I should probably point out that 
> if we cannot come to some mutual agreement then Red Hat will not be able 
> to benefit at all. I should also add that this cannot be the subject of 
> long negotiation. There is a 2.0 beta release coming up, with a 2.0 
> final soon after. We will not delay the releases to have this resolved, 
> and will need to reach a decision with or without Red Hat.
> 
> If you wish, you may reply in private to me and I will gladly forward to 
> all maintainers, although purely for transparency it would be preferred 
> if this was in the open on the ecos-maintainers mailing list (which has 
> public archives) if it is commercially possible. Alternatively, you can 
> phone me, and I will act as intermediary as best I can, although the 
> final decision will be collective. Contact phone number available if you 
> e-mail me off list.
> 
> I should add for the absence of doubt to Tony and Mark, that this is 
> purely in the context of an eCos maintainer, and nothing to do with 
> eCosCentric or any other commercial organisation. In this discussion, we 
> the maintainers (made up of people from eCosCentric, Mind, Ascom as well 
> as Red Hat) are acting purely for the benefit of the open source 
> project, even if this is contrary to our employer's preferences; as with 
> other open source projects.
> 
> Thanks in advance,
> 
> Jifl
> // Nominal eCos chief maintainer


-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Future code ownership

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Hi -


jifl wrote:

> > I'm still being misunderstood.  My point is that you might find a way
> > to go *without* formal copyright assignments to a central organization,
> > and still be relatively safe from corporate copyrights.
> 
> "relatively"? It's the "relatively" that's the problem. I agree that 99% 
> of the time there's no problem. It's the magnitude of the problems that 
> the 1% cause that give us reason to hesitate.

Right.


> > Yes, whatever [the FSF has] makes sense to them for their assignment-based
> > scheme, and there has been little "competition" to discourage excessive
> > barriers to contribution.
> 
> But it's their legal advisors that say it's not excessive to use an 
> assignment-based scheme! It's the only way to be legally sure about
> ownership. [...]

But that begs the question.  Just because the FSF uses such relatively
bulletproof documentation requirements (company officers' signatures
for assignments) does not mean that this is the only way.  (Even the
FSF has a slightly different copyright-disclaim mechanism.)  Anyway,
Another lawyer may give advice more in line with my intuition, and
that would render FSF's approach excessive.  IOW, You might want to
get your own legal opinion.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]