[License-discuss] Intimacy in open source (SSPL and AGPL)

[Bruce Perens]

On Tue, Jan 22, 2019 at 10:21 AM Nicholas Matthew Neft Weinstock <
nweinsto at qti.qualcomm.com> wrote:

> I agree, it would be very helpful to have a clear statement of the intent
> of that paragraph in (A)GPLv3.
>

FSF in general does not make definitions because they wish to use the full
extent of what the local law will allow them.


>
> On Sunday the 13th, 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.
>

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.


>
>
> The next day, on Monday the 14th, 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.
>

AGPL and GPL are not conventional library licenses which allow unrestricted
licensing of applications, so yes, this is true.


>
>
> Both are tempting, but I’m not sure that either makes sense in all
> situations.
>

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.

Also, remember that dynamic linking doesn't matter, once courts have found
APIs to be copyrightable (as they did in *Oracle v. Google)*. The license
applies whether you dynamically link something or not. IMO dynamic linking
never was protective, but that is another discussion.


>
> 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
> https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses)?
> Does this mean I’m not allowed to modify the application to work with the
> library?
>

Yes, that's right.


> 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 *needed* to run the software?
>
>
>
Intimacy doesn't matter for this example. You can't combine works under
incompatible licenses. Period.


> 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.
>

Try rephrasing the question, it doesn't make sense this way.


>
> 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.”
>

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.


>
>
> 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:
>
>    - 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.
>       - Slight modification: Could also include if both were modified in
>       regards to the specific “intimate” data communications.
>    - 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.
>    - 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.
>
>
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.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190122/105fdee2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1393 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190122/105fdee2/attachment-0001.png>