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

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

[FSF General Contact Address]

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.

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.

It would not be problematic for Red Hat to hold copyright alongside FSF.

I believe the addresses all your questions and concerns.  Let me know what
you think about having eCos be part of the GNU project, and we will work
from there.  Of course, if you have further questions about what it means
to be a GNU program, or about copyright assignment, please feel free to
contact me.

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

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

[Jonathan Larmour]

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

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

[FSF General Contact Address]

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

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

[Jonathan Larmour]

I don't think there are any problems with the FSF's response other than, 
obviously, the documentation....

FSF General Contact Address wrote:
> 
> Such non-free documentation would be problematic, yes. 

So we can't even distribute the documentation with eCos even if it's not 
assigned to the FSF. The documentation is unfortunately IMO too important 
to lose. Most of it, including much of the RedBoot stuff, is pretty much 
irreplaceable really.

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

It seems that approaching Red Hat is back on the agenda (again!).

I think we need a definite decision now on this before we try to get Red 
Hat's permission to assign copyright or relicense the docs under the FDL. 
If Red Hat don't oblige I believe we have consensus that the only feasible 
alternative is dropping assignments (but retaining a disclaimer).

There probably isn't any sensible way to do this other than a vote, and 
there are 7 of us so no worries about a tie... so is this categorically 
what everyone agrees with? Please reply ASAP, as I'd like to get the ball 
rolling with Red Hat ASAP. Vote on 
ecos-maintainers-private[at]ecoscentric.com if you prefer.

I vote to go ahead with Red Hat, but if that fails, drop assignments but 
retain a disclaimer.

Something else to think about is whether we should plough ahead with 2.0 
final anyway, or wait till we hear from Red Hat, or at the very least wait 
for some time period for Red Hat. For "just" the documentation, they will 
hopefully be amenable to an accommodation - it's not like the FSF are an 
unknown quantity! Something to consider anyway, and it's obvious we can't 
wait with 2.0 going stale, so I suggest a drop dead date, which we 
wouldn't be real close anyway, as there are still some outstanding 2.0 issues.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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

[Andrew Lunn]

> I vote to go ahead with Red Hat, but if that fails, drop assignments 
> but retain a disclaimer.

Agreed.

> Something else to think about is whether we should plough ahead with 
> 2.0 final anyway, or wait till we hear from Red Hat, or at the very 
> least wait for some time period for Red Hat. For "just" the 
> documentation, they will hopefully be amenable to an accommodation - 
> it's not like the FSF are an unknown quantity! Something to consider 
> anyway, and it's obvious we can't wait with 2.0 going stale, so I 
> suggest a drop dead date, which we wouldn't be real close anyway, as 
> there are still some outstanding 2.0 issues.

Make the 2.0 release when its ready independent of what's going on
with FSF, assignment etc. 

2.1 can be with the changes for FSF. Hopefully, when releases are
closer together there is much less work involved in making a release.

       Andrew

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

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> 
> I vote to go ahead with Red Hat, but if that fails, drop assignments
> but retain a disclaimer.
> 
> Something else to think about is whether we should plough ahead with
> 2.0 final anyway, or wait till we hear from Red Hat, or at the very
> least wait for some time period for Red Hat. For "just" the
> documentation, they will hopefully be amenable to an accommodation -
> it's not like the FSF are an unknown quantity! Something to consider
> anyway, and it's obvious we can't wait with 2.0 going stale, so I
> suggest a drop dead date, which we wouldn't be real close anyway, as
> there are still some outstanding 2.0 issues.
> 

I don't think we should hold up 2.0 for this issue -- release it when
it's ready on technical grounds.

While I am reluctant to have to go back and interact with Red Hat
again -- mainly because of the delay it will cause. I guess we should
at least try this. I doubt it will come to much though.

If (when!) the Red Hat approach fails then I would vote for dropping
assignments and accepting the consequences.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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

[Bart Veer]

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    Jifl> I don't think there are any problems with the FSF's response
    Jifl> other than, obviously, the documentation....

    Jifl> FSF General Contact Address wrote:
    >> 
    >> Such non-free documentation would be problematic, yes. 

    Jifl> So we can't even distribute the documentation with eCos even
    Jifl> if it's not assigned to the FSF. The documentation is
    Jifl> unfortunately IMO too important to lose. Most of it,
    Jifl> including much of the RedBoot stuff, is pretty much
    Jifl> irreplaceable really.

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

    Jifl> It seems that approaching Red Hat is back on the agenda
    Jifl> (again!).

One possibility is to have the FSF approach Red Hat on this, rather
than us. A message from RMS or some other senior FSF person is likely
to get a more rapid response than yet another message from us.

    Jifl> I think we need a definite decision now on this before we
    Jifl> try to get Red Hat's permission to assign copyright or
    Jifl> relicense the docs under the FDL. If Red Hat don't oblige I
    Jifl> believe we have consensus that the only feasible alternative
    Jifl> is dropping assignments (but retaining a disclaimer).

    Jifl> There probably isn't any sensible way to do this other than
    Jifl> a vote, and there are 7 of us so no worries about a tie...
    Jifl> so is this categorically what everyone agrees with? Please
    Jifl> reply ASAP, as I'd like to get the ball rolling with Red Hat
    Jifl> ASAP. Vote on ecos-maintainers-private[at]ecoscentric.com if
    Jifl> you prefer.

    Jifl> I vote to go ahead with Red Hat, but if that fails, drop
    Jifl> assignments but retain a disclaimer.

I vote to go ahead, but suggest a slightly different approach:

1) get confirmation from the FSF that the license exemption (or
   something equivalent) will be preserved in future. Unless we get a
   guarantee we should not go ahead.

2) have the FSF approach Red Hat about the documentation license,
   which can be done in parallel with (1).

    Jifl> Something else to think about is whether we should plough
    Jifl> ahead with 2.0 final anyway, or wait till we hear from Red
    Jifl> Hat, or at the very least wait for some time period for Red
    Jifl> Hat. For "just" the documentation, they will hopefully be
    Jifl> amenable to an accommodation - it's not like the FSF are an
    Jifl> unknown quantity! Something to consider anyway, and it's
    Jifl> obvious we can't wait with 2.0 going stale, so I suggest a
    Jifl> drop dead date, which we wouldn't be real close anyway, as
    Jifl> there are still some outstanding 2.0 issues.

I believe 2.0 final should be independent of all this. Right now we
want to concentrate on getting 2.0 final out, not address other issues
like removing gifs.

Bart

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

[Jonathan Larmour]

Bart Veer wrote:
> 
> I vote to go ahead, but suggest a slightly different approach:
> 
> 1) get confirmation from the FSF that the license exemption (or
>    something equivalent) will be preserved in future. Unless we get a
>    guarantee we should not go ahead.

I know Brett said he was working on getting this. I would like to hope 
this wouldn't be an issue.

> 2) have the FSF approach Red Hat about the documentation license,
>    which can be done in parallel with (1).

Okay, it appears we have some consensus: not letting it delay 2.0 is 
certainly decisive.

Given Bart's suggestion, I'll take a two-pronged approach, which is to 
approach directly but if there's no reply very soon (as is likely), ask 
the FSF to do it directly as well.... attack from all sides ;-). I intend 
to mail Tony Moretto, Mark Webbink, and also this time, Michael Tiemann, 
and hopefully we can work something out. I'll CC this list of course.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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

[FSF General Contact Address]

Dear eCos team,

About a month ago, you wrote to us with interest in becoming part of the
GNU project, and questions about what would be necessary to do so.  I have
not heard from you since.  If you could just let me know what has come of
this so far -- if you've come to a decision one way or the other, have
further questions, are still considering the issue, or whatever else -- I
would appreciate a quick note.

If it is of any help, I would like to point out that we would be happy to
help negotiate copyright and licensing issues with Red Hat, particularly on
the documentation, if we are able to obtain copyright on the software.

Also, if you have not yet made a decision, I would appreciate if you could
answer a quick question of ours.  We were wondering if people use GNU
software with eCos -- have a GNU/eCos system, in other words -- and if so,
how common it is to use GNU software with eCos.  Any examples of such
systems you could refer us to would be helpful as well.

I look forward to hearing back from you soon.

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

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

[Jonathan Larmour]

FSF General Contact Address wrote:
> Dear eCos team,
> 
> About a month ago, you wrote to us with interest in becoming part of the
> GNU project, and questions about what would be necessary to do so.  I have
> not heard from you since.  If you could just let me know what has come of
> this so far -- if you've come to a decision one way or the other, have
> further questions, are still considering the issue, or whatever else -- I
> would appreciate a quick note.

No problem. We are indeed keen to go forward with this.

> If it is of any help, I would like to point out that we would be happy to
> help negotiate copyright and licensing issues with Red Hat, particularly on
> the documentation, if we are able to obtain copyright on the software.

The issue is indeed the documentation currently under the Open Publication 
Licence. If you can bring what influence you have to bear on this it would 
be great. Right now, despite sending to a range of people, with several 
reminders, I've been quite disappointed to receive absolutely no response, 
not even an acknowledgement.

If you could contact whoever you feel would be best to help, please do so, 
and if we can help with this in any way, just ask.

Just for the avoidance of doubt, by the way, as discussed before, we are 
unable to do anything about Red Hat's copyright on the software, but, 
since the current licence is GPL+special exception, that was okay by the 
FSF.... in future the software would end up being dual licenced FSF and 
Red Hat. Of course it would be pointless for Red Hat to maintain their 
copyright in such a situation, but there's little we can do about that.

> Also, if you have not yet made a decision, I would appreciate if you could
> answer a quick question of ours.  We were wondering if people use GNU
> software with eCos -- have a GNU/eCos system, in other words -- and if so,
> how common it is to use GNU software with eCos.  Any examples of such
> systems you could refer us to would be helpful as well.

I've heard very isolated examples of GNU software being used with eCos, 
but not really many yet as a) we were only GPL compatible until just over 
a year ago and previously were explicitly incompatible (and haven't had a 
major release since that change until right now!); and b) we've still to 
provide some of the more common system infrastructure components that GNU 
systems provide.... remember that in our world, we don't even always have 
filesystems! We intend to redress this "shortly", but of course as ever 
it's a volunteer effort :-).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine