From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24733 invoked by alias); 3 Apr 2003 19:51:19 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 24696 invoked from network); 3 Apr 2003 19:51:18 -0000 Message-ID: <3E8C90B5.2020807@jifvik.org> Date: Thu, 03 Apr 2003 19:51:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030314 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: FSF General Contact Address Cc: ecos-maintainers@sources.redhat.com Subject: Re: [gnu.org #25869] eCos as an FSF project? References: <20030328192326.GF3053@gnu.org> In-Reply-To: <20030328192326.GF3053@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00018.txt.bz2 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 . > 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 . 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 . 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