This is the mail archive of the ecos-maintainers@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]