This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Pros and cons of FSF
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: eCos Maintainers <ecos-maintainers at sources dot redhat dot com>
- Date: Thu, 03 Apr 2003 05:02:22 +0100
- Subject: Pros and cons of FSF
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* at gnu dot 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