Kevin P. Fleming wrote: >>> Please keep in mind that if your application incorporates or relies upon >>> any other code (to which you do not hold the copyrights) that is also >>> licensed under the AGPL, you cannot grant an exception (really, an >>> 'additional permission') on your code which is combined with it, since >>> you can't grant that same additional permission on the third-party code >>> you are using.
Kevin is — of course — correct, but I did take Joel's original inquiry as asking on behalf of a project that's just getting started (and/or just about to be released), and in that situation, it's likely they are in touch with all the copyright holders. But, I agree with Kevin that Joel must first check Kevin's point above as a threshold question. On the three examples Joel found: This one doesn't seem like it has any additional permissions: > https://github.com/grafana/grafana/blob/HEAD/LICENSING.md Did I miss something? > https://docs.shopware.com/en/shopware-5-en/tutorials-and-faq/agpl This one seems more like a statement of "intent to provide an additional permission later" than an *actual* additional permission. Does their code repository have an actual additional permission present? > https://github.com/translate5/translate5/blob/develop/plugin-exception.txt Prima facie, this one seems "just ok" — the problem is that it's very specific to the software in question, and has some ambiguities. It's hard for me to recommend its use because of that. I'm also curious what Richard Fontana thinks. Generally speaking, when drafting additional permissions, the true art is finding a way to make it general enough that it has more than one-off usefulness but not so general that it completely eviscerates the copyleft requirements of the main license. Having been a key drafter of the Classpath Exception, the GCC RTL Exception, and Web Template Output Additional Permission (WTO-AP, used by the Houdini project), I have found that additional permission drafting is sometimes even more difficult than primary license drafting. I have various complaints about the outcome of those three additional permissions — even though I have intimate knowledge why they are ultimately worded the way that they are. The theory of 'additional permissions' is better than the practice. For everything but the most trivial, you'll need drafting help of someone with serious experience drafting copyleft licenses to get an outcome that doesn't just confuse people and/or eviscerate the copyleft entirely. Furthermore, folks who are really interested in copyleft and its policy goals, as I am, are going to ask you this question first: *Why* do you feel that you must permit proprietary plugins to your application in the first place? What is the policy goal you're trying to achieve, and why does a pure application of the license not achieve it? We asked these questions first before helping the Houdini project create the WTO-AP, and I think the outcome was much better for it, because we were able to narrow in on the exact area that required the AP. Finally, keep in mind that while additional permissions are fully permitted by the GPLv3 family of licenses, they are used in practice so rarely that users are usually quite confused by them. Thus, if your reason for adding an Additional Permission is to "gain adoption" from folks who don't like the AGPLv3, it's likely to have the opposite effect. On Wed, Aug 10, 2022 at 3:07 PM McCoy Smith <mc...@lexpan.law> wrote: > > You might want to check out the SPDX lists of exceptions: > > https://spdx.org/licenses/exceptions-index.html This is a strange suggestion as answer to Joel's query, most importantly because AFAICT none of the additional permissions listed there are drafted for AGPL, but also because the list is just a tiny subset of the additional permissions that are widely used. -- bkuhn _______________________________________________ The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
