public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: eCos Maintainers <ecos-maintainers@sources.redhat.com>
Subject: Future code ownership
Date: Mon, 16 Dec 2002 07:52:00 -0000	[thread overview]
Message-ID: <3DFDF6B7.8090008@jifvik.org> (raw)

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

             reply	other threads:[~2002-12-16 15:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-16  7:52 Jonathan Larmour [this message]
2002-12-17  0:44 ` Andrew Lunn
2002-12-17 19:57   ` Jonathan Larmour
2002-12-17  1:09 ` Andrew Lunn
2002-12-17 15:24   ` Bart Veer
2002-12-18  0:40     ` Andrew Lunn
2002-12-19  5:09     ` Jonathan Larmour
2002-12-17 19:54   ` Jonathan Larmour
2002-12-17 20:00     ` Gary Thomas
2002-12-17  1:27 ` Andrew Lunn
2002-12-17  5:47   ` Gary Thomas
2002-12-17  9:16     ` Andrew Lunn
2002-12-17  8:52       ` Gary Thomas
2002-12-17 12:29     ` Jonathan Larmour
2002-12-17  8:29 ` Andrew Lunn
2002-12-17 12:23   ` Jonathan Larmour
2002-12-17  8:38 ` Andrew Lunn
2002-12-17 12:18   ` Jonathan Larmour
2002-12-17  8:42 ` Andrew Lunn
2002-12-17  8:56   ` Gary Thomas
2002-12-17 12:00     ` Jonathan Larmour
2002-12-19 11:52 Frank Ch. Eigler
2002-12-19 14:39 ` Bart Veer
2002-12-20 14:21   ` Frank Ch. Eigler
2002-12-22 15:21     ` Bart Veer
2002-12-23  7:53       ` Frank Ch. Eigler
2003-01-02 14:55         ` Jonathan Larmour
2003-01-12  2:42           ` Jonathan Larmour
2003-01-22  2:22             ` Jonathan Larmour
     [not found] <3E145A86.5050601@eCosCentric.com>
2003-01-02 16:21 ` Frank Ch. Eigler

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=3DFDF6B7.8090008@jifvik.org \
    --to=jifl@jifvik.org \
    --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).