what *is* the approval process?

Chris Travers chris.travers at gmail.com
Tue Sep 4 16:17:10 UTC 2007


On 9/3/07, Matthew Flaschen <matthew.flaschen at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070904/d58aba70/attachment.html>


More information about the License-discuss mailing list