[License-discuss] "Fairness" vs. mission objectives

[Ryan Birmingham]

There has been discussion (though in this case debian rather than OSI)
approval on the Vim License before; see
https://lists.debian.org/debian-legal/2002/01/msg00010.html .
As a summary, the vim license still asks for those who make changes provide
them to the maintainer.
Members of this mailing list mentioned the "desert island test" that this
breaks, and more importantly for OSI, mentioned that this may be a OSD
section 6 violation since it may bar applications which require secrecy.
Though, I'm not a lawyer, and it's quite possible I've misinterpreted the
implications of that part of the vim license.

-Ryan Birmingham


On Tue, Feb 25, 2020 at 5:44 PM Kevin P. Fleming <kevin+osi at km6g.us> wrote:

> Hear hear! I recently had to grant an internal exception to allow
> contributions to Vim because "The Vim License" is not an OSI-approved
> license. I have no doubt that it would be approved were it to be
> submitted, but it has not been as far as I can tell and is unlikely to
> ever be.
>
> On Tue, Feb 25, 2020 at 2:56 PM Richard Fontana <rfontana at redhat.com>
> wrote:
> >
> > On Tue, Feb 25, 2020 at 2:18 PM VanL <van.lindberg at gmail.com> wrote:
> >
> > > On the flip side, I think there should be an affirmative effort to
> certify licenses - such as those identified via the SPDX project - even
> without affirmative submission. Most of them will not be controversial. We
> want to reach a world in which we have looked at all the source-available
> licenses and made a determination as to their OSD conformance. This
> strengthens the OSD as a tool for measuring licenses.
> >
> > Agreed! In theory I suppose the "legacy approval" process could be
> > used for this, but it has depended on someone taking the initiative to
> > submit a license for approval and has been invoked only rarely. I
> > would love to see the OSI recognize some category of certification for
> > the hundreds of licenses in actual active use in, for example, Linux
> > distributions, more often than not simple legacy noncopyleft licenses
> > from the 1980s and 1990s, which uncontroversially meet OSD/software
> > freedom criteria but which would likely never be submitted for
> > approval by a (typically nonexistent) license steward, or which would
> > have traditionally been discouraged on anti-proliferation grounds. Far
> > better than focusing on so-called "crayon" and thought-experiment
> > licenses, which until relatively recently characterized a lot of the
> > submissions to license-review.
> >
> > Richard
> >
> >
> > _______________________________________________
> > License-discuss mailing list
> > License-discuss at lists.opensource.org
> >
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200225/28f4e0ce/attachment.html>