<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>TLDR<br></div><div>--------</div><div><br></div><div>After some long thought and many, many discussions with various folks across the spectrum, at this stage, I'm with Bruce on this one and am happy to help infrastructure projects/providers come up with a common license, but I think getting one that would be OSI approved in a short timeframe isn't going to be feasible.</div><div><br></div><div>Thre Longer version</div><div>---------------------------</div><div><br></div><div>I'm the CEO of jClarity, which is actually a proprietary software license company, a choice we partly made because we were concerned about cloud providers service wrapping our software!  So I do strongly sympathize with the commercial pressures that infrastructure projects/providers are operating under. It certainly isn't always easy to see others profiting off your hard work without contributing back in a meaningful manner, regardless of license choice. Yes, there is a potential risk that large, complex infrastructure projects won't be built under any sort of shared source or OSS auspices if investors all shy away from investing in them because they think service wrappers will kill their investment due to no license protection.<br></div><div><br></div><div>I'll repeat an often cited statement which I've repeated verbatim to several investors and founders in the last few days:<i>  "OSS is not a business model"</i><br></div><div><br></div><div>Making changes to the OSD in order to incorporate what is effectively an FOU restricted OSS License should be approached cautiously and over a much longer time period than what we're all seem to be working under right now (appreciate the commercial pressures here, see below). Maybe something like the SSPLv2 could become an OSI approved license but for now we shouldn't rush this through, the consequences are incredibly long-lasting and far-reaching and I don't think we've collectively had enough time to think all of this through yet.</div><div><br></div><div><div>With all of that in mind, I'd also like to offer my help alongside Bruce's to get the various infrastructure providers together to work on a common license that they're happy with. We could call the group the "Infrastructure License Consortium" or something else appropriate. I think this would address Greg's concern of proliferation, if all of the various players work together then they could all use the same Commons Clause, or SSPLv2, or YYY license and that could become a de-facto license for this particular service wrapper use case in the industry for whoever *wants to* use it.<br></div></div><div><br></div><div>Starting in parallel the broader ecosystem could discuss how that license could or could not be an OSI approved Open Source License. I'm sure that will be a long and involved discussion, as it should be!  Perhaps at that point, it would be appropriate as an OSI experimental license, but let's cross that bridge when we come to it.</div><div><br></div><div>Disclaimer / Background<br></div><div>--------------------------------<br></div><div><br></div><div>I'm a first-time poster, to help folks understand some of my biases etc here's a self-important listing of roles etc, apologies in advance:</div><div><br></div><div>I act as a representative (when they want me to!) for Java User Groups worldwide and spend time pulling together vendors who are normally adversarial to work in communities for the common good (e.g. AdoptOpenjDK). This topic is of great interest to parts of that community as several infrastructure projects are written in Java and these projects by their nature attempt to fulfill an important piece of the Java (and dare I say it software) ecosystem for a good length of time!  Licensing *really* matters (preaching to the converted on this obviously).</div><div><br></div><div>For my sins, I sit on the Java Community Process Executive Committee (an enterprisey mouthful I know!), the Eclipse Jakarta EE steering committee and help run the advocacy group at OpenJDK. I Am Not A Lawyer, my background is that of a non-legal 'expert' in GPLv2+CE, AGPL, EPL and Apache v2.0 as it applies to the Java ecosystem in particular.</div><div><br></div><div>Repeated from above:  I'm also the CEO of jClarity, which is actually a proprietary software license company, a choice we partly made because we were concerned about cloud providers service wrapping our software, I feel the commercial pain here.<br></div><div><br></div><div>=====</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br>Martijn</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 19 Dec 2018 at 02:31, Bruce Perens <<a href="mailto:bruce@perens.com">bruce@perens.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Dec 18, 2018 at 5:58 PM Greg Luck <<a href="mailto:greg@hazelcast.com" target="_blank">greg@hazelcast.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div style="text-align:start;text-indent:0px"><span style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span><span><span><span><span><span><span><span><div style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px"><span><font style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px">If OSI or another standards body fails to solve this problem with a general, community accepted license, which keeps open source as we know it but restricts service wrapping, then there will be plethora of new custom licenses where each open source software vendor solves the problem for themselves.</font></span></span></div></span></span></span></span></span></span></span></span></span></div></div></div></blockquote><div><br></div><div>OSI can not "solve" this problem without changing the definition of Open Source or stepping outside of the territory of Open Source to create a new commercial licensing paradigm. They can't do that. I <i>can</i> do that, and will help gratis - as I have already helped other attorneys - as long as you promise to avoid conflict with Open Source. That means you call it something else, and that you acknowledge the difference between your licensing and Open Source. Have your attorney write to me.</div><div><br></div><div>We must remain cognizant that "Open Source companies" remain in the minority of Open Source developers. Most Open Source developers do not wish to make any revenue from their software, but use it to enable another business or non-profit activity. Those folks might welcome having their software adopted by a service provider.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div style="text-align:start;text-indent:0px"><span style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span><span><span><span><span><span><span><span><div style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px"><span><font style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px">I predict the majority of popular open source infrastructure software will have defensive measures in place in the next year, all with custom licenses.</font></span></span></div></span></span></span></span></span></span></span></span></span></div></div></div></blockquote><div><br></div><div>Actually, it would not be the majority of Open Source infrastructure software. It would be the minority produced by companies which wish to directly gain revenue from that software. This is not the paradigm behind the production of most Open Source. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div style="text-align:start;text-indent:0px"><span style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span><span><span><span><span><span><span><span><div style="text-align:start;text-indent:0px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal"><span style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px"><span><font style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px">Which will require the use of a lawyer to use that software, create commercial uncertainty and be a major friction in the use of what has been open source software.<br></font></span></span></div></span></span></span></span></span></span></span></span></span></div></div></div></blockquote><div><br></div><div>Which will not be OSI or Open Source's problem. You create this problem by leaving the tent.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div><div> <br></div><div><br></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></div>