public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: FSF General Contact Address <info@fsf.org>
To: ecos-maintainers@sources.redhat.com
Subject: Re: [gnu.org #25869] eCos as an FSF project?
Date: Thu, 10 Apr 2003 22:08:00 -0000	[thread overview]
Message-ID: <20030410214734.GH1904@gnu.org> (raw)
In-Reply-To: <rt-25869-73954.4.22037571649483@rt.gnu.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


  parent reply	other threads:[~2003-04-10 22:08 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
     [not found] ` <rt-25869-73954.4.22037571649483@rt.gnu.org>
2003-04-10 22:08   ` FSF General Contact Address [this message]
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=20030410214734.GH1904@gnu.org \
    --to=info@fsf.org \
    --cc=ecos-maintainers@sources.redhat.com \
    /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).