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

[Lawrence Rosen]

Bruce Perens wrote:

> If you want to make a product, I will discuss with you how to resolve the issue for the particular problem you have, which mostly means you won't be creating a derivative work of any kind, but will be architecting a bright line between the free and proprietary pieces that would be extremely clear to any court.

 

Bruce, that I agree with. I believe that is good advice. The boundary line is a derivative work. But that is different from "Corresponding Source" or "intimacy". The INTENT of the license must be clear, but not with words or phrases that are vague and too broad. They should say precisely what they mean, and what apparently you also mean. :-)

 

/Larry

 

 

From: Bruce Perens <bruce at perens.com> 
Sent: Tuesday, January 22, 2019 8:17 PM
To: Lawrence Rosen <lrosen at rosenlaw.com>
Cc: license-discuss at lists.opensource.org
Subject: Re: [License-discuss] Intimacy in open source (SSPL and AGPL)

 

 

 

On Tue, Jan 22, 2019 at 8:02 PM Lawrence Rosen <lrosen at rosenlaw.com <mailto:lrosen at rosenlaw.com> > wrote:

What particular architectural design do you recommend? I want an architecture that always permits a programmer to implement her own software in accordance with a published API, under any FOSS or proprietary license she chooses, and thereby let her software become intimate with some other open source software. 

 

No FOSS license that prohibits that is truly open source!

Oh, come on, Larry. If you want to write software and combine it with software under a license that is clearly intended to prevent combination with proprietary software, you are entirely free to use their API under a license compatible with their chosen one and release it as their terms require. There is nothing about Open Source that says they have to give a free ride to anyone, no less deep-pocket companies that are extremely jealous of their own intellectual property rights.

 

If you want to make a product, I will discuss with you how to resolve the issue for the particular problem you have, which mostly means you won't be creating a derivative work of any kind, but will be architecting a bright line between the free and proprietary pieces that would be extremely clear to any court.

 

    Thanks

 

    Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190122/037d2a90/attachment-0001.html>