This is the mail archive of the ecos-maintainers@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gnu.org #25869] eCos as an FSF project?


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 at gnu dot 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]