<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 22, 2019 at 10:21 AM Nicholas Matthew Neft Weinstock <<a href="mailto:nweinsto@qti.qualcomm.com">nweinsto@qti.qualcomm.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 lang="EN-US">
<div class="gmail-m_3502146559026420863WordSection1">
<p class="MsoNormal">I agree, it would be very helpful to have a clear statement of the intent of that paragraph in (A)GPLv3.</p></div></div></blockquote><div><br></div><div>FSF in general does not make definitions because they wish to use the full extent of what the local law will allow them.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">On Sunday the 13^th, Lukas discussed the idea that “intimate” communication is in regards to distributing Corresponding Source, so the license must mean that “anything needed to run the software” must also be released under (A)GPLv3. 
 He effectively suggests that if a GPLv3 application is developed so that it cannot run without a given library, the library must also be released under (A)GPLv3.</p></div></div></blockquote><div><br></div><div>The complete and corresponding source code must include whatever is needed to build and install the program with all functionality of the hardware enabled as it was in the binary conveyed by the manufacturer. This doesn't mean you have to license libraries under a GNU license, just that they are available in a form which is compatible with the GNU license. There is the system libraries exception, etc. And if you are GPL-shy and naive, you can license the necessary tools under a permissive license.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The next day, on Monday the 14^th, John Cowan described the idea in the exact inverse: If you develop an application so that it cannot run without a given (A)GPLv3 library, your application must also be released under (A)GPLv3.</p></div></div></blockquote><div><br></div><div>AGPL and GPL are not conventional library licenses which allow unrestricted licensing of applications, so yes, this is true.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Both are tempting, but I’m not sure that either makes sense in all situations.</p></div></div></blockquote><div><br></div><div>Be careful with "makes sense", I have seen engineers and their managers use that in court and make total fools of themselves. You have to comply with the license whether or not it fits with conventional process in your industry. </div><div><br></div><div>Also, remember that dynamic linking doesn't matter, once courts have found APIs to be copyrightable (as they did in <i>Oracle v. Google)</i>. The license applies whether you dynamically link something or not. IMO dynamic linking never was protective, but that is another discussion.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">But what if I want to modify an existing open source application under GPLv3 to interact with an existing open source library under one of the licenses that are not
 compatible with GPLv3 (as discussed by GNU.org at <a href="https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses" target="_blank">
https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses</a>)?  Does this mean I’m not allowed to modify the application to work with the library?</p></div></div></blockquote><div><br></div><div>Yes, that's right.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"> If I modify the application to work with the library, but the application is also capable of
 working without the library (similar to 2(a) from LGPLv3), does this mean it’s no longer “intimate” since the library is no longer
<i>needed</i> to run the software?<u></u><u></u></p>
<p class="MsoNormal"><u></u> </p></div></div></blockquote><div>Intimacy doesn't matter for this example. You can't combine works under incompatible licenses. Period.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">What if I want to modify an existing application that is under an incompatible
 open source license to work only with an LGPLv3 library, and the application’s license requires me to distribute as source?  LGPLv3 doesn’t grant any additional permissions that would save the application in this case.</p></div></div></blockquote><div><br></div><div>Try rephrasing the question, it doesn't make sense this way.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Although it’s not directly relevant because of different license versions, I’d also point out that John’s interpretation goes against the so-called “Torvalds Exception.” </p></div></div></blockquote><div><br></div><div>The "Torvalds exception" is not an exception, it was inherent in the GPL as written. And in any case it would not apply to anything but the kernel.</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 lang="EN-US"><div class="gmail-m_3502146559026420863WordSection1"><p class="MsoNormal">
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">One other point of consideration:  When I give training on open source licenses, this idea of “intimate” nearly always comes up.  I lead the class (generally Engineers not trained in law nor familiar with the GPLv3 background) in a discussion
 of what it might mean.  Some other notable ideas I’ve heard:<u></u><u></u></p>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_3502146559026420863MsoListParagraph" style="margin-left:0in">Maybe it means only if the two are developed together, so that the application and library are both developed to run only with each other.<u></u><u></u>
<ul style="margin-top:0in" type="circle">
<li class="gmail-m_3502146559026420863MsoListParagraph" style="margin-left:0in">Slight modification: Could also include if both were modified in regards to the specific “intimate” data communications.<u></u><u></u></li></ul>
</li><li class="gmail-m_3502146559026420863MsoListParagraph" style="margin-left:0in">Maybe it needs to be complex data structures, so if the interaction only uses default data types present in the language (e.g., int, char, bool, String) it can’t ever be intimate.<u></u><u></u></li><li class="gmail-m_3502146559026420863MsoListParagraph" style="margin-left:0in">Maybe grammatically it should be read as “communication of intimate data” which is judging the data being communicated, so a banking app communicates intimate data but a weather app
 does not.</li></ul></div></div></blockquote><div><br></div><div>Actually, if this comes up, you might not be giving the right advice to your trainees. They should be trained in how to build bright lines between software under reciprocal licenses and their proprietary software. If they are considering making this sort of combination, something's gone wrong. There are less risky ways to combine proprietary software and works under a reciprocal license.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce </div></div></div>