[Sussex] Distros

Tue Apr 5 00:08:16 UTC 2005

On Tue, 2005-04-05 at 00:33 +0100, Geoffrey J Teale wrote:
> Paul Tansom <paul at aptanet.com> writes:
> 
> > On Mon, 2005-04-04 at 18:16 +0100, Geoffrey J. Teale wrote:
> >> Paul Tansom <paul at aptanet.com> writes:>
> >
> > Well, no, from my reading of this thread, which is my only real
> > interaction with any information on the GFDL so far, I have come to the
> > same conclusion. If a GPL project creates documentation and wants this
> > documentation to be available to anyone who creates a derivative work
> > then the GFDL is not an option. If said hypothetical project wishes to
> > restrict the ability of any derivative work to quickly produce
> > documentation by forcing them to do it from scratch then the GFDL looks
> > good.
> 
> The GFDL would only force you to do it from scratch if it contained an
> invariant section that you did not want to pass on.  The reality I
> have been pointnig out is that the FSF's documentation released under
> the GFDL only contains invariant material that pertains to letter and
> spirit of the license under which the software is licensed anyway.
> Objecting to this material seems a little odd under the circumstances.

Unless I am reading the GFDL incorrectly, I disagree - well, the
situation I had in mind doesn't fit with that anyway:

Take project A which is GPL with GFDL documentation. Some of the
users/project members see a variation in the project that is not agreed
on in general. The power of the GPL allows them to take the project and
add/remove the parts as necessary to create the variation. Being pro the
concepts and spirit of the GPL (and adhering to it) they make their new
project and source available. Unfortunately, although say 60-80% of the
documentation would be reusable, and they would include suitable
acknowledgement of the original authors, etc., they cannot use project
A's documentation to create their own. The cover cannot be changed, so
it would reference the wrong project, the main body of the document
cannot be reused because it is not possible to pick the relevant chunks
out, only expand or correct them within the confines of being a revision
of the same document - which this is not, it is documentation for the
new project, not project A. The new project now falls foul of the big
criticism of free software projects - poor or no documentation.

If you are saying that the entirety of the document can be rewritten or
reused so long as the cover and other invariant sections remain in place
then so long as the new project is happy with the FSF invariant section
(which for the sake of argument we are) then so long as the new projects
documentation claims to be for project A on the cover (i.e. using the
same cover) and adds an addendum page within that states that the cover
is wrong, but required by project A's documentation to be left in place
because they are basing their documentation, where common, on the
original document, all will be well - if looking a little silly!

<snip>
> > To my mind the GFDL is a good license for publishers to release books
> > related to free software projects with a view that they will be or may
> > be made available electronically. It is friendly enough to be accepted
> > by the community for such a purpose. For documentation directly
> > distributed with free software projects in electronic format primarily
> > (although with the possibility of printing if desired) then I would
> > suggest a different license is more suited. If there are situations
> > relating to commercial use of documentation (as you have indicated) that
> > require specific formats, protections, or etc. then I would suggest that
> > projects looking at supporting this produce specific documentation - or
> > alternatively there is a documentation project that produces this for
> > multiple free software projects.
> 
> This places the duplication of effort upon the producers of the
> software who would have no problem with the license in first place
> (else they wouldn't have used it).

I'm more stating an opinion on its use and where I would personally see
it suitable for use than insisting that everyone does it this particular
way. The choice, as you say, is with the producers of the software -
they are free to choose proprietary documentation if they want :)

<snip>
> Unfortunately these tensions will always arise.  The FSF see Debian as
> not Free enough to recommend and Debian see the GFDL as not free
> enough to include.  All of this simply reflects the different goals of
> the two organisations.  Debian is a notebly good example of free
> software distribution, it's a shame that it can't go the final few
> steps but it's still streets ahead of many other mainstream distros in
> this regard.
> 
> > Personally I see the GFDL as an olive branch to the commercial world
> > (primarily publishing) to allow them to work with us, not something that
> > is of direct use internally. Of course that is my current view and I
> > don't say that it will always be so - I reserve my right to change my
> > mind with new evidence or re-evaluating existing evidence :)
> 
> As you should do. It's less of an olive branch and more of a
> compromise to make it possible to deal with these situations with
> undermining the greater goal of software freedom.  Debian have a more
> idealistic stance with regard to the principle of freedom in
> documentation, perhaps.

My reading is that they are looking to ensure their distribution (i.e.
CDs, etc.) does not have extra restrictions imposed on it by virtue of
less freedom being placed on the documentation required to use the
software than the software itself. If you included proprietary
documentation on the CD then this would suddenly limit some of what you
can do with the Debian distribution.

Don't get me wrong here, I am partly playing devils advocate (I am prone
to it!). I am seriously considering becoming an FSFE Fellow when funds
allow - one of the ways I can put back what I get out of free software.
I am one of those scrimping and saving and trying to eek out a living
from free software. Unfortunately that isn't easy unless you happen to
be employed by one of the big organisations and way too much of my work
is proprietary software driven. Arguably I could make more money by
churning out proprietary solutions. There would certainly be less
scrutiny and it may be easier to get the go ahead in many cases, in
spite of higher costs. In the end I believe customers are more satisfied
with the results - although pressure from vendors of proprietary
software that has to interact is getting tough to work with sometimes!

-- 
Paul Tansom | Aptanet Ltd. | http://www.aptanet.com/