public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: FSF General Contact Address <info@fsf.org>
Cc: ecos-maintainers@sources.redhat.com
Subject: Re: [gnu.org #25869] eCos as an FSF project?
Date: Thu, 03 Apr 2003 19:51:00 -0000	[thread overview]
Message-ID: <3E8C90B5.2020807@jifvik.org> (raw)
In-Reply-To: <20030328192326.GF3053@gnu.org>

Hi Brett,

FSF General Contact Address wrote:
> On Wed, Mar 26, 2003 at 11:03:23AM -0500, Jonathan Larmour via RT wrote:
> 
>>On behalf of the eCos maintainers, I would like to express our interest in 
>>possibly becoming an FSF project.
> 
> 
> Dear Jonathan, and the rest of the eCos team,
> 
> Thank you for taking the time to write to us with your questions about Free
> Software Foundation's possible support for the eCos project.  We appreciate
> the wonderful contribution your works provides to the free software
> community, and would be happy to assist you in what ways we can.

Thank you :-).

> Historically, FSF has accepted copyright for those programs which become
> part of the GNU project.  This is not because of any legal restrictions or
> obligations on us; it is simply how things have gone.  We would like to
> know, however, if you would be willing to consider making eCos part of the
> GNU project.
> Becoming a GNU project means that the project developers agree to GNU
> policies.  These are listed at <http://www.gnu.org/prep/maintain_toc.html>.
> They are the full requirements; beyond what is listed there, the developers
> have full autonomy over the program's development.

That does clarify a lot of things. On the basis of that, we have discussed 
and are willing to become a GNU project.... although we still have a few 
questions and issues that would need checking:

1) Someone reminded me that, although eCos code is covered by the eCos 
licence (GPL plus a special exception), our documentation is covered by a 
different licence, which unfortunately is not the FDL. It is the Open 
Publication Licence as described here: http://www.opencontent.org/openpub/ 
and includes License option B, namely:

"Distribution of the work or derivative of the work in any
standard (paper) book form is prohibited unless prior
permission is obtained from the copyright holder."

This is not ideal certainly. However Red Hat also own partial copyright 
over our documentation files, so we are not in a position to change this. 
We have made changes to this documentation, so if we did become a GNU 
project, then as a result of the copyright assignments the files would be 
joint copyright, like the eCos source code - therefore Red Hat will not 
have any special status any more.

So would this be an obstacle? And for any completely new pieces of 
documentation presumably the FDL should be used instead of trying to be 
consistent by continuing with the OPL.

2) We understand that we should make relatively minor but widespread 
changes across our sources, documentation and web pages like changing 
"Linux" to "GNU/Linux" and using PNGs instead of GIFs. Would it be okay 
for this changeover to be an ongoing process rather than needing to go 
through everything immediately which would take some time given that we 
are a well established project?

3) We already have a well established bug reporting system in the form of 
bugzilla, as per <http://sources.redhat.com/ecos/problemreport.html>. As 
such we think the creation of a bug-ecos@gnu.org list would be a confusing 
distraction. Is this list actually necessary? Or if it existed could we 
set up an autoresponder to tell people to use bugzilla instead?

4) According to http://www.gnu.org/prep/maintain_7.html#SEC7 we need to 
set up an AUTHORS file, however this would be very difficult since we are 
such an established project (first release to the net 6 years ago now) so 
any information would be woefully incomplete, although we have an existing 
(also incomplete :-| ) list of people to thank at 
<http://sources.redhat.com/ecos/contrib.html>. In addition I note that 
neither GCC nor GDB appear to have such a file. So is it really a requirement?

5) http://www.gnu.org/prep/maintain_16.html#SEC16 doesn't really apply to 
eCos - our established distribution system is very different... in fact by 
design due to the package and component nature of eCos (I can describe how 
it differs in more detail if you're interested!). We distribute prebuilts 
for tools on the host side (with source since they are GPL), as we know 
from our own bitter experience that they can be difficult to build, and 
aren't even the purpose of eCos - the code on the target is. This is of 
course along with the eCos target-side sources with a radically different 
build system given the requirements of the eCos design and the nature of 
cross-targeted systems. Therefore I would imagine we should just be able 
to ignore this page since it doesn't really apply. Okay?

Similarly, although it doesn't say it is a requirement anyway, I'll just 
mention that given the package nature of eCos it is not practical to 
distribute diffs as per http://www.gnu.org/prep/maintain_17.html#SEC17

6) Can we have some sort of guarantee that the FSF will never seek to 
change the eCos licence (we are concerned about losing the exception 
clause that had been applied) without the input of the maintainers and 
without good cause? Since losing the exception would be a tightening of 
the licence, it would not require Red Hat's consent to do this so unlike 
other changes this could happen unilaterally by the FSF.

7) We still have a few people in Red Hat who submit patches. Given the 
very widespread nature of the Red Hat copyright in the existing files, 
would they strictly still require an assignment or would they be a special 
case? I'm just saying this speculatively - we don't yet know what Red 
Hat's opinions of an assignment for eCos work would be.... the 
relationship between Red Hat and eCos is at present somewhat indeterminate!

> It would not be problematic for Red Hat to hold copyright alongside FSF.

Good, since unfortunately we don't have much choice! :-)

Thanks for the response, and hopefully we should be able to come to a 
quick decision based on your reply to these many (sorry!) questions.

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

  reply	other threads:[~2003-04-03 19:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <rt-25869@gnu.org>
     [not found] ` <rt-25869-69834.13.1459854406747@rt.gnu.org>
2003-03-28 19:57   ` FSF General Contact Address
2003-04-03 19:51     ` Jonathan Larmour [this message]
     [not found] ` <rt-25869-73954.4.22037571649483@rt.gnu.org>
2003-04-10 22:08   ` FSF General Contact Address
2003-04-10 23:21     ` Jonathan Larmour
2003-04-11  7:50       ` Andrew Lunn
2003-04-11 12:02       ` Nick Garnett
2003-04-13 18:20       ` Bart Veer
2003-04-14 19:50         ` Jonathan Larmour
2003-05-19 22:20 FSF General Contact Address
2003-05-19 22:56 ` Jonathan Larmour

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=3E8C90B5.2020807@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=ecos-maintainers@sources.redhat.com \
    --cc=info@fsf.org \
    /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).