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

Wed Jan 23 03:52:45 UTC 2019

Bruce Perens wrote:

> In most cases I suggest a particular architectural design for the software which avoids gray areas in the law like this one.

Please train me. 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!

Best, /Larry

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

Oh, I could have so much fun with a question like that. But getting to the one about licenses:

People who write highly reciprocal licenses have, in general, reserved a territory for people who want to link proprietary software in the form of a different license: for FSF this is LGPL or GPL-with-exception. If you want to combine your proprietary software with software under the license they have reserved for an exclusively Free territory, do not expect them to cooperate.

I have, and continue to, help companies and their licensed counsel determine what to do in particular cases. In most cases I suggest a particular architectural design for the software which avoids gray areas in the law like this one.

    Thanks

    Bruce

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

Nick Weinstock proposed:
> A clear statement about API interaction sounds like it would go a long way to clarify this section.

Bruce Perens wrote:
> Nobody will ever make such a statement, because it would make it easier for you to do things they don't want you to do.

Bruce, I'm trying to parse this. Is "doing things" good or bad, legal or illegal, ethical or unethical, what FSF wants or doesn't want, what Bruce Perens desires or hates?

I freely implemented APIs from the day I first became a programmer. You should tell us all what you mean so I know if I was a saint or a sinner.

Bravo to Nick! /Larry

From: License-discuss <license-discuss-bounces at lists.opensource.org <mailto:license-discuss-bounces at lists.opensource.org> > On Behalf Of Bruce Perens
Sent: Tuesday, January 22, 2019 3:23 PM
To: license-discuss at lists.opensource.org <mailto:license-discuss at lists.opensource.org> 
Subject: Re: [License-discuss] Intimacy in open source (SSPL and AGPL)

Nobody will ever make such a statement, because it would make it easier for you to do things they don't want you to do.

On Tue, Jan 22, 2019 at 2:18 PM Nicholas Matthew Neft Weinstock <nweinsto at qti.qualcomm.com <mailto:nweinsto at qti.qualcomm.com> > wrote:

A clear statement about API interaction sounds like it would go a long way to clarify this section.

Some additional considerations:

* What about internal vs external APIs, so internal APIs are “intimate” but external APIs aren’t, similar to the Kernel’s UAPI?  

* Could a library require API callers be under (A)GPLv3?  Or would it need to use something like the Kernel’s MODULE_LICENSE interface?

* What is necessary for API extensions to be considered “documented user calls and data structures”?  Is it sufficient for the maintainers to integrate source modifications even if the accompanying documentation isn’t updated?  Is it sufficient for source modifications to be publicly submitted to the maintainers?  What if either of those were maintainers of a distinct fork rather than the original project?  Is it sufficient for me to publish my modified version on my personal GitHub page as a one-time fork?

_______________________________________________
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/20190122/a1c0a585/attachment.html>