[Sussex] Distros

Tue Apr 5 10:08:07 UTC 2005

On Tue, 2005-04-05 at 07:29 +0100, Geoffrey J Teale wrote:
> Paul Tansom <paul at aptanet.com> writes:
> > 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.
> 
> Hmm, yes, to an extent what you are saying is true, although it is
> also something that is definitively _not_ the spirit of the GPL.  The
> GPL doesn't intend for people to take someone elses work, change it's
> name and then redistribute it as being an entirely new work.  The
> limitation on changes to the cover text (which can be changed to some
> extent) and details of authorship are simply forcing people to "play
> fair".

I thought that was precisely in the spirit of the GPL. The GPL provides
the ability to take and modify a piece of software to suit your purposes
should it not already do so - so long as you share your modifications
with everyone in the same manner. Thus if an application has features
you don't need and lacks some you do causing you to modify it, it is in
the spirit of the GPL (and the letter) for you to share that work (I
believe that for your own use and nobody others you may stick within the
letter to keep it to yourself, but that is clearly not within the
spirit). Should you wish to continue to maintain your work then there
will be future updates that also need to be published - either mirroring
changes within the original work, taking updates of the original work
and re-applying your changes, or updates directly of your own. Trying to
do this from within the original project that did not require or want
the changes in the first place is not practical and likely to cause
aggravation, so publishing independently is the only option. Should the
modified version be a significant modification it is likely to take a
new name for clarity rather than play on the name of the original
project unfairly. At no point in this process have I advocated
deliberately taking the work and creating a new project for the sake of
it, or failing to credit the original project and authors.

> The case where they "cannot use" the documentation falls into two
> categories:
> 
>   1. Where someone has added an invariant section that they disagree
>      with (by implication this should not happen with the FSF's docs).
> 
>   2. Where the new project is unwilling to give credit to the original
>      authors of both the code and the documentation (which is frankly
>      contrary to the spririt of free software).
> 
> I'll freely admit that bodies other the FSF might cause problems under
> case 1.

OK, I think I'm going to have to go back and read some of the thread
again and/or the GFDL specification itself. At one point in the thread I
concluded that the invariant sections were only creatable by the
original authors (although this almost implies only on first draft which
seems somewhat restrictive, but the original authors could create a new
document by virtue of being the copyright holders). Later and before
that I concluded that invariant sections could be added by anyone at any
point. Should this be the case the somebody could take some FSF
documentation, add some extremely useful technical content and at the
same time a new invariant section that states that, for example, the
views in the original invariant section are contrary to the American
Constitution and human rights and that proprietary software is the only
safe way to go should you want secure and reliable software. From here
on in (I'll reiterate that being an example!) should you wish to make
use of the, perhaps large quantity, of superb new documentation you have
to keep the invariant section. The alternative is to rewrite and
continue from a previous release, but you still have a copy being
distributed with the FSF cover texts and anti FSF invariant.

All of course fitting within freedom of speech/expression and within the
GFDL. This is of course only a license and can be used for whatever
purpose you wish.

Playing devils advocate can be a bad move sometimes :)

> > 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!
> 
> I'll say again, the cover isn't totally invariant.
> 
> The GFDL define the cover text as:
> ==========================================================================
> The "Cover Texts" are certain short passages of text that are listed,
> as Front-Cover Texts or Back-Cover Texts, in the notice that says that
> the Document is released under this License. A Front-Cover Text may be
> at most 5 words, and a Back-Cover Text may be at most 25 words.
> ==========================================================================

OK, that bit I've obviously missed, so the resulting project could have
a cover with the invariant cover text:

"This is the documentation for Project A"

and a new invariant section:

"This is not in fact the documentation for Project A as stated below,
but for Project B which is a derivative work."

and if they were being really bl**dy minded about licensing:

"The reason for the confusing claim that this is documentation for
Project A is the fact that the original documentation was published
under the GFDL and we cannot change the title to something like 'This is
the documentation for Project B, which is a derivative work of Project
A' because they put the title in as an invariant section."

OK, being really awkward there, I would hope that people would see sense
and keep the invariant sections to things like credits and the like, but
the GFDL does seem flexible enough to create problems, but not flexible
enough to correct them. That said I think I'm warming to it slightly.
Originally I could see only commercial uses for it. Still yet to be
fully convinced though!

> And later..:
> 
> ==========================================================================
> If you publish printed copies (or copies in media that commonly have
> printed covers) of the Document, numbering more than 100, and the
> Document's license notice requires Cover Texts, you must enclose the
> copies in covers that carry, clearly and legibly, all these Cover
> Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
> the back cover. Both covers must also clearly and legibly identify you
> as the publisher of these copies. The front cover must present the
> full title with all words of the title equally prominent and
> visible. You may add other material on the covers in addition. Copying
> with changes limited to the covers, as long as they preserve the title
> of the Document and satisfy these conditions, can be treated as
> verbatim copying in other respects.
> ==========================================================================
> 
> Yes this means you cannot pass the document off as being something
> other than a variant of the original document, but you can make quite
> significant changed to the cover to indicate it is a variant belonging
> to the new project.

Hmm, loosing me again, notable with the section "as long as they
preserve the title of the Document". I'm back towards the view that this
is a good document for published works about free software, but not
suitable for documentation of free software. This should be more closely
aligned to the license it is published under (taking this to be the GPL
for arguments sake). Should somebody wish to take GFDL'd documentation
and use sections of it within the inline documentation for a project you
run into license clashes and the requirement to get the documentation
authors approval to do so (hopefully not too difficult since they should
be closely related to the project).

> <snip>
> > 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.
> 
> I feel describing the GFDL documentation as propietary is a little
> extreme, but I can see the point entirely.

My intention was not to describe the GFDL as proprietary, but to compare
some of its restrictions as heading down the path towards some of the
limitations of a proprietary license.

> > 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.
> 
> Good stuff.
> 
> > 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!
> 
> Keep up the good work.  If anything the restriction the FSF have built
> in to the GFDL are there to promote freedom in a way that should
> ultimately benefit people like you.  I hope that will be my last word
> on the subject.

With any luck my last word in the thread too. Rather a sudden
introduction to a LUG list I've been lurking on for a bit! I can see
potential uses for the license, and may use it myself. I don't see it as
suited to all the purposes the FSF do though. I can see the opportunity
to write third party documentation for free software projects that would
not be able to be copied or passed off as another persons work with only
small credit to the original author. This is a good thing for publishing
and original authors as you say, since people are free to improve on the
document but not copy great chunks. It is slightly at odds with the GPL
spirit, but for commercially published work (not necessarily paid for,
but published with a commercial reason, be that as some form of free
advertising or to promote your own writing, etc.) it is useful. I would
still stick with the view that documentation for a project that should
be included with the application during distribution would be best to
avoid the GFDL. A complimentary manual published by the project would
likely work quite well under it since it is not necessarily something
that should be distributed with the code. That said this would still
leave Debian not including the manuals.

For my part the jury is still out on this one though :)

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