Re: Issues cooperation

[Federico Mena Quintero <federico ximian com>]

On Wed, 2002-11-27 at 01:36, Richard Stallman wrote:

> There are several specific points where better cooperation between
> GNOME and the overall GNU Project is important.
> 
> * Mentioning the connection with GNU prominently in GNOME publicity.
> (More awareness of the GNU Project helps us recruit and influence
> people, which is a major part of how we get things done.)

Our home page advertises GNOME to be part of the GNU Project, and as far
as I know most of our printed literature (brochures and the like) have
included similar content.  If particular instances don't mention it,
then it is likely an oversight of whoever made the brochure.  Please
understand that for user-organized conferences, it is mostly overworked
people who make the brochures at the last minute and oversights cannot
be avoided.  This is just an organizational issue, as always. 
Unfortunately we cannot send every single document up the hierarchy so
that every person can check it.

> * Giving the GNU Project credit for developing the popular variant of
> the GNU system, GNU/Linux.  (This will help us recruit support among
> the tens of millions who use and appreciate our system, but think it
> was done by someone else.)

I think we use "GNU/Linux" everywhere within the GNOME web pages and
distributed documentation.  If you find particular instances where this
is not the case, it would be most helpful to send a patch to the culprit
file.  I don't think anyone is making a conscious effort to divert from
the standard practice within GNOME, which is to use "GNU/Linux" when
talking about the whole system and just "Linux" when talking about the
kernel.

> * Whether to recommend non-free software.  To do so publicly rejects
> the fundamental important principle of the GNU Project.

I don't think we have ever recommended the use of non-free software.  If
the concern is the software map, then let's see.

This page lists all the items in the software map that are classified as
"Other/proprietary license":

	http://www.gnome.org/softwaremap/list/form_cat/196

It has four items, namely:

1. GARNOME: a distribution of GNOME.  Listed under "Other" because the
particular licenses of each project are different.

2. General GNOME User Documentation:  Listed under "Other" because it
uses the GNU FDL.  We don't have a toplevel category for the FDL.

3. ggobi: Listed under "Other" because its components have different
licences:  AT&T Open Source License, GPL, BSD, LGPL.  I don't know if
the AT&T one qualifies as free software.

4. Gibbon: Listed under "Other" because its components are a mixture of
LGPL and the phpShop license.  I just skimmed through the latter very
quickly and I *think* it may have an advertising clause.  Can you please
determine if this is true?

So the first two are of no concern.  The second two require
clarification --- the main code of those projects is released under free
licenses, but they may depend on non-free software.  I don't think that
makes the projects themselves non-free by themselves.

> * Technical standards.  Coherence is vital for making an operating
> system easy to learn, use, and maintain, so we have had GNU Coding
> Standards since the 1980s.  GNOME has a history of going contrary to
> GNU standards--without even discussing the issue first.

I amm going to go point by point through the GNU Coding Standards as per
the content in the info nodes.

* Preface: No issues here, of course.
        
* Keeping free software free:
        
        * Referring to proprietary programs:  I don't think anyone has
        referred to proprietary source code while developing for GNOME. 
        It would be really dangerous to do so.  If you know of
        particular instances of this happening, please do tell us.
        
        * Accepting contributions:  This is copyright assignment
        papers.  We have been as guilty here as pretty much every other
        free software project.  However, work is underway within the
        GNOME Foundation to request copyright assignments from
        contributors to the core GNOME packages.
        
* General program design:

        * Compatibility with other implementations:  GNOME has no clones
        of Unix utilities, but rather a mish-mash of features copied
        from graphical applications in other platforms.  I think the
        most "compatible" application is the Gnumeric spreadsheet, which
        consciously copies features from Microsoft Excel, for obvious
        reasons.  So yes, we are compatible with existing software.
        
        * Using non-standard features:  Most GNOME software is not so
        low-level for these recommendations to apply.  We already depend
        on a base GNU system to work, and we use GNU extensions when
        appropriate.  For example, the core Glib library will use GCC
        extensions if it is built with GCC, and it won't use them if you
        build it with another compiler.
        
        * ANSI C and pre-ANSI C:  We don't support pre-ANSI compilers. 
        This isn't terrible in 2002 :)
        
        * Using languages other than C:  We use Guile, Python, and Perl
        in applications occasionally.  GNOME does provide the basic
        interfaces between these languages and the applications (e.g.
        toolkit bindings).  I guess the recommendation from the GNU
        standards applies more to low-level system utilities rather than
        large applications; for the latter ones it would be impractical
        to do everything in C.
        
* Program behavior for all programs:  This is a tremendously useful
section on how to write programs that behave in a standard way.  We do
recommend the use of these standards in the GNOME Programming
Guidelines:
	http://developer.gnome.org/doc/guides/programming-guidelines/book1.html

  The GNOME Programming Guidelines themselves reiterate some of the
points made in the GNU standards.  Please read them and tell us if they
include any dubious advice.

* Making the best use of C:  Again, a very useful section on how to
write C programs in a good style --- using meaningful names for
variables and functions, structuring code in a good way, etc.  The GNOME
Programming Guidelines repeats some of this advice and expands on it. 
The only difference is that GNOME prefers to use K&R indentation for C
with 8-space tabs, whereas the GNU standards prefer to use braces in
their own line, indented 2 spaces, and with extra indentation for the
code inside.  I'm sure that indentation is not a matter worthy of
strife; fortunately GNU Emacs makes it very easy to deal with either
style of code.

* Documenting programs:  The main difference between the GNU standards
and the GNOME conventions is that the former recommend texinfo as a
documentation format, while the latter use DocBook SGML.  We have
discussed this in the past and determined that DocBook is a better tool
for GNOME --- it allows inclusion of graphics and other media types, and
can be converted into other documentation formats if necessary, texinfo
among them.  Apart from that and in compliance with the GNU standards,
we do use NEWS files to list user-visible changes and we do use
ChangeLog files for developers.  Most GNOME programs do not come with
man pages, which are secondary as per the GNU standards.  GNOME
documentation is released under the GNU FDL.

* The release process:

        * How configuration should work:  We do use GNU autoconf which
        automates the cration of the "configure" script.
        
        * Makefile conventions:  We do use GNU automake, so again we
        have the standards covered.
        
        * Making releases:  Our tarballs are of the form that automake
        allows, which is compliant with the GNU standards.
        
That is all.  I don't see where GNOME goes contrary to the GNU standards
except for copyright assignment.  The GNOME Foundation's lawyers are
currently revising our code contribution papers that relate to copyright
assignment, so this should be better in the short term.

HTH,

  Federico