<div dir="ltr"><div>They're certainly mostly terrible. (The covenant-condition thing, for example, is universally a mess.) So if you want to go ahead and defend the state of our licensing by saying
"all licenses are terrible" I guess I'm not going to argue that very
hard? But, just as one example, I'm hard-pressed to recall a commercial software contract that didn't at least somewhat deal with SaaS, even if briefly (Yes! No!, etc.). And of course almost all OSI-approved copylefts fail to grapple with that at all.<br></div><div><br></div><div>I'd think we should aspire to serve our community's needs better
than that. I don't believe the need for copyleft/anti-free-riding magically went away in the mid-2000s, but that's certainly the conclusion you'd draw from our collective effort as a legal community.<br></div><br><div>Luis<br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 9:19 PM Richard Fontana <<a href="mailto:richard.fontana@opensource.org">richard.fontana@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree with the point that OSI, and OSI-approved licenses, shouldn't stay trapped in amber, but I have to take issue with the idea that the problem is specific to open source and that outside of open source, software licenses have changed radically to adapt to changing technological and economic circumstances. At least, I don't think I've seen this in proprietary commercial software licenses at all, beyond the fact that negotiated agreements can address specific issues and circumstances in ways that form agreements are less likely to. I'm generally struck by how conservative, technically and perhaps legally clueless and hidebound contemporary proprietary software license agreements tend to be - though not in the same way as open source licenses, which are vulnerable to similar criticisms. <div><br></div><div></div></div><div dir="ltr"><div><div>Richard</div></div></div><div dir="ltr"><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 11:57 PM, Luis Villa <span dir="ltr"><<a href="mailto:luis@lu.is" target="_blank">luis@lu.is</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>[Changing the subject line back for those who'd like to ignore tools discussion or vice-versa]<br></div><div><br></div><div>The software industry has a completely different economic and technological infrastructure than it did when OSI was founded and when most of these licenses were written. Every other software licensing agreement in the industry has changed radically since the mid-2000s as a result. It is not healthy that the OSI's license selection (and possibly the OSD) have not followed suit. Frankly, I think a lot of the "<a href="http://lu.is/blog/2013/01/27/taking-post-open-source-seriously-as-a-statement-about-copyright-law/" target="_blank">post open source</a>" thing is really "open source licenses are nearly completely unresponsive to the software industry as it actually exists in the year 2018". <br></div><div><br></div><div>I'm pretty sure that, contra Bruce, it isn't OSI's position that open source needs to stay forever trapped in amber, but a reasonable outside observer (like Kyle!) could certainly conclude otherwise.<br></div><div><br></div><div>Luis</div><div><br></div><div>P.S. To respond to the claim that licensing improvements are no longer possible, significant input that MPL 2.0 responded to in various subtle but important ways:</div><div><ul><li>various cases around the covenant / condition difference (thanks in part to members of this list)<br></li><li>then-state-of-the-art changes in Javascript compilation (shouldn't be any unexpected surprises there, unlike the case for some licenses)<br></li><li>vast improvements in readability to reflect the broadening base of open source developers who lack legal expertise<br></li><li>GPL v3-style termination</li><li>explicit permission for additional disclaimers (has proven very useful in the medical space)</li><li>patent termination that reflected the actual mechanisms by which patents were being granted to open source communities (which, IMHO, we'd all be better off if Apache and FSF adopted) <br></li></ul><div>And that's just off the top of my head, in a license that had as a deliberate design goal not rocking the boat.<br></div><div><br></div><div>Changes since then that even a fairly conservative new license might consider responding to:</div><div><ul><li>What does a network services license look like in a microservices world? what about serverless? what about a Javascript-dominated world?<br></li><li>How should notice requirements respond to state-of-the-art in app stores, package managers, GitHub, SPDX, and general trend towards "WTFPL"-attitude in next-generation open source development? (What current licenses *say*, and what all these *do*, are often at odds in ways that would be very profitable for a determined troll.)<br></li><li>How should drafting respond to license wizards, CC-style human-readable licenses, and other attempts to make licensing "easy"?</li></ul><div>A bolder new license might consider:<br></div><ul><li>What does an economically viable open source look like?<br></li><li>How do you get Facebook, Amazon, Google, Twitter, etc., on board with a network services copyleft? When you talk to people at these places, many of them would like to prevent free-riding by their competitors, and would look very seriously at a network copyleft that was perceived to be pragmatic. The vast, gaping hole in this area is a damning condemnation of our work as an open legal community.<br></li><li>How should we think about our role as an extra-institutional legal system? Eben and Richard took some good steps there by documenting everything (in recognition of the quasi-constitutional nature of the license) but I think there's a lot of potential to explore here.</li></ul></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 7:28 PM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">OK, so not just whether it passes the OSD but whether it provides any unique value, too.<div><br></div><div>Sure we need new licenses for new case law. But how many of the licenses submitted actually <i>were </i>an attempt to catch up with new case law? There hasn't been much other than GPL3.</div><div><br></div><div> Thanks</div><div><br></div><div> Bruce<br><div class="gmail_extra"></div></div></div><div dir="ltr"><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 7:18 PM, Allison Randal <span dir="ltr"><<a href="mailto:allison@opensource.org" target="_blank">allison@opensource.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bruce,<br>
<br>
I'm a firm supporter of the license proliferation position that the OSI<br>
adopted over a decade ago, and we do continue to consider whether a new<br>
license is offering unique value.<br>
<br>
But, I consider it highly unlikely that we have such a perfect set of<br>
open source license versions today that we'll never need to change them.<br>
Especially since the law that open source licenses are built on keeps<br>
changing, so over time open source licenses will need to evolve to cope<br>
with a legal environment that the current licenses couldn't anticipate.<br>
<br>
Allison<br>
<span><br>
On 06/19/2018 06:02 PM, Bruce Perens wrote:<br>
> Allison,<br>
> <br>
> The biggest problem here is not that OSI is slow to approve licenses,<br>
> that they provide insufficient feedback, or that they are using the<br>
> wrong software.<br>
> <br>
> It's a greater problem that OSI continues to approve licenses on a<br>
> regular basis, twenty years after the process started.<br>
> <br>
> There aren't that many actually useful variations on the licenses that<br>
> actually pass the OSD. There are actually only three useful licenses, a<br>
> gift-style, a sharing-with-rules-style, and something in between. Given<br>
> Affero and GPL3 terms on those three, essentially all purposes for Open<br>
> Source can be carried out. All else is embellishment.<br>
> <br>
> What we are seeing now are licenses that satisfy a particular attorney.<br>
> These are often introduced as being necessary for the specific needs of<br>
> the venue (Europe, for example) or a particular organization (NASA,<br>
> focusing on restrictions on the public domain). It's arguable that these<br>
> licenses are more useful than existing well-tested ones, even for those<br>
</span>> organizations. For example, I don't see how NASA can /really /benefit<br>
<span>> from imposing terms upon public-domain works or making itself a<br>
> secondary beneficiary of licenses executed by others.<br>
> <br>
> The license reviewers aren't waiting to be surprised by some worthy<br>
> innovation in Open Source licensing. No such thing is coming by. They<br>
> are mainly working to make sure that OSI understands when a license<br>
> should be rejected, and why.<br>
> <br>
> If OSI were to conclude that licenses, at this point, should be approved<br>
</span>> only when there are /compelling /reasons to do so, the community would<br>
> benefit.<br>
> <br>
> Thanks<br>
> <br>
> Bruce<span><br>
> <br>
> <br>
<div class="m_-6163474792248412040m_8333930886668330933m_4280207377860326719HOEnZb"><div class="m_-6163474792248412040m_8333930886668330933m_4280207377860326719h5">> _______________________________________________<br>
> License-review mailing list<br>
> <a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
> <br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</div></div></span></blockquote></div><br><br clear="all"><div><br></div></div></div></div><span><div dir="ltr"><div><div class="gmail_extra">-- <br><div class="m_-6163474792248412040m_8333930886668330933m_4280207377860326719gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Bruce Perens K6BP - CEO, Legal Engineering<br>Standards committee chair, license review committee member, co-founder, Open Source Initiative<div>President, Open Research Institute; Board Member, Fashion Freedom Initiative.<br></div></div></div></div></div></div></div>
</div></div></div></span><span>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</span></blockquote></div></div>
<br>_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
<br></blockquote></div><br></div></div></div></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>