From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9602 invoked by alias); 10 Apr 2003 22:08:16 -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 9579 invoked from network); 10 Apr 2003 22:08:15 -0000 Date: Thu, 10 Apr 2003 22:08:00 -0000 From: FSF General Contact Address To: ecos-maintainers@sources.redhat.com Subject: Re: [gnu.org #25869] eCos as an FSF project? Message-ID: <20030410214734.GH1904@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-SW-Source: 2003-04/txt/msg00024.txt.bz2 On Thu, Apr 03, 2003 at 02:53:12PM -0500, Jonathan Larmour via RT wrote: > 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: Thank you for your consideration into becoming a GNU project. I have addressed your points one-by-one below. > 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." > > So would this be an obstacle? Such non-free documentation would be problematic, yes. The freedom for users to use, share, modify, and redistribute their software, and its documentation, is of utmost importance to the GNU project. We cannot provide people with documentation that restricts the freedom to redistribute, as option B of the Open Publication License does; it would be counterproductive to the goals of the GNU project. Similarly, the FSF could not accept copyright on such a work. Red Hat disclaims all changes made by its employees to a number of GNU programs. We may approach them about doing the same for eCos if you all are dedicated to making it a GNU project, and may be able to deal with this problem by obtaining full copyright on the document and relicensing it. > 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? We would like to see these changes made before eCos is released as GNU software. I understand that these changes can seem daunting, but we have historically found that they do not require nearly as much effort as one might expect. As an example, similar problems were recently found in distributions of GNU GhostScript, and were corrected within the course of a couple of hours. You will likely have the opportunity to deal with these issues while we hammer out other details of the process. > 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? A bug reporting address is not required, and we have no problems with you using Bugzilla. I understand that there is an e-mail interface for reporting bugs contributed to Bugzilla; if that is installed on your server, we could set up as a simple forwarder to that address, if you think it would be helpful. > 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? No, this is not required. > 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!). 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 Both of these are fine. > 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. I have raised your concerns here to a number of others here at the FSF; I will let you know when I have an answer on this. > 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? If Red Hat maintains separate copyright on the program, contributions of Red Hat employees will be covered by that. If Red Hat assigns copyright for its employees' contributions to the FSF, they will be covered by that agreement. Either way, no explicit assignment will be required from each individual Red Hat employee. I hope this adequately addresses all of your concerns. If you have any other questions I can answer for you, please don't hesitate to let me know. We look forward to hearing back from you. Best regards, -- Brett Smith, Free Software Foundation Become a card-carrying member of FSF: http://member.fsf.org/ Help support our work for FSF and the GNU project: http://svcs.affero.net/rm.php?r=fsfinfo