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

[Tzeng, Nigel H.]

Licenses clearly intended to prevent combination with any commercial/proprietary work is clearly not open source.

Licenses clearly intended to prevent commercial/proprietary derivatives can be open source.

If an API isn’t a bright line for defining open source then your definition is incorrect because that’s just use of a literal copy which any open source license should allow for.  It’s freedom 0.

Using a developer provided API shouldn’t create any triggerable “intimacy” and any definition/criteria that implies such is clear overreach and should NOT be part any open source criteria.

Speaking for myself,

Nigel

From: Bruce Perens <bruce at perens.com<mailto:bruce at perens.com>>
Date: Tuesday, Jan 22, 2019, 11:18 PM
To: Lawrence Rosen <lrosen at rosenlaw.com<mailto:lrosen at rosenlaw.com>>
Cc: license-discuss at lists.opensource.org <license-discuss at lists.opensource.org<mailto: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!
<http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org>
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/20190123/e5f98200/attachment.html>