[FM discuss] kicking off

[adam hyde]

ok!

seems everyone is subscribed sans Derek and plus Luka :)

So, let me kick the ball off...firstly, thanks so much to you all for
agreeing to joining the list. I would really like to evolve FLOSS
Manuals (fm) and there are many interesting and exciting avenues, your
help in doing this by being part of this list is really appreciated.

Secondly, I am sorry this email is rather long. Its necessary to get the
breadth of the topics across...so my appologies, future emails will be
shorter.

The last weeks I have found myself researching sustainable financial
models and tweaking the site to fit one interaction model or the other,
and I have come to the point I really need some feedback and since you
all have familiarity with fm and I think we are all more or less on the
same wavelength then I thought it would be great to open the discussion
up to to get your ideas and input. 

So.... there are two issues at the moment that have caused me to sway
from one argument to the other...they have to do with licensing and the
the contributing process. I will start with the licensing and follow it
up once the discussion is rolling with the issues about site
interaction...

Licensing
At the moment all docs in the repository are GPL. The FDL turned out to
be nasty. In fact I wrote something up for the floss rss here :
http://en.flossmanuals.net/bin/view/Blog/LicenseChange#BlogPosts

The main issues with the FDL are that :
* its hard to implement
* its written as if for a book (refering to title pages, covers, history
section)
* its hard to modify manuals using it (you must change the title
everytime you make a modificaiton)
* it has very arbitary clauses about the permissable number of copies
etc, 

for example, take this clause :
"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...." (etc)

as the above text illustrates, the license is written for books and
specifically is written to _protect the interests of a book publisher_.
The FDL has this bizarre rationale: "Meanwhile, the GFDL has clauses
that help publishers of free manuals make a profit from selling
copies--cover texts, for instance."
http://www.gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals

I wrote to Richard Stallman about my concerns. I did this as the FSF is
undergoing a revision process for the GPL and FDL and I thought they
might head in a more reasonable direction. I had first asked a
Amsterdam funder for some money to get a lawyer to write a submission
to the FSF, but first i thought it would be good to test the
water....unfortunately I got a two line answer from rms that said
'i am sorry i do not agree'...since the FSF is pretty much steered by
the personality of rms (or so it seems to me) I don't hold much hope
the FDL will sober up.

Just to be clear - I'm not against anyone making a money (FLOSS Manuals
itself has to make some money else it won't progress very fast), but the
idea that a business model should be inherent in the license is very
weird. Anyways...so everyone agreed we should go with the GPL with some
reservations about its appropriateness. Derek specifically was
concerned that the GPL was focused on programs. It is true, however the
FSF itself says the GPL can be applied to 'any other work', and that
seems to cover that issue for now.

More to the point, documentation is often part of a program and it
would be nice if the documentation created in fm could be included in
source code for distribution. This has happened already with Linphone
including a page of the fm linphone manual in its man pages. the
developer was very happy to not have to include another license in the
sources.

So...the issue that is bugging me at the moment is this...the GPL is
fine I think, and appropriate, and has some advantages over the FDL. It
also keeps the info free, which is cool. However it has a few
disadvantages...namely:
* it is hard to understand if you never saw it before
* inorder to use it in a manual all manual content in that manual must
be GPL...not many manuals use the GPL...

so, these two issues, I believe, make it hard for users that want to use
the content in webpages and it seems others think so too..

A member of the Audacity documentation project team (Gale Andrews) has
said in an email exchange we had discussing the license status of
audacity documentation that Dominic Mazzoni, the project leader for
Audacity, is thinking all documentation for Audacity will use (in the
future) the Creative Commons Attribution 3.0 license (it is currently
GPL'ed). Specifically because they find the GPL to verbose and
unwieldly.

I'm not sure, but I think their thoughts lie with the people that want
to use the docs in their own websites...these are commonly people that
would be across CC licenses but may not have heard of the GPL. 

Further...I am very unclear if the GPL would require anyone that used
the content from fm in a webpage would actually require the page
(website?) to also be gpl'ed....(as per section 10 of the GPL:
 "10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission" )

so...what are the options. The options that seem open to me are:
1. leave everything with the GPL
2. dual license

The first option means fm lives with the GPL. Option 2 means that all
content is dual licensed with the GPL and perhaps the CC by 3.0 or cc
by-sa 3.0 (http://creativecommons.org/licenses/by-sa/3.0/). The later
meaning the content should always be credited, and free and licensed
under a compatible license.

Dual licensing means the user can decide under which of the licenses
offered they will choose to modify and redistribute the material. So in
this scenario a developer might use the GPL to include the docs in their
code, while a webby would use the CC as its easy to use and they
probably are more familiar with how to use it, and it seems to fit www,
textual, and print paradigms better.

Dual licensing has previously had a bad name as it has been used to dual
license free software under a closed license so that vendors can use it
in proprietary apps. The world is getting used to this a little now it
seems to me, but anyways, i don't think that this criticism would apply
to fm as we would be dual licensing not to keep the code closed, but to
keep the documentation free and easy to re-use.

so...I keep flittering between the 'just keep it gpl'...and 'switch to
dual licensing'....

I would really appreciate your comments here...


adam







-- 
adam hyde
floss manuals

free manuals for free software
http://www.flossmanuals.net

mobile : + 31 6 154 22770 (Netherlands mobile)
email : adam at flossmanuals.net