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