AW: For Approval: German Free Software License

[Bernhard Fastenrath]

Axel Metzger wrote:
> Chuck Swiger wrote: 
>>I have strong doubts about the validity of an open-ended license which may
>>be 
>>altered or changed by one party without notification or acceptance on the
>>part 
>>of the other party.  For example, the fact that credit-card companies would 
>>like to be able to change the rates they charge card-holders on an
>>arbitrary 
>>basis does not make such license terms agreeable to me.
> 
> This remark touches a difficult point. We (i.e. the lawyers engaged to write
> the license and the Ministry) proofed this question in-depth. First of all,
> it's a contractual issue - therefore the choice of law clause in section 10
> is applicable. Hence, German law governs the question if a third party can
> change the provisions of a long-term contract. Here is a major difference to
> the GPL/FSF-case. The FSF is licensor AND license authority (i.e. the entity
> entitled to change the terms of the license) at the same time.

That is only true for software published by the FSF. I wrote several
programs myself that have been made available publicly under the GPL.
http://nongnu.org/ currently hosts 1855 programs that are not published
by the FSF but which probably contain a high rate of software that is
distributed under the GPL anyway. sourceforge.net probably has much more
to add to this.

> In this case
> one can discuss the similarities with the credit-card companies. The GFSL is
> a different case. Here a third party acts as some kind of neutral "referee"
> between the licensors and the licensees. The - here applicable! - German
> Civil Code accepts that parties choose a neutral third party to adapt the
> provisions of a long-term contract if this is necessary, see section 315 et
> seqq. German Civil Code. Hence, this is legally feasible. 
> 
> We think that this solution is superior to the GPL-approach because all
> components of a GFSl-program will always stay under the same license version.

I'm inclined to agree that this is superior under the condition that the
third party "license board" is a trusted third party to all licensors
and licensees. For the OSI as yet another party it, however, it seems
difficult to assume that level of trust as a necessary precondition for
the acceptability of that license. The license board can modify the GFSL
to leave the acceptance standards for OSI approval of an open source
license and by giving the first version its stamp of approval OSI is
giving away its right to reject a future version of the license at least
in cases where the licensor has agreed to the earlier, OSI approved
version of the license.

> It is very hard to adapt the GPl to new technical and legal challenges
> because the FSF must get the "o.k." of rightholders to accept the new license
> version. If some rightholders do not agree or are simply unknown, the users
> have to check different licenses. This is not wishful. We will see what is
> going to happen if the FSF will try to enact the GPL V3. I am not yet sure
> how they will manage this.

The GPL v3 is by design compatible with the GPL v2 and v1 so it is left
to very single software author to either accept newer GPL licenses by
explicitly trusting the FSF or by upgrading to the newer license by
stating the new license terms for new releases of the software. That is
a migration process without major obstacles.

I'm less certain about the built-in GPL compatibility of the GFSL. Could
you please clarify in what way the GPL and the GFSL are compatible?

> The GFSL tries to install a democratic body - the license board. We are
> working hard to get statute of the board published soon. It will follow
> democratic rules. We know that this democratic body has a lot of power. We
> will hold it open for representatives of those who license their software
> under the GFSL. If, for example, the German Federal Ministry fo Home Affairs
> will also use this license for their software, they will get a seat in the
> board.

That sounds like a foundation for the required trust into the GFSL but
I don't see the OSI can agree to a license that takes away OSI's freedom
to reject future versions without leaving customers suddenly with a
non-OSI compliant license. What you are actually asking for is for OSI
to give you a signature in blank, which is something the OSI cannot do
without giving up its primary purpose.

-- 
www.citizens-initiative.org <http://www.citizens-initiative.org/>