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 <[email protected]> Sent: Tuesday, January 22, 2019 4:10 PM To: Lawrence Rosen <[email protected]>; [email protected] 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 <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > On Behalf Of Bruce Perens Sent: Tuesday, January 22, 2019 3:23 PM To: [email protected] <mailto:[email protected]> 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 <[email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
_______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
