public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* Pros and cons of FSF
@ 2003-04-03  4:02 Jonathan Larmour
  2003-04-03  8:29 ` Andrew Lunn
  2003-04-03 13:08 ` Mark Salter
  0 siblings, 2 replies; 8+ messages in thread
From: Jonathan Larmour @ 2003-04-03  4:02 UTC (permalink / raw)
  To: eCos Maintainers

To help us all reach a conclusion, I'll just try and collate a list of 
what I see and can think of as the pros and cons of going with the FSF, 
which means becoming a GNU project. Please add to this if you think of 
anything I've missed (and I've got a strong feeling I have):

Pros
----

* The obvious and biggest thing: We get to choose the legally safer route 
of keeping copyright assignments, with all the aforementioned advantages 
of legal protection, licence enforcement, and the possibility of fixing a 
broken licence down the road (with RH's agreement).

* FSF handle copyright assignments. Well established.... it will "just 
work". Also everyone knows what to expect with an FSF assignment - not 
just random entity that may or may not be trustable. Unlike a commercial 
company owning or retaining copyright, they wouldn't stab us in the back 
down the road!

* A badge of honour for a free project. A GNU project commands respect and 
a certain amount of kudos; and that also means other GNU projects like GCC 
and GDB have to pay more attention to us and give us consideration

* We also get a little bit more publicity as a result.

* Get GNU resources and infrastructure, e.g. setting up ecos.gnu.org to 
point to s.r.c if we wanted (and I would be strongly in favour of this), 
savannah.gnu.org services may also be useful; ftp.gnu.org and mirrors too.

* (Yes I'm listing this as a pro :-)) Move towards consistently using the 
GNU coding standards for all new work.

Cons
----

* Loss of control. FSF may get the final say on some things. I know that 
sometimes when the FSF and, say, the GCC steering committee have disagreed 
sometimes the SC has in fact won... after all, if everyone else disagreed 
there is a risk of a fork. But for some decisions, we may just have to toe 
the FSF line. I know we wouldn't be happy about losing autonomy. However 
against that, the FSF and RMS in particular won't in general (frankly) be 
all that interested in eCos and will probably try to be as hands-off as 
possible.

* If we have queries on whether something is acceptable or not in the 
repository for legal reasons, the FSF may have a harder line than we 
would. In border line cases we should refer to FSF legal.

* Changing Linux to GNU/Linux throughout

* Changing GIFs to PNGs throughout.

The above two we would hopefully be able to argue for a gradual ongoing 
changeover rather than a big bang.

* We use the Open Publication Licence rather than the FSF's preferred Free 
Documentation Licence. However since that's partly (C) Red Hat, we can't 
change the licence. The FSF will have to take it as a precondition IMHO 
since there's nothing we can do. Entirely new documentation will probably 
be FDL, but there's no issue with that IMO.

* Bureaucracy overhead of assignments for contributors remains

* Some companies may not like assignments, e.g. big ones with first 
initials beginning with I. Perhaps it would be possible to make them a 
very special case as long as their changes are confined to their own 
platform HALs, but then we may not have the power to make such decisions 
with the FSF! If we could persuade compny-beginning-with-I to put things 
in the public domain instead, I see from 
http://www.gnu.org/prep/maintain_5.html#SEC5 that this would be acceptable 
to the FSF.

* Maintainers doc includes stuff we don't want like having to set up a 
bug-ecos[at]gnu.org mailing list - which won't be spam filtered, and it's 
well known bug*@gnu.org lists attract masses of spam. So given our 
preferred route remains bugzilla, the S/N ratio will be abysmal. Perhaps 
as a well established project we can argue against this.

* Maintaining an "AUTHORS" file allegedly according to 
http://www.gnu.org/prep/maintain_7.html#SEC7 although neither GCC nor GDB 
have this, so I'm not sure this is a hard requirement. It would certainly 
be a bit silly given how much water has already flowed under the bridge.

* I'm sure we can argue against 
http://www.gnu.org/prep/maintain_16.html#SEC16 (and almost definitely 
http://www.gnu.org/prep/maintain_16.html#SEC17) given existing established 
practice, particularly with preferentially distributing the host tools in 
binary format (although obviously the source is available).

* As per http://www.gnu.org/prep/maintain_22.html#SEC22 "A GNU package 
should not recommend use of any non-free program, nor should it require a 
non-free program (such as a non-free compiler or IDE) to build." which 
definitely means the config tool will need to be built with cygwin, not 
MSVC++, which JLD is actively working on. Also "a GNU package cannot be 
written in a programming language that does not have a free software 
implementation." which could constrain e.g. acceptable java 
implementations (GCJ, Kaffe and wonka support good, support for non-free 
JVMs bad).

* The FSF will never give up their copyright under any circumstances even 
if there was some very good reason. Similarly, the licence will never be 
any weaker than it is now. There is an outside chance the FSF may insist 
we remove the GPL exception clause down the road.

* An unanswered question: will Red Hat developers need to make sure there 
is an assignment to the FSF? Or will it be okay to just do stuff since 
there's already more than enough RH copyright so a little more won't make 
much difference. I suspect the FSF may insist on the former, but if so, 
would that be acceptable to Red Hat? This may make life very difficult for 
developers in Red Hat :-|.

Pro *and* Con
-------------

* eCos must be truly vendor neutral. We've already been choosing this 
path, but the exact details of what is or isn't acceptable may now 
ultimately be decided and policed by the FSF, not us. Their view of what 
is or isn't fair credit and recognition may be different from ours, even 
if we had 100% consensus. The advantage is that it helps lift the burden 
of worrying about conflicts of interest a little, but at the expense of 
genuinely due recognition.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2003-04-03 17:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-03  4:02 Pros and cons of FSF Jonathan Larmour
2003-04-03  8:29 ` Andrew Lunn
2003-04-03 13:40   ` Jonathan Larmour
2003-04-03 13:53     ` Gary Thomas
2003-04-03 13:55     ` Mark Salter
2003-04-03 17:12     ` Nick Garnett
2003-04-03 13:08 ` Mark Salter
2003-04-03 13:36   ` Jonathan Larmour

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