Subject: Re: what *is* the approval process?
From: "Chris Travers" <chris.travers@gmail.com>
Date: Tue, 4 Sep 2007 09:17:10 -0700
Tue, 4 Sep 2007 09:17:10 -0700
On 9/3/07, Matthew Flaschen <matthew.flaschen@gatech.edu> wrote:
>
> Chris Travers wrote:
> > First of all, I want to state a few things about limitations on the
> approval
> > process.
> >
> > We really can't ever come to an understanding of whether a license is
> > eligable for approval if we don't know what it means.  There are areas
> of
> > the GPL3 which still seem sketchy from a procedural perspective (and
> while I
> > can live with the idea that the permissions removal essentially creates
> an
> > ineffectual sublicense, as Matt has stated, I am still not sure if this
> is
> > truly the case).
>
> It isn't strictly true that the license needs to be completely
> unambiguous (in all situations) to be approved.  This is a good thing,
> because no license fits that bill.  In this case, it doesn't matter
> which way you read the license.  Even if it's impossible to remove extra
> permissions, GPLv3+permissions is still OSD-compliant if GPLv3 is.



One question is:  How many issues does a license have to have before we want
to look at proliferation questions.

My own view is that the "removal of permissions" issue seems at odds with
the rest of the license in terms of mechanism to the point that it may need
to be fixed.  I think the appopriate response is probably to hold off, pass
the questions back to the FSF and ask them and/or the Software Freedom Law
Center to provide an analysis.  If it is a problem that they decide needs to
be fixed, do we want to do another approval process for a GPL 3.01 when it
is released shortly after we approve the GPL 3?  Just because a license is
out there and even currently used for a few projects, does that mean we
*must* decide whether to approve that license?  (Certainly many people in
the Microsoft license threads didnt seem to think so.)\

At this point, I am not saying we should reject the license.  I am just
saying we should communicate the concerns with the organizations involved
and find out if they consider them serious enough to be fixed.  If so, we
might want to hold off.  If not we may want to go ahead for the sake of
projects who *have* already upgraded their licenses..

Best Wishes,
Chris Travers


Matt Flaschen
>
>
>




On 9/3/07, Matthew Flaschen <matthew.flaschen@gatech.edu> wrote:
Chris Travers wrote:
> First of all, I want to state a few things about limitations on the approval
> process.
>
> We really can't ever come to an understanding of whether a license is
> eligable for approval if we don't know what it means.  There are areas of
> the GPL3 which still seem sketchy from a procedural perspective (and while I
> can live with the idea that the permissions removal essentially creates an
> ineffectual sublicense, as Matt has stated, I am still not sure if this is
> truly the case).

It isn't strictly true that the license needs to be completely
unambiguous (in all situations) to be approved.  This is a good thing,
because no license fits that bill.  In this case, it doesn't matter
which way you read the license.  Even if it's impossible to remove extra
permissions, GPLv3+permissions is still OSD-compliant if GPLv3 is.


One question is:  How many issues does a license have to have before we want to look at proliferation questions.

My own view is that the "removal of permissions" issue seems at odds with the rest of the license in terms of mechanism to the point that it may need to be fixed.  I think the appopriate response is probably to hold off, pass the questions back to the FSF and ask them and/or the Software Freedom Law Center to provide an analysis.  If it is a problem that they decide needs to be fixed, do we want to do another approval process for a GPL 3.01 when it is released shortly after we approve the GPL 3?  Just because a license is out there and even currently used for a few projects, does that mean we *must* decide whether to approve that license?  (Certainly many people in the Microsoft license threads didnt seem to think so.)\

At this point, I am not saying we should reject the license.  I am just saying we should communicate the concerns with the organizations involved and find out if they consider them serious enough to be fixed.  If so, we might want to hold off.  If not we may want to go ahead for the sake of projects who *have* already upgraded their licenses..

Best Wishes,
Chris Travers
 

Matt Flaschen