Pros and cons of FSF

Pros and cons of FSF

[Jonathan Larmour]

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

Re: Pros and cons of FSF

[Andrew Lunn]

Hi Jifl

Many of the cons seem negotiable with FSF, depending on host strict
they are. Could you form a list of questions and see what they say?


     Andrew

Re: Pros and cons of FSF

[Jonathan Larmour]

Andrew Lunn wrote:
> Hi Jifl
> 
> Many of the cons seem negotiable with FSF, depending on host strict
> they are. Could you form a list of questions and see what they say?

In fact, one of the purposes was to create this list so I could easily see 
what the questions were :-).

Yes I can do it, but I'd like some buy-in that if the answers were all 
positive, this is something we would likely still want to pursue, given my 
summarising e-mail.

So are others (Gary, Nick, Bart, John, Mark) definitely interested in 
pursuing this if the answers are positive?

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: Pros and cons of FSF

[Gary Thomas]

On Thu, 2003-04-03 at 06:40, Jonathan Larmour wrote:
> Andrew Lunn wrote:
> > Hi Jifl
> > 
> > Many of the cons seem negotiable with FSF, depending on host strict
> > they are. Could you form a list of questions and see what they say?
> 
> In fact, one of the purposes was to create this list so I could easily see 
> what the questions were :-).
> 
> Yes I can do it, but I'd like some buy-in that if the answers were all 
> positive, this is something we would likely still want to pursue, given my 
> summarising e-mail.
> 
> So are others (Gary, Nick, Bart, John, Mark) definitely interested in 
> pursuing this if the answers are positive?

Yes.

n.b. after seeing all of the bickering that goes on the SPI
mailing lists, I'm not so sure that could ever work anyway.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: Pros and cons of FSF

[Mark Salter]

>>>>> Jonathan Larmour writes:

> So are others (Gary, Nick, Bart, John, Mark) definitely interested in 
> pursuing this if the answers are positive?

Yes for me.

--Mark

Re: Pros and cons of FSF

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Andrew Lunn wrote:
> > Hi Jifl
> > Many of the cons seem negotiable with FSF, depending on host strict
> > they are. Could you form a list of questions and see what they say?
> 
> In fact, one of the purposes was to create this list so I could easily
> see what the questions were :-).
> 
> Yes I can do it, but I'd like some buy-in that if the answers were all
> positive, this is something we would likely still want to pursue,
> given my summarising e-mail.
> 
> So are others (Gary, Nick, Bart, John, Mark) definitely interested in
> pursuing this if the answers are positive?
> 

It is certainly worth getting the answers. There are likely to be some
compromises and we need to see what those are before making a
decision. We don't really know yet which things the FSF consider
sacrosanct and which they are flexible on.


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

Re: Pros and cons of FSF

[Mark Salter]

>>>>> Jonathan Larmour writes:

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

I think all Red Hat employees are covered by a blanket assignment
to FSF. I'll check to make sure.

--Mark

Re: Pros and cons of FSF

[Jonathan Larmour]

Mark Salter wrote:
>>>>>>Jonathan Larmour writes:
> 
> 
>>* 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 :-|.
> 
> 
> I think all Red Hat employees are covered by a blanket assignment
> to FSF. I'll check to make sure.

It depends on the exact text certainly, because the default FSF assignment 
form explicitly lists the "Program" covered.

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