AW: AW: AW: For Approval: German Free Software License

[Michael Sparks]

On Mon, 29 Nov 2004, Axel Metzger wrote:
> Sorry, but I do not believe that we will come to a common point by writing
> e-mails to the list.

Without talking, nothing changes.

> I see that some members of the list, especially Bernhard and Russell, have a
> problem with the new license versions-clause. When I read on the OSI website
> the following...
>
> 	"If license-discuss mailing list members find that the license does
> not conform to the Open Source Definition, they will work with you to
> resolve the problems."

They ARE working with you. You can't see it though, which is unfortunate
so I'll have a go, since I can see it. I'm not a lawyer, or an OSI borard
member etc, so this isn't binding on anyone, but I can see what they're
talking about.

The Open Source Definition is just that. It's a definition that's been
agreed upon as a good enough definition. If it ever changes it will be a
slow, hard fought battle with lots of input from lots of locations. Not
least for one very simple reason: people agree that it embodies the basic
tenets of open/free software development from the past few decades.

Essentially it defines a standard to which implementations must adhere. In
this case the implementations are licenses and whilst in some places there
are ambiguities on border cases, in others there are not.

In this case you are asking for the GFSL to be certified as open source.
This is fine. In order to be certified the first thing anyone does is they
look for bugs - you run the standard across the implementation and look
for areas where things don't match.

In this case there is a blocking "bug" which is specifically this line:
  "The new version of the License becomes binding for you as soon as you
   become aware of its publication."

There may be others.

Why is this a blocking bug?

Date 1) Suppose the GFSL version 1.414 is certified as open source.

   This is good for your universities and other organisations - they can
   now release code under a common license. (And everyone else can just
   take it, bind with GPL code and re-release the whole under the GPL
   should they wish according to section 3.3)

Date 2) University releases code X under GFSL

Date 3) External project A recieves code under GFSL, combines with GPL
project, releases combination Y under the GPL

Date 4) The board who write the GFSL think "oh hold on, maybe we want to
   have a similar clause for BSD licenses" and introduce 3.3.1 which says
   the entirety may also be linked with BSD and become BSD as a whole. (Assume
   a misunderstanding of the BSD license here - I'm deliberately creating
   a problem clause)

   I'm using this as a silly example of the people writing the GFSL
   thinking that their license needs updating (as happens), and adding in
   a problem clause.

   This is identified as version 1.732

Date 5) External project B recieves the code from A, and decides to
   integrate some BSD's code into the original codebase that was GFSL.

What's the problem here?

At simplest, it becomes very difficult to accurately ascertain what should
happen as a devloper,meaning it's very unlikely I'd go near the code with
a bargepole! This is very bad from the perspective of any rationale for
open sourcing software. That means the license is defeating it's purpose
of existance.

That aside, what other problems are there?

Well at somepoint after date 4, all parties involved will be aware of GFSL
1.732. At that point project B has to transform a GPL project from GPL to
BSD in order to comply with the terms of section 3.3.1. This they cannot
do since they also have to comply with section 3.3.

The upshot is the license becomes impossible to comply with, which means a
normally sensible/OK combination (combining BSD and GPL projects) now
breaks due to seeming simple clauses in 1.732.

That said, the people writing the GFSL wouldn't write such a clause in
would they? However you cannot *guarantee* that they will not write a
clause that removes my right as a developer to work on code in a certain
way, ever.

The GPL, BSD, AFL, OSL, lienceses guarantees that if I recieve code at any
time under any of those licenses - specifically that if I recieve code at
any time under and OSI certified license that I will be able to continue
to use the source code as I see fit making derivative works as I need to
under terms and conditions that do not change until copyright expiration.

THAT is absolutely key for open source or free software development.

If you as an external party have the ability to change any part of the
license I am relying on your good will and good sense not to make a change
either through malice or mistake that takes away any of those rights. I
would expect the mistake route to be more likely but it is a possibility.

Suppose however malice kicks in due to unfortunate political changes*, and
(say) the license changes to remove the GPL clause, or the GPL clause
changes to "you may not link with the GPL", etc. This retroactively
affects every external project that uses the code. (Consider a whizzy new
scheduler released under the GFSL which gets integrated into the linux
kernel, the GFSL changes - the scheduler has to be removed - from all
distributed versions as soon as people become aware of the license change)

   * Given the history of the world unfortunately you really can't rule
     that out... :-(((


Trying to be constructive rather than just pointing out the blocking issue
though, I would suggest that you change that single clause to something
like:

"As a new version of the License is published, you may choose to accept
such version as binding as you become aware of its publication."

You really need to include the version number in the license though,
obviously.

The downside here, is that whilst this is an absolute blocker, and whilst
I believe your group has absolutely the best intentions and so on, times
change, and political climates in all countries change. You cannot
guarantee to the list that the license may change 10 years from now to
disallow any/all OSI rights.

  *** And yet, you expect people to accept the license as it is now  ***
  *** as OSI compliant, when in fact you have no idea what terms and ***
  *** conditions acceptance now will enforce 10 years down the line. ***

And the really sad downside of getting bogged down on this particular
bug is that it masks the discussion on any/all other problems with the
license, if any.

One final thought though:
   * This license is not Free Software as I would understand the
     definition used by most - most people tend to agree with the FSF
     these days out of convenience here.
   * This license is not Open Source - as most people would view things.

This strikes me as a very, very poor thing to be arguing for without
listening to the absolute key blockers from someone who list "Institute
for Legal Issues On Free and Open Source Software" as the creators of the
license.

To my mind this license and your apparent inability to understand the
arguments put forward to yourself puts your entire Institute into
disrepute, since you clearly have not understood as a legal professional
what is wrong with your license and non-legal people (ie the layman) CAN.

My intent here by mentioning this is not to insult you but simply to
inform your lack of understanding comes to me personally, and I suspect to
others. This harms you, and since you clearly support free software and
open source (based on where you work :), I would suggest you're doing
yourself a disfavour.

Best Regards,


Michael.
--
I Am Not A Lawyer, This is not legal advice. I'm also not an OSI member,
but I am trying to help you by hopefully prompting useful questions :-)


> ... I had the expectation that we could work together on some kind of
> compromise. I was wrong to that point. It seems to me that Bernhard and
> Russell do not want to have any sort of compromise. For them it's a question
> of right or wrong. I have to accept this. It's their decision.
>
> I have also read positive comments on the list. Thanks for them too.
>
> I would suggest that we wait now until the OSI-board decides what they think
> about the license and under what conditions they are willing to certify it or
> not. Then the GFSL-people have to decide whether they are willing to pay the
> price or not.
>
> I will go back to work now.
>
> Axel
>
>