[License-discuss] comprehensiveness (or not) of the OSI-approved list [was Re: [License-review] For Legacy Approval: LBNL BSD]

Sat May 18 20:55:07 UTC 2019

[should I bother continuing to move things off of license-review?]

[tldr: I have said the OSI list is not very useful as currently
constituted, but I don't mean that as an attack on OSI's authority;
hopefully it's an opportunity for the org to note, identify, and fill some
pragmatic real-world needs.]

For my part, my complaint/observation about the incompleteness of the list
is less an "attack on OSI's authority" and more simply the observation that
the OSI approved license list, as-is, is not particularly useful in tools
or contracts.

It isn't comprehensive, so I am highly unlikely to say in a contract "only
use OSI-approved licenses" or build a scanner that rejects/warns solely
based on the OSI list. That would lead to many false positives, either
making the contract inaccurate from day one or making the scanner emit a
lot of incorrect error messages. (This is why many model open source
contract clauses use weasel words that refer to the definition rather than
the list, or use phrases like "licenses similar to those..." or what have
you.[1])

Of course it is possible to build useful, non-comprehensive lists! But the
OSI list mostly isn't that either. For example, a contractor agreement is
most likely to say "only permissive licenses" or "no copyleft licenses",
rather than "only OSI licenses"; similarly for scanner policies.

Saying "OSI's list isn't very useful in contracts or scanners" does carry
an implicit question that I've probably also said explicitly on occasion:
if people don't, by and large, refer exactly to the OSI list in their
documents and scanners, then what is it for? Who is the audience? What will
they use the list for? I don't actually have good answers to this question,
so I'm not sure how OSI should answer it. But it does seem likely that OSI
should strive to have *some* lists whose goal is explicitly about utility.
(This does *not* imply that OSI should abandon the current OSD; one can
imagine many lists that are more useful and still contain only
OSD-compliant licenses. But one can also imagine that an effort to create
those lists might helpfully serve to help refine the edge cases of what the
OSD means in 2019 - perhaps either knocking things off of, or adding to,
the "main" list.)

Answering this question of utility is what drove the Blue Oak list. It is
not a challenge to OSI's authority, simply an actually useful thing that I
can refer to in contracts and scanner policies, which I (and my
clients/customers) need but OSI does not provide. We'll continue to evolve
the list with that goal of utility in mind. (For example, we've had several
people say they can't use it until the groupings/labels are more
informative/less vague. If the list isn't pragmatically useful, it isn't
fulfilling its purpose, so we'll probably make them more informative.) If
OSI obsoleted this effort by providing a deliberately useful list of
permissive licenses I'd be thrilled.

Luis

[1] I do note the lack of such weasel wording in Red Hat's Patent Promise,
which I find admirable. (If anything, the language seems to imply that the
drafters of the Patent Promise do not believe everything in the list
actually meets the OSD, so is potentially narrower than a simply union of
the OSI and FSF lists. This is consistent with Richard's position, if I
understand correctly.) But it does make me wonder how much of Fedora is
actually covered by the patent promise? I assume still 90+% of packages
but, as far as I can tell, certainly not 100% by the strict language of the
promise given the literally hundreds of licenses in Fedora not covered by
the OSI + FSF lists. Perhaps I am misreading it, though.

On Fri, May 17, 2019, 10:59 AM Richard Fontana <rfontana at redhat.com> wrote:

> On Fri, May 17, 2019 at 10:37 AM Smith, McCoy <mccoy.smith at intel.com>
> wrote:
> >
> > I’m curious why, if this license has been used successfully for 16
> years, OSI approval is needed at all? Has the lack of OSI approval suddenly
> resulted in prospective licensees declining to use code under this license?
>
> Probably not. I would assume there's just low awareness of it. But
> I've noticed that OSI has recently come under some attack from a
> not-insubstantial number of people in the wake of the perceived
> rejection of certain experimental business-model-facilitative copyleft
> licenses. The attack in part goes to OSI's claim to say what open
> source licenses *are* and the fact that Linux distributions distribute
> packages embodying hundreds more licenses than are in the OSI's
> approved catalogue, while characterizing (most of) those licenses as
> free software/open source, is something some of these critics point to
> in what I think is an attempt to undermine the OSI's authority. For
> that sort of reason I can see some benefit to some mass effort to get
> legacy approval for that larger set of obviously-FOSS licenses (not
> saying that this BSD-LBNL license is one of them, though if I ever
> consciously looked at this license in the past that's probably what I
> would have concluded).
>
> I can't find the tweet but on Twitter recently Van Lindberg expressed
> the view that for distros like Debian or Fedora, the only portions of
> them that can legitimately be called "open source" are those that are
> licensed under an OSI-approved license. I do not agree with this at
> all, and if the legacy approval mechanism can help respond to this
> sort of viewpoint then it can only be beneficial to OSI.
>
> Richard
>
>
> > Also, I think generally OSI should discourage licenses with text that is
> specific to a particular entity or entities, which is the case with clause
> (3).
> >
> > > On May 17, 2019, at 6:48 AM, Kevin P. Fleming <kevin+osi at km6g.us>
> wrote:
> > >
> > > The request is for "legacy" aprpoval, and if approved that will mean
> > > that usage of the license is discouraged, right?
> > >
> > > On Fri, May 17, 2019 at 6:36 AM Bruce Perens via License-review
> > > <license-review at lists.opensource.org> wrote:
> > >>
> > >> I always appreciate your comments, John, but I'd like to hear from
> Sebastian this time. Is this important enough to have yet another license
> adding to the license proliferation problem?
> > >>
> > >>    Thanks
> > >>
> > >>    Bruce
> > >>
> > >>> On Thu, May 16, 2019 at 7:12 PM John Cowan <cowan at ccil.org> wrote:
> > >>>
> > >>> Well, I suppose because of the default copyleft.  If you publish a
> derivative work and *don't* give it a specific license, it gets the LBNL
> BSD by default rather than the usual default, which is no-license.
> > >>>
> > >>>> On Thu, May 16, 2019 at 7:11 PM Bruce Perens via License-review <
> license-review at lists.opensource.org> wrote:
> > >>>>
> > >>>> Why do they still need to use this rather than the plain BSD
> license?
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> Bruce
> > >>>>
> > >>>>
> > >>>>> On Thu, May 16, 2019, 16:33 Sebastian Ainslie <sainslie at lbl.gov>
> wrote:
> > >>>>>
> > >>>>> The license:
> > >>>>>
> > >>>>> Copyright (c) XXXX, The Regents of the University of California,
> through
> > >>>>> Lawrence Berkeley National Laboratory (subject to receipt of any
> required
> > >>>>> approvals from the U.S. Dept. of Energy). All rights reserved.
> > >>>>> Redistribution and use in source and binary forms, with or without
> > >>>>> modification, are permitted provided that the following conditions
> are met:
> > >>>>>
> > >>>>> (1) Redistributions of source code must retain the above copyright
> notice,
> > >>>>> this list of conditions and the following disclaimer.
> > >>>>>
> > >>>>> (2) Redistributions in binary form must reproduce the above
> copyright
> > >>>>> notice, this list of conditions and the following disclaimer in the
> > >>>>> documentation and/or other materials provided with the
> distribution.
> > >>>>>
> > >>>>> (3) Neither the name of the University of California, Lawrence
> Berkeley
> > >>>>> National Laboratory, U.S. Dept. of Energy nor the names of its
> contributors
> > >>>>> may be used to endorse or promote products derived from this
> software
> > >>>>> without specific prior written permission.
> > >>>>>
> > >>>>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> > >>>>> AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > >>>>> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > >>>>> ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > >>>>> LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > >>>>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> > >>>>> SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > >>>>> INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> > >>>>> CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > >>>>> ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> > >>>>> POSSIBILITY OF SUCH DAMAGE.
> > >>>>>
> > >>>>> You are under no obligation whatsoever to provide any bug fixes,
> patches, or
> > >>>>> upgrades to the features, functionality or performance of the
> source code
> > >>>>> ("Enhancements") to anyone; however, if you choose to make your
> Enhancements
> > >>>>> available either publicly, or directly to Lawrence Berkeley
> National
> > >>>>> Laboratory, without imposing a separate written license agreement
> for such
> > >>>>> Enhancements, then you hereby grant the following license: a
> non-exclusive,
> > >>>>> royalty-free perpetual license to install, use, modify, prepare
> derivative
> > >>>>> works, incorporate into other computer software, distribute, and
> sublicense
> > >>>>> such Enhancements or derivative works thereof, in binary and
> source code
> > >>>>> form.
> > >>>>> ---------------------------
> > >>>>> The rationale:
> > >>>>>
> > >>>>> The LBNL BSD has been in use since 2003. It has an ADDED paragraph
> at the
> > >>>>> end that makes it easier to accept improvements without a specific
> grant
> > >>>>> required.
> > >>>>>
> >
> > _______________________________________________
> > License-review mailing list
> > License-review at lists.opensource.org
> >
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
>
> --
> Richard Fontana
> Senior Commercial Counsel
> Red Hat, Inc.
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

On Fri, May 17, 2019, 10:59 AM Richard Fontana <rfontana at redhat.com> wrote:

> On Fri, May 17, 2019 at 10:37 AM Smith, McCoy <mccoy.smith at intel.com>
> wrote:
> >
> > I’m curious why, if this license has been used successfully for 16
> years, OSI approval is needed at all? Has the lack of OSI approval suddenly
> resulted in prospective licensees declining to use code under this license?
>
> Probably not. I would assume there's just low awareness of it. But
> I've noticed that OSI has recently come under some attack from a
> not-insubstantial number of people in the wake of the perceived
> rejection of certain experimental business-model-facilitative copyleft
> licenses. The attack in part goes to OSI's claim to say what open
> source licenses *are* and the fact that Linux distributions distribute
> packages embodying hundreds more licenses than are in the OSI's
> approved catalogue, while characterizing (most of) those licenses as
> free software/open source, is something some of these critics point to
> in what I think is an attempt to undermine the OSI's authority. For
> that sort of reason I can see some benefit to some mass effort to get
> legacy approval for that larger set of obviously-FOSS licenses (not
> saying that this BSD-LBNL license is one of them, though if I ever
> consciously looked at this license in the past that's probably what I
> would have concluded).
>
> I can't find the tweet but on Twitter recently Van Lindberg expressed
> the view that for distros like Debian or Fedora, the only portions of
> them that can legitimately be called "open source" are those that are
> licensed under an OSI-approved license. I do not agree with this at
> all, and if the legacy approval mechanism can help respond to this
> sort of viewpoint then it can only be beneficial to OSI.
>
> Richard
>
>
> > Also, I think generally OSI should discourage licenses with text that is
> specific to a particular entity or entities, which is the case with clause
> (3).
> >
> > > On May 17, 2019, at 6:48 AM, Kevin P. Fleming <kevin+osi at km6g.us>
> wrote:
> > >
> > > The request is for "legacy" aprpoval, and if approved that will mean
> > > that usage of the license is discouraged, right?
> > >
> > > On Fri, May 17, 2019 at 6:36 AM Bruce Perens via License-review
> > > <license-review at lists.opensource.org> wrote:
> > >>
> > >> I always appreciate your comments, John, but I'd like to hear from
> Sebastian this time. Is this important enough to have yet another license
> adding to the license proliferation problem?
> > >>
> > >>    Thanks
> > >>
> > >>    Bruce
> > >>
> > >>> On Thu, May 16, 2019 at 7:12 PM John Cowan <cowan at ccil.org> wrote:
> > >>>
> > >>> Well, I suppose because of the default copyleft.  If you publish a
> derivative work and *don't* give it a specific license, it gets the LBNL
> BSD by default rather than the usual default, which is no-license.
> > >>>
> > >>>> On Thu, May 16, 2019 at 7:11 PM Bruce Perens via License-review <
> license-review at lists.opensource.org> wrote:
> > >>>>
> > >>>> Why do they still need to use this rather than the plain BSD
> license?
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> Bruce
> > >>>>
> > >>>>
> > >>>>> On Thu, May 16, 2019, 16:33 Sebastian Ainslie <sainslie at lbl.gov>
> wrote:
> > >>>>>
> > >>>>> The license:
> > >>>>>
> > >>>>> Copyright (c) XXXX, The Regents of the University of California,
> through
> > >>>>> Lawrence Berkeley National Laboratory (subject to receipt of any
> required
> > >>>>> approvals from the U.S. Dept. of Energy). All rights reserved.
> > >>>>> Redistribution and use in source and binary forms, with or without
> > >>>>> modification, are permitted provided that the following conditions
> are met:
> > >>>>>
> > >>>>> (1) Redistributions of source code must retain the above copyright
> notice,
> > >>>>> this list of conditions and the following disclaimer.
> > >>>>>
> > >>>>> (2) Redistributions in binary form must reproduce the above
> copyright
> > >>>>> notice, this list of conditions and the following disclaimer in the
> > >>>>> documentation and/or other materials provided with the
> distribution.
> > >>>>>
> > >>>>> (3) Neither the name of the University of California, Lawrence
> Berkeley
> > >>>>> National Laboratory, U.S. Dept. of Energy nor the names of its
> contributors
> > >>>>> may be used to endorse or promote products derived from this
> software
> > >>>>> without specific prior written permission.
> > >>>>>
> > >>>>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> > >>>>> AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > >>>>> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > >>>>> ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > >>>>> LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > >>>>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> > >>>>> SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > >>>>> INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> > >>>>> CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > >>>>> ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> > >>>>> POSSIBILITY OF SUCH DAMAGE.
> > >>>>>
> > >>>>> You are under no obligation whatsoever to provide any bug fixes,
> patches, or
> > >>>>> upgrades to the features, functionality or performance of the
> source code
> > >>>>> ("Enhancements") to anyone; however, if you choose to make your
> Enhancements
> > >>>>> available either publicly, or directly to Lawrence Berkeley
> National
> > >>>>> Laboratory, without imposing a separate written license agreement
> for such
> > >>>>> Enhancements, then you hereby grant the following license: a
> non-exclusive,
> > >>>>> royalty-free perpetual license to install, use, modify, prepare
> derivative
> > >>>>> works, incorporate into other computer software, distribute, and
> sublicense
> > >>>>> such Enhancements or derivative works thereof, in binary and
> source code
> > >>>>> form.
> > >>>>> ---------------------------
> > >>>>> The rationale:
> > >>>>>
> > >>>>> The LBNL BSD has been in use since 2003. It has an ADDED paragraph
> at the
> > >>>>> end that makes it easier to accept improvements without a specific
> grant
> > >>>>> required.
> > >>>>>
> >
> > _______________________________________________
> > License-review mailing list
> > License-review at lists.opensource.org
> >
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
>
> --
> Richard Fontana
> Senior Commercial Counsel
> Red Hat, Inc.
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190518/9b78411c/attachment-0001.html>