Open Letter to Richard Stallman

Posted 4 Nov 2008 at 21:52 UTC by cdfrey Share This

Dear Mr. Stallman,

I am writing to express my disappointment with the Free Software Foundation regarding the recent release of the GNU Free Documentation License version 1.3.

The new version 1.3 adds a new clause, section 11, which, according to the FAQ, allows wiki sites to relicense specific content from GFDL 1.3 to CC-BY-SA 3.0, for content added before November 1, 2008. They have this relicensing option until August 1, 2009.

This, in my view, is a serious moral mistake and breach of trust. Even if this new clause does no harm, it is still the wrong thing to do.

Many years ago, I read criticisms about the recommended way of applying the GNU GPL license to software. People criticized the common phrasing "version 2 of the License, or (at your option) any later version," saying that this gave the FSF too much power, and was basically writing a blank cheque to possible future abuse of one's work.

This criticism began to hold less weight for me when I witnessed the extreme care and meticulous and open process of writing the new GPL version 3. All comments were logged and processed in a website in an extremely open fashion. The process was long and cautious, balancing the opinions of users of the license with the commitment to Free Software. It was a thing of beauty.

I started to see the benefits of having an open ended license. I saw the direction that the FSF took. They did not loosen the grip on Free Software principles, they tightened it. And since only the FSF could change the GPL, and given their trustworthy method used to update it, it seemed like a worthy place to put my trust.

Unfortunately, this seemingly hasty change to the GFDL undoes all that. Not only does it violate the assumption that the author of the work decides what license to use, it adds another party to the equation. Not only can the FSF now change the terms of the GFDL, the Creative Commons Corporation can now change the terms that some older GFDL work is licensed under.

Fortunately this only lasts until August 1, 2009. But old GFDL wiki content is basically dual licensed now.

Perhaps I was living under a legal rock, but I also didn't see any announcement for public input to this revision. If I did miss it, I regret not being able to give my feedback earlier in the process. If the input cycle was shorter or non-existent, this is a flaw in the update process of the GFDL, which I hope the FSF will fix.

In practical terms, the relicensing is not that big a deal. The restrictions on what can be relicensed are good, and it is basically swapping one set of legal boilerplate for another that does the same thing. Some authors may have specifically chosen the GFDL over CC-BY-SA, for various reasons, one of them being the fact that the license had to be copied along with the work. This part of the GFDL is both a feature and a bug. But this specific choice, which was previously up to the author, is now gone.

In the greater scheme of things, very little harm is probably done. Indeed, many have hailed this change as a great improvement. I suspect that the most harm is simply done to the FSF's reputation. The problem is the message this sends to users of other FSF licenses. Can we trust the FSF not to allow relicensing of our works, to non-FSF licenses, if we use the "future version" clause? In the past, I would have been confident that this was the case. Now I'm not so sure.

I look forward to hearing your thoughts on this, and if you like, I will post your reply verbatim in the same places I post my letter.

Thank you for your time.


Chris Frey

missing the point, posted 5 Nov 2008 at 00:41 UTC by jbuck » (Master)

The GFDL is widely considered a flawed license, and I doubt if you will be able to find actual copyright holders that used that license but that have a moral objection to CC-BY-SA.

In fact, many contributors to GFDL documents object to the GFDL, but are pretty much forced to use it because they contribute to GNU projects. If anything, most of us were hoping for more changes, not fewer changes. We still have the invariant sections issue and the flawed DRM language (which would appear to be make "chmod 600 gfdl_doc.pdf" illegal on a multi-user system).

Copyright holders who care about the legal details can specify a specific version number; those who care only that a work be free usually don't care about those details and are unlikely to care about the distinctions between GFDL with no invariant sections, and CC-BY-SA.

practical vs. principle, posted 5 Nov 2008 at 07:39 UTC by cdfrey » (Journeyer)

I agree that in a practical sense, little has changed, and in many cases CC-BY-SA is preferable.

My concern was that this sets a bad precedent by allowing licensing control to pass from FSF to some other organization. I'm not slamming the Creative Commons Corp here, but the trust that people put into the "any later version" clause is directed at the FSF. I don't think that trust should be taken lightly.

Lack of trust in the FSF regarding this clause causes things like the Linux kernel to be GPL v2 only.

The FSF and the GNU project have historically been very strict about these things, requiring transfer of copyright, etc. This is why I'm surprised and disappointed about the change.

More people would have supported this change, posted 5 Nov 2008 at 22:52 UTC by atai » (Journeyer)

I would think more people support this move, a surprise on RMS's part because he is not a big egomaniac like some would think.

The point of section 10..., posted 6 Nov 2008 at 10:21 UTC by chalst » (Master)

...which says that the license counts also as being cross-licensed with any later version, is to allow the FSF to deal with problems with earlier versions by changing the terms of the license. To use a license with such a term means that you are placing trust in the FSF to do the right thing.

What obligations does the FSF have? Not to never surprise any user of the GFDL, but act in some particular concept of the best aggregate interest of all parties who use the license. This is a tricky concept, but it is clear that it's not enough to complain about vague principles being violated, for the FSF to have fallen short of their responsibilities they must have failed to take into account actual harm to the interests of the license users.

As an author, through Wikipedia, of GFDL text, I'd like to have heard of this change before reading this article, and, like cdfrey, it bothers me a little that I haven't. But the reasons I wrote that content are definitely furthered by the change, and I don't know of any concrete harm this does, so I'm not really all that bothered.

If you don't trust the FSF, but for some strange reason think version 1.2 is almost exactly the right license, it is possible to adjust the license by deleting section 10.

trust, posted 10 Nov 2008 at 09:47 UTC by lkcl » (Master)

i raised this issue several years ago.

there is no clause in the GPL that says "future licenses will NOT EVER have the clause removed that makes future GPL licenses be truly free software".

there was, at the time, some confusion about this, because, if such a clause is ever removed, it's not _that_ license that you have to worry about, it's the one AFTER it.

first remove the protection mechanism and _then_ you have carte-blanche.

it was the same thing with hitler's 1936 "enabling act", and it was nearly the same thing with the UK "legislative and reform bill" which got through to its second reading - unnoticed - before anyone realised the similarities to the nazis method of legally introducing dictatorship into germany.

Re: trust, posted 18 Nov 2008 at 15:31 UTC by abraham » (Master)

Despite his comparison to Hitler, which usually helps improve the discussing, I'm not quite sure what lkcl is talking about. But if it the power granted the the FSF by the "any later option" choice, I'd like to point out that this power is severely restricted by thousands of signed contracts with people who have donated software to the FSF. Each contract stipulates restrictions in what FSF can do with the code, and since the code is usually covered by the GPL, is also means there are restrictions in what the FSF can do with the GPL.

Re: trust, posted 18 Nov 2008 at 23:20 UTC by cdfrey » (Journeyer)

abraham: I didn't know about that side of the GPL equation. That's very good to know, thanks.

GFDL Background, posted 18 Nov 2008 at 23:27 UTC by cdfrey » (Journeyer)

This is copied from a thread on the KWLUG mailing list, by request, to provide any further clarification to those stumbling across this web document in the future.

On Mon, Nov 17, 2008 at 07:30:29PM -0500, Chris Bruner wrote:
> Chris Frey wrote:
> >Open Letter to Richard Stallman:
> >
> >     [Also posted at:]
> >
> >Dear Mr. Stallman,
> >
> >  
> ...
> Hi Chris,
> I don't understand the ramifications of this at all. What has happened 
> with this license that cause the open letter?  (I was not even aware 
> there was an gpl for documents, I assumed gpl was enough).

Hi Chris,

As I understand the history of the GFDL, people came to the conclusion that the regular GPL was less than ideal for documentation. (Things like software manuals, books, articles, creative works.) And so a new license was written by the FSF to handle this. The result was the GNU Free Documentation License.

I believe this was one of the first licenses of its kind. If you read the license, you'll find it is very complicated, and tries to deal with every possibility. So, for example, say you're writing a manual for your GPL software FooBarter. You might write an introduction to your manual that explains your philosophy or reasons for writing the software, or the history behind it, perhaps including credits of people who inspired you or original research you did. And then afterward would be the usual technical and user documentation on how to use the software.

The GFDL has language in it that supports breaking your document into sections. You may want to keep your introduction intact, and while letting everyone freely distribute it, you do not want edits to it, because it is your creative and philosophical vision. But the rest of the manual changes with your software, and should be free to change by the community, and should be open to patches just like the rest of the code.

So these features of the license are what make the GFDL so complicated and useful in certain contexts. The GFDL was also written with the goal of allowing and promoting paper publications of such works. The license requires that you include the license text with republication of the work. From a GPL perspective, this makes sense, since GPL software nearly always comes with the text of the GPL license included. A GFDL book might as well have the license in the back as well, to promote the knowledge of the freedom of the text.

Well, the world has changed and the Creative Commons school of thought has come into being. These licenses are designed to be more plug-and- play. They do a few things, and do them well, and while they don't permit as much flexibility in the same way as the GFDL, they are simpler, easier to understand, and therefore have spread like wildfire. This is a Good Thing (TM).

Unfortunately, Wikipedia was created in that limbo time, around the time of the GFDL but before the time of the Creative Commons, and so all of Wikipedia's work was licensed under the GFDL. As time went on, the Wikipedia community started to lust after the free-wheeling nature of the Creative Commons community. In fact, if you ever tried to contribute a photo to Wikipedia, you would run into much encouragement to licsense your work under a Creative Commons license, because it let people reuse your work without pinning a 3 page GFDL to the back of each photo.

But the main body of text in Wikipedia was stuck under the GFDL.

Normally when this happens in a Free Software project, and the current developers decide to relicense software that has multiple copyright holders, they go through the CVS/whatever history and try to contact every major contributor, and ask specificially whether it's ok. If they get enough affirmative answers, they can change the license of the code, rewrite any small parts that they didn't get permission for, and continue on with life. If they don't get permission, they can't relicense. Also, the effort to do a proper relicensing job is rather substantial, so it is not done for trivial reasons.

This natural inertia against relicensing is also a Good Thing (TM), in my opinion.

Well, the GFDL can be used in the usual recommended way that the Free Software Foundation recommends all their licenses be used: i.e. you can license your work under version X.Y of their license, or any later version. This is commonly done in the GPL world, and was done in the Wikipedia case.

The choice of this style of licensing is of course up to the author of the software, manual, book, photo, etc. Not all projects use this clause. The linux kernel, for example, uses only version 2 of the GPL, and so cannot easily switch to the new version 3.

The implicit promise is that if you trust the FSF, then you can trust that any future license that they release will remain true to the original principles that the current license you are now using espouses. If you agree with the principles, and trust the FSF to stick to them for future details, you use the extra clause, which gives you added flexibility and possibly protection from future threats, such as new legal landscapes, bugs in old versions of the license, etc.

Generally, the "any later version" clause is also a Good Thing (TM), although many people disagree.

The problem I had, was that the FSF chose to make use of the "any later version" clause to allow a change of licenses from the GFDL to one of the Creative Commons licenses. In practical terms, this changes very little, except that it is much easier to reuse Wikipedia content (or any Wiki content that matches this new GFDL license change). In idealistic terms, it sets a bad precedent, in my opinion, where FSF has given control of future licenses away to another organization, the Creative Commons Corp, and now people who chose to accept the "any later version" clause for their works now have to trust both the FSF and the Creative Commons.

Again, practically, this isn't a big deal. But you can imagine the uproar if version 4 of the GPL allowed a transfer of license from GPL to BSD. This is highly unlikely to happen, but it is the sort of change that I believe should be left to the existing method... the one with the extremely hard work, the one that needs the author's approval.

Technically, the authors have already given their approval, by using the "any later version" clause. The problem is that they thought they were allowing any later version of the GFDL, not any later version of the Creative Commons license. In my opinion, it is a betrayal of trust, and hence warranted an open letter to Richard Stallman.

Unfortunately, I haven't heard back from him yet. I hope he's just been very busy, and will reply eventually.

I hope that clarifies things.

- Chris

GFDG Background, followup, posted 18 Nov 2008 at 23:29 UTC by cdfrey » (Journeyer)

And the followup...

On Mon, Nov 17, 2008 at 09:46:15PM -0500, Chris Bruner wrote:
> So if I understand it, the new GFDL allows a switch to a competing 
> license, and you feel that people signed on to the FSF license may not 
> want a competing license. Their trust in the FSF has been tainted by the 
> FSF essentially changing the basis of the original license to one that 
> was less strict.
> I can see your point.

Yes, pretty much.

I should point out that I'm in the minority here. Which would put Richard Stallman in the majority for once. :-)

The actual change is very little. The new GFDL allows switching only for a limited time, and only documents that have no invariant sections, to be transferred to a Creative Commons license that has the Share-Alike clause. So the "viral" (for lack of a better word) nature of the GPL family of licenses is still intact.

To give the FSF credit, they were fairly careful with the change, and I would have been happier if they would have specified a specific version of the Creative Commons license, instead of using the "any later version" there too. That would have kept the FSF in the loop, and at least maintained that link of trust that I believe is implied by the "any later version" clause.

In any case, the Wikipedia folks are happy, as well as many others. The GFDL seems to get a bad rap these days. I haven't worked with it very much myself, so I don't see its flaws first hand. Even Debian considers it a poor license.

So I do see that there are numerous practical advantages, I just wish those advantages were achieved differently.

- Chris

contract implications, posted 20 Nov 2008 at 11:14 UTC by lkcl » (Master)

Each contract stipulates restrictions in what FSF can do with the code, and since the code is usually covered by the GPL, is also means there are restrictions in what the FSF can do with the GPL.

are you _sure_ about that? what has each and every individual piece of code _explicitly_ got to do with the specific and completely separate issue of being responsible for writing up the GPL license?

is it _explicitly_ written into the contracts that the FSF *must* keep the GPL "invoilate" and in accordance with the current ethics (which we accept and believe in) just because some code _happened_ to be released under that license?

it's by a series of steps of "omission", in subsequent generations of the license, that the GPL _could_ be eroded.

the comparison to the situation with _not only_ the "enabling act" of 1936 _but also_ a much more recent (2006 i think it was) near-identical law in the United Kingdom (the "legislative and reform bill") serves as a reminder that it's perfectly possible to slip in "progressions" in undermining of the status quo.

exerpt from chris's post, posted 20 Nov 2008 at 11:23 UTC by lkcl » (Master)

Again, practically, this isn't a big deal. But you can imagine the uproar if version 4 of the GPL allowed a transfer of license from GPL to BSD. This is highly unlikely to happen, but it is the sort of change that I believe should be left to the existing method... the one with the extremely hard work, the one that needs the author's approval.


is _that_ explicitly disallowed in the *current* GPL???

is there _anything_ in the GPL that says "future versions of the GPL will ALWAYS be similar in spirit _to_ the current GPL, and this statement - this very statement, this very clause, here being said RIGHT now - will NEVER be removed".

this is the kind of language that NEEDS to go into the GPL to ensure that it never ever gets "taken over". "degraded".

and, if it can be done to the GFDL, then, conceivably, it can be "considered reasonable" to be done to the GPL, as well.

GPL to BSD, posted 20 Nov 2008 at 16:49 UTC by cdfrey » (Journeyer)


Technically, there is nothing stopping FSF from making such a change, even though I consider it highly unlikely.

The thing that lets people think that the "any later version" clause is appropriate is their trust in the FSF, and let me be clear, it is only this trust that has taken any hit, in my opinion, and _not_ the practical effects of the licenses.

and, if it can be done to the GFDL, then, conceivably, it can be "considered reasonable" to be done to the GPL, as well.

The recent change in the GFDL is not nearly as wild as a GPL->BSD license would be. (I used that as an explanatory "shock and awe" example.) The core principles are indeed being preserved in the GFDL case, it's just the details around those principles that are changing. And while you and I agree that those details are important, the sky hasn't fallen. Yet. :-)

I just wanted to clarify that.

Copyright assignment contracts, posted 20 Nov 2008 at 16:52 UTC by cdfrey » (Journeyer)

I'd love to see the text of one of these contracts, but as far as I understood abraham's post, it sounds like the FSF has their own self-interest locked up in these contracts, such that if they made core changes to the GPL, they may be ripping the rug out from under themselves, and losing access to the code they supposedly control.

And if so, this is a beautiful thing. :-)

It seems like new 'licensing verbiage' is needed, posted 22 Nov 2008 at 18:54 UTC by Mysidia » (Journeyer)

For licensed files, instead of: "...the Free Software Foundation, either version 2 of the License, or (at your option) any later version."

A note more like:

"the Free Software Foundation, or (at your option) the latest version currently published, provided that version includes all the same restrictions as this version and the latest version does not allow any change of license."

In effect, giving the FSF the ability to revoke new versions of the license at any time (other than the originally licensed version), since they will no longer be the latest version.

And the verbiage itself can never be changed, except with approval by all copyright owners.

doesn't work, posted 22 Nov 2008 at 20:00 UTC by lkcl » (Master)

the point of the future-proofing is to allow the GPL to be updated to deal with unforseen circumstances.

the BSD licenses were created at a time when people were trusted to contribute code back. corporate greed broke that trust. standing out in particular: apple (BSD kernel), microsoft (BSD tcp/ip stack - _twice_ - once in winsock and when they screwed that up, the second time was in MSRPC using raw sockets).

the GPL licenses were believed to deal with that, but again, corporate greed found a way, using the DMCA as a *legally* required threat (oh, our hands are tied: we have to _by law_ add DRM, sorry).

so the GPL had to be updated _again_.

so - yes, the FSF must be given the freedom to make changes it sees fit, but also it should be restricted in its freedom to act _against_ the spirit of what the FSF stands for.

just in case.

Future proofing, posted 22 Nov 2008 at 22:13 UTC by Mysidia » (Journeyer)

I think the real reason for allowing distribution under the terms of future versions is for compatibility; so situations don't begin to develop where you can't make a work derived from both a GPLv2 product and a GPLv3 product, because the licenses are incompatible and neither can be satisfied.

The author of the software still has to change "version 2 (or at your option) any later version" to actually read the "version 3 (or at your option).

Until that happens, none of version 3's protections are imposed against new licensees.

And even the new licensee, who forks the project and distributes under GPLv3, cannot necessarily change the option, since the license is always conferred from the original licensee with the option of version 2, until _that_ party has actually changed the minimum applicable version for every single file in their software package.

So it makes sense that there should be some restrictions on what type of changes new versions can introduce and "automatically" be used.

Who watches the FSF?, posted 24 Nov 2008 at 14:53 UTC by chalst » (Master)

lkcl: the FSF ... should be restricted in its freedom to act _against_ the spirit of what the FSF stands for.

How is this to work, exactly?

To me it seems that the right thing is not to restrict the FSF's legal rights over updating its licenses, but to improve the quality of its democratic processes. The kind of thing that slef talks about from time to time.

A bit of diversity wouldn't hurt. We could have several different GPLs, or whatever, backed by different free software bodies, who each have the right of updating for their branch of the GPL...

Richard Stallman's reply, posted 6 Feb 2009 at 02:15 UTC by cdfrey » (Journeyer)

Richard Stallman responded back on Dec 3 2008, and I only noticed now. Thanks to mattl for posting the latest Free Software Supporter article where I found it.

Richard Stallman's response can be found on the FSF blog here.

Still, I would say, does not look very nice, posted 5 Jun 2009 at 10:11 UTC by audriusa » (Journeyer)

I have read the Stallman's reply, it still does not look very nice. Generates lots of very unpleasant FUD about if that "any later version" could allow to sell all GNU project to IBM or Microsoft one day. Maybe not by Stallman but who knows enough about the people that may come later? Linux seems right not liking this clause.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page