<div dir="ltr"><div><span style="color:rgb(0,0,0)"><font size="1">(Forgive the resend, my email address changed).</font></span></div><div><span style="color:rgb(0,0,0)"><br></span></div><span style="color:rgb(0,0,0)">A license with parameters such that end users are advised to first engage a legal expert to help craft a usage architecture, seems to be lacking completion. Licenses should speak for themselves. I'm glad there is a community of informed lawyers I can find and call upon when needed for open source issues. I wish the licenses were so clear the need for these services were less. A cynic would suggest that new licenses could be written with even less clarity by lawyers who want to secure more future business. I'm not that cynic.</span><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">A license such that "we all know what it means" but some of us are still worried that a court reads into the text a meaning that we were sure was not intended, but does fit the plain meaning (e.g. interpreting intimacy in an overly broad way than the expressed feelings of people on a mailing list), seems to be incomplete (albeit the reality in law). An open source license is supposed to invite use and adoption under terms that the user can understand. It should not invite doubt and speculation about how to call an API or driver to avoid the unintended situation where a product is accidentally considered part of a copyleft scope. (And thus commercial licenses should be sold to exchange value for money, not to reduce concerns of license parameters.)</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">I respect the care involved in crafting the license we have today. As we encounter new product architectures that might not have been anticipated by the drafters of the licenses, we need to refine the parameters. I wondered why we don't have an A/LGPL (or A/MPL, A/EPL) that addresses the "non-conveyed software gap" but also limits the scope of copyleft to the work itself. Moreover, I still am humored by the term <i>intimacy</i> since it usually implies the invitation to know each other without doubts, and in this case, it feels like kissing with eyes open, looking around.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)"><b style="color:rgb(103,78,167);font-family:georgia,serif">Gil Yehuda</b><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 11:39 AM John Cowan <<a href="mailto:cowan@ccil.org">cowan@ccil.org</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-89605188537184576gmail_attr">On Wed, Jan 23, 2019 at 1:27 AM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br></div><div dir="ltr" class="gmail-m_-89605188537184576gmail_attr"><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 class="gmail_quote"><div>It's not fair to blame FSF for what the court did in an entirely unrelated case.</div></div></div></blockquote><div> </div><div>On the contrary, alas. The FSF's GPL FAQ says:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.</blockquote><div><br></div><div>Of course, data structures themselves can't be interchanged over a pipe, only representations of them. ASCII text giving information about available print queues is just as much a representation of the system's undocumented internal data structures as anything else. (Dr. Google informs me that NET PRINT is no more.) <br></div><div><br></div><div>And I think it is fair to blame the FSF for introducing an undefined term, not known to be a term of art, into the GPL3, and thus putting a weapon into the hands of those who use the GPL solely for commercial advantage and/or employ the SCO business model.</div><div><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 class="gmail_quote"><div> Nor is it fair to say that FSF wants to sue you until your eyes bubble.</div></div></div></blockquote><div><br></div><div>I thought that using a classic P.G. Wodehouse-ism would be enough to indicate that I wasn't _entirely_ serious. Though now that I look it up, it was Asimov (who is known to have been a PGW fan) who used it in connection with a threatened lawsuit, _God v. Satan_, over Satan's delinquent payments for upkeep on the Heaven-Hell Bridge. Of course God is doomed to lose because he can't get a lawyer. :-)</div><div><br></div><div>Rick Moen wrote:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is little<br>reason to think judges will ever be impressed by coders' ideas<br>concerning internal vs. external APIs, different sorts of linking,<br>wrappers, remote calls, etc. </blockquote><div><br></div><div>Well, some reason. Industry usage is an accepted source of the</div><div>meaning of undefined terms in contracts, along with common usage,</div><div>prior dealings, etc. The trouble is that "intimate data communication"</div><div>_has_ no industry usage.</div><div><br></div><div>-- </div><div><div>John Cowan <a href="http://vrici.lojban.org/~cowan" target="_blank">http://vrici.lojban.org/~cowan</a> <a href="mailto:cowan@ccil.org" target="_blank">cowan@ccil.org</a></div><div>After fixing the Y2K bug in an application:</div><div> WELCOME TO <censored></div><div> DATE: MONDAK, JANUARK 1, 1900</div></div><div><br></div></div></div></div></div>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>