AW: For Approval: German Free Software License

[Axel Metzger]

Hi Chuck, 

thanks for your comments. I will try to address your critical remarks. 

Chuck Swiger wrote: 

>Although the terms are close in meaning, neither the Free Software
>Foundation 
>nor the OSI board would consider "free software" and "open source software"
>to 
>be synonyms.  For example, the OSI board has approved some licenses which
>are 
>not compatible with the GPL's definition of "free software".
>
>The rest of the preamble which follows this first paragraph strikes me as 
>well-written, but I would attempt to revise the above like so:

We know about the different opinions and definitions. Our aim was to take a
position as neutral as possible between the different branches of the
Free/Open Source community.

>>>Section 0 Definitions
>>>Documentation: Description of composition, architecture and/or
>>>structure of the programming process and/or functionalities of the
>>>program, irrespective of whether they were done in the Source Code
>>>or separately.
>
>Documentation also includes things like user guides, README's, FAQ's, and 
>other information which is oriented towards end-users who are not
>developers. 
>  You might want to list these first, even.  :-)

We should consider this. Thanks for the hint. 

[ ... ]
>>>Public/publicly: Not solely directed towards a certain group of
>>>people who have a personal connection to each other or are
>>>associated through their affiliation with a legal person or public
>>>organisation.
>
>This strikes me as a complicated and non-intuitive definition of "public". 
>Doesn't applicable law already have a well-established meaning for this
>term?

For copyright issues, the principle of territoriality is appplicable. It
states that each state has to apply ist own copyright rules. The choice of
law clause does not help here, because the territoriality is internationally
mandatory. 

The result is that many different copyright legislations might be applicable.
I do not enough about their definition of "public". Therefore we thought it
would be useful to have a definition in the license.

>>> Making Publicly Available: The public distribution of the Program in
>>> an immaterial form, in particular, by making it available for
>>> download in data networks.
>
>Please note that the FSF is willing to ship their software on tape or
CD->ROM 
>formats.  If I make the GFSL software available in a material form by 
>reselling it on a CD to the public at large, this license probably sstill 
>hould cover such a situation.  :-)
>
>You might find the phrase "public redistribution" more useful to you.

The license grants the right to "make publicly available" AND to
"distribute". The latter term includes hardcopies. This is the wording of
European Copyright law. We have to accept this. 

>>> Entitled Person(s): The author(s) or other holders of the exclusive
>>> right to use for the Program.
>
>The OSD recognizes that the authors of software do have some additional
>rights 
>and may impose some reaonable restrictions (cf. OSD #4 "Integrity of The 
>Author's Source Code"), however:
>The notion that the authors/holders have exclusive right to use the program 
>violates OSD #5.  If the software is to be open source, all users need to
>be 
>granted the same rights to use and modify the software.

I think we have a misunderstanding here. Entitled Persons in the sense of the
GFSL have these rights before licensing the software under the GFSL. 
The authors or his employer have exclusive rights by law. They may transfer
these rights to somebody else. If one of these entitled persons is willing to
license a program under the GFSL he/she stills holds the exclusive rights for
the software. Take SUN and Open Office as an example. They licensed the
software under the GPL, but they are still rightholder and hold exclusive
rights. Otherwise they could not take the same code and distribute it under a
proprietary license as Star Office. 

>>>Distribution: The public passing on of material copies to third
>>>parties, in particular, onto storage devices or in connection with
>>>hardware.
>
>One is also redistributing the software if you pass the software on in 
>private, say to your relative or to another member of your company.
>
>I believe your intent is to enable people to change the software for their 
>private use without making their changes public, but require the source
>code 
>to be made available when public redistribution, so it would be helpful to 
>clarify these terms a bit.

Here once again, we followed the wording of German and European Copyright
law. Do you have a realistic idea how many problems of interpretation
European lawyers have with the US-based licenses? This is one of the major
reasons why the Ministry wanted to have a more "European" license. 

>>>Section 7 Liability and Warranty
>>>(1) The Entitled Persons are only liable for conflicting third-party
>>>rights if they were aware of such rights without informing you.
>>>
>>>(2) Liability for errors and/or other defects in the Program shall
>>>be governed by agreements concluded between you and the Entitled
>>>Person beyond the scope of this License or, if no such agreement
>>>exists, by the pertinent statutory provisions.
>
>If I modify a program covered by the GFSL, and I want to redistribute my 
>version without any warranty (ie, the standard DISCLAIMER found in the BSD
>and 
>other licenses which disclaims liability since the software is being made 
>available free of charge), may I do so?

No, under German and European contract law it is impossible to exclude any
warranty and liability. The consequences are not to severe - as long as you
redistribute the program without charging a fee. Under the German Cicil Code
you are only liable if you knew that the program has defects etc.

>Can a project like FreeBSD, NetBSD, etc, or a Linux distro like Debian, 
>Redhat, etc, adopt GFSL code without conflict with their existing
>disclaimers?

The disclaimers are invalid under German and European contract law. Sorry,
they are legally inexistent in Europe. 

>[ ... ]
>>>(3) This License does not commit you to forward the Program to a
>>>third party. You are free to decide to whom you wish to make the
>>>Program available. However, you may not prevent or complicate
>>>further use by third parties through the use of technical protective
>>>measures, in particular, the use of copy protection of any kind.
>>>Password-protected access restriction or use in an Intranet shall
>>>not be regarded as technical protective measures.
>
>It seems important to distinguish access to the program from access to the 
>source code of the program.  The last sentence is a start, but even so,
>this 
>paragraph appears to forbid users of the software to utilize GFSL software
>via 
>SSL, for example.

Didn't we make that clear in Section 4 of the GFSL? ("Section 4 Further
Obligations for the Distribution of the Object Code"

>
>[ ... ]
>>>(2) The license board of the German Free Software License may put
>>>into force binding new versions of this License inasmuch as this is
>>>required and reasonable. New versions of the License will be
>>>published on the Internet site <http://www.d-fsl.org> with a unique
>>>version number.
>
>This version of the license ought to have a version #, too, then.

Thanks for the hint. I will advice the Ministry to do so.

>>> The new version of the License becomes binding for
>>> you as soon as you become aware of its publication. Legal remedies
>>> against the modification of the License are not restricted by the
>>> regulations described above.
>
>I would suggest handling this the way the GPL does; ie, the user may choose
>to 
>accept the new version of the license at their option, not as a
>requirement.
>
>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. 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.
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 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. 

>Anyway, by and large, my opinion is that this license will be
OSD->compatible 
>and ought to be approved once some of the inconsistent details are worked
>out.

Thanks for the positive feedback and the interesting hints and questions.

Best regards

Axel

	----------