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

[Gil Yehuda]

(Forgive the resend, my email address changed).

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.

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

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

*Gil Yehuda*

On Wed, Jan 23, 2019 at 11:39 AM John Cowan <cowan at ccil.org> wrote:

>
>
> On Wed, Jan 23, 2019 at 1:27 AM Bruce Perens <bruce at perens.com> wrote:
>
> It's not fair to blame FSF for what the court did in an entirely unrelated
>> case.
>>
>
> On the contrary, alas.  The FSF's GPL FAQ says:
>
> 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.
>
>
> 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.)
>
> 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.
>
> Nor is it fair to say that FSF wants to sue you until your eyes bubble.
>>
>
> 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.  :-)
>
> Rick Moen wrote:
>
> There is little
>> reason to think judges will ever be impressed by coders' ideas
>> concerning internal vs. external APIs, different sorts of linking,
>> wrappers, remote calls, etc.
>
>
> Well, some reason.  Industry usage is an accepted source of the
> meaning of undefined terms in contracts, along with common usage,
> prior dealings, etc.  The trouble is that "intimate data communication"
> _has_ no industry usage.
>
> --
> John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
> After fixing the Y2K bug in an application:
>         WELCOME TO <censored>
>         DATE: MONDAK, JANUARK 1, 1900
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190123/47ee3809/attachment-0001.html>