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

[FSF General Contact Address <info@fsf.org>]

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 <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?

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 <bug-ecos@gnu.org> 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 
> <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?

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