[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A single unified license



RMS said:
>GPL 3 is not at the stage to ask for public comments.

Rumor has it that it will contain loads of stuff which Debian considers 
non-free.  This is a *problem*.

The FDL public comment period resulted in *no* significant changes due 
to the public comments.  

RMS has declared that he has the final word on anything the FSF does, 
and refuses to give out the names of anyone else involved [1].  
Getting information about his reasons for decisions about the 
controversial parts of the FDL has been like squeezing blood from a 
stone [2].  (It took about a year to get the information that he 
considered invariant sections acceptable because he classed them as 
'packaging restrictions'.)

The FSF is set up as a charitable corporation, which means its board is
self-perpetuating.  It is currently run as RMS's personal autocratic 
fiefdom [3], and there's really no chance of that changing without 
RMS's assent given a self-perpetuating board.  (Unless he dies, of 
course.)

Previously, developers were willing to assign their copyrights to the 
FSF because they trusted RMS/the FSF to preserve the freedom of their 
code.

After the FDL fiasco, I no longer trust him to do that.  I am waiting 
for a definitive legal opinion from the FSF on whether I can relicence
my *own* contributions under a more permissive license (such as the GPL 
v.2).  (I do not appear to get that right from my copyright 
assignment papers.)  If that right is absent, I will have to cancel my 
current copyright assignment to the FSF, in favor of a disclaimer 
(since putting my work in the public domain is far better than 
allowing it to be made proprietary by the FSF).

--
If we can anticipate consistent behavior from the FSF, we will see the 
following:
1. The GPL v.3 will be presented "for public comment".  It will contain 
unacceptable non-free provisions with no good explanation.
2. The comment period will contain lots of complaints about this.
3. The final version of the GPL v.3 will be released, with no change in 
the non-free provisions, and no explanation as to why.

At this point, it will be necessary for free software developers to do 
the following:
a) Discourage "version 2 or later" licensing in favor of "version 2" 
licensing
b) Encourage the forking of all FSF-copyrighted projects

I would personally start a fork of GCC.

Forking and relicensing is a slow, tedious process.  Accordingly, if the 
FSF is planning to release a non-free GPL v.3, we want to start the 
process as soon as possible; waiting simply gives them a head start at 
subverting free software.  On the other hand, if the GPL v.3 will be 
just *fine*, we don't *want* to cause the trouble caused by forking and 
relicensing.

What free software developers want are reassurances that the FSF is *not*
planning to cause this nightmare scenario by making a GPL v.3 which is 
unacceptable to Debian.  We have *no* such reassurances.  The recent 
past leads us to be very suspicious.  

The "no information coming out" attitude from the FSF means, sadly, that 
we must believe the worst: that the FSF is planning to subvert free 
software with the GPL v.3, and that RMS is trying to hold off on 
supplying information as long as possible so as to leave the opposition 
scrambling to catch up, as it is with the FDL.

I will be starting the following projects:
1.  Informational website with reasons to avoid the GNU FDL, and how to 
do so.
2.  List of free software developers who oppose the GNU FDL.
3.  Project to create free (GPL) manuals for GCC, and eventually other 
projects with FDL'ed manuals.  (This is partly awaiting the FSF's legal 
opinion on relicensing of one's own contributions, since if we definitely can,
I just need to collect the contributions of willing developers and then 
fill the gaps.)

I'll need help with all of these. :-(

[1] Personal communication.
[2] Archives of debian-legal.
[3] In addition to the evidence above, all requests for licensing 
changes on FSF projects must go through RMS personally, which can be 
testified to by many GCC developers.



Reply to: