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

Lawrence Rosen lrosen at rosenlaw.com
Wed Jan 23 20:06:26 UTC 2019


Gil Yehuda wrote:
> 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.

 

We do. OSL 3.0. 

 

In all other respects, I agree with Gil's email.

 

> it feels like kissing with eyes open, looking around

 

Bruce Perens also reminded me.... It feels like I did while serving on the GPLv3 drafting committee. It was a difficult experience, but it turned out better than GPLv2. No intimacy remains, however....

 

/Larry

 

 

From: License-discuss <license-discuss-bounces at lists.opensource.org> On Behalf Of Gil Yehuda via License-discuss
Sent: Wednesday, January 23, 2019 8:47 AM
To: license-discuss at lists.opensource.org
Cc: Gil Yehuda <gyehuda at verizonmedia.com>
Subject: Re: [License-discuss] Intimacy in open source (SSPL and AGPL)

 

(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 <mailto:cowan at ccil.org> > wrote:

 

 

On Wed, Jan 23, 2019 at 1:27 AM Bruce Perens <bruce at perens.com <mailto: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 <mailto: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 <mailto: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/12c694c8/attachment-0001.html>


More information about the License-discuss mailing list