[License-discuss] Question about AGPLv3 with a Plugin Exception

Tue Aug 16 23:30:44 UTC 2022

Ben,

The companies I do Open Source compliance work for would not be inclined to
approve an Open Source review of what you suggest for use in the
company, due to ambiguity.

Licenses can, and should, clearly state when an API is meant to be a
connector to another work which can be under a different license and is not
to be considered derivative. Handwaving about what a court should do when
faced with two differently-licensed products implementing the same API is
an invitation to long and pointless litigation about the developer's
intent, etc. We don't want to win in court about this sort of thing. We
want to never go to court.

    Thanks

    Bruce

On Tue, Aug 16, 2022 at 9:36 AM Ben Tilly <btilly at gmail.com> wrote:

> Here is a solution that is worth considering.
>
> Create 2 pieces of software that are compatible.  One is under a BSD
> license and will accept the plugins in question.  The other is under the
> AGPL.  Any plugin written against the BSD version is clearly not derivative
> of the AGPL version and therefore can be under any BSD compatible license.
> And it should work against the AGPL version.  Any plugin which only works
> with the AGPL version has to be covered by the AGPL.
>
> In practice this boils down to a complicated way to say, "Here is the
> defined API that you can use without legal problems."
>
> On Sun, Aug 14, 2022 at 9:39 AM Joel Kelley <jkelley at georgefox.edu> wrote:
>
>> Dear All,
>>
>> I would like to thank you all for your kind and helpful responses.
>>
>> To provide some background, hopefully helpful, on the application in
>> question, it helps manage timesheets, faculty contracts, and student offer
>> letters as are commonly used in Higher Education.  It is a web application
>> written in Python with Flask that is designed to integrate with a
>> University's Enterprise Resource Planning (ERP) system.  Though with effort
>> it could be run as a stand alone system.
>>
>> The application’s development has helped George Fox University in some
>> needed ways, particularly during the pandemic, and we would like to be able
>> to share it openly with other institutions.  Having benefited from Open
>> Source Software ourselves, this is the model we are looking towards for
>> sharing this application..  We would like to use the AGPLv3 to protect
>> against the case of a vendor taking the application, putting it behind a
>> Software as a Service (SaaS) setup and not contributing anything back to
>> the community.  If a vendor wants to do something like that, we at least
>> want the comfort of knowing they have to release their changes to the
>> community as well.
>>
>> We are interested in a plugin exception due to the reality of software
>> development at colleges and universities, particularly mid-sized and
>> smaller institutions.   A few areas we've broken out into plugins are
>> validation, approvals, and payroll exports.  Our internal plugins are
>> written now in such a way that they would be fine to Open Source, and will
>> be when the application is released.  However, a small team faced with
>> changing business rules is all too likely to end up hardcoding a position
>> or employee ID number into an approval plugin instead of using an
>> environmental variable.  Other things, like validation of what makes a
>> student offer letter valid at a particular school, or exactly how a custom
>> internal system wants payroll data formatted, just may not make much sense
>> to merge into a larger project.  Most developers given enough time to do
>> things, can code around the problems I've alluded to here.  However, we
>> didn't want to make a situation where we created an accidental incentive to
>> violate the software license and having heard of projects using a plugin
>> exception to the AGPLv3 in general sense we thought we would start looking
>> there.
>>
>> As for Kevin's excellent reminder about taking care of the license of the
>> existing code, since it's currently an internal project written by
>> University employees I don't believe there is a problem there.  We aren't a
>> fork of an existing project.  Looking at the third party libraries we use,
>> fairly normal Python and Flask libraries, I don't see any that are AGPLv3
>> nor ones that I've heard of being a problem with AGPLv3.  I'm a programmer
>> not a lawyer though, which is why someone else will be doing a quick review
>> before release.
>>
>> As for the grafana example I found that link on their blog post talking
>> about a relicensing decision they made, the originating blog post was:
>> https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relicensing-to-agplv3/
>>
>> Also, while I didn't see a match for what I was looking for in the SPDX
>> list, it was interesting to see how additional permissions have been used
>> elsewhere.  However, I was, perhaps naively, hoping that there was an off
>> the shelf and community approved extension.  To McCoy's comment I would
>> like your recommendation on someone in Oregon my University could talk to
>> so I could pass the name on.
>>
>> As to Bradley's question of "are you really sure this is what you need?"
>> I'm not entirely sure.  I'm not really worried about how something like
>> this would affect my institution, but rather the often exhausted IT teams
>> at colleges and universities at large.  Also, this is a learning experience
>> for George Fox University, as it is the first large application we will be
>> Open Sourcing, but we hope not that last one.
>>
>> Thank you all again for your responses.  While the desire for a public
>> Open Source release of this application is developer led at George Fox
>> University, it does have board support and a desire to do it right, which
>> is a very fortunate place to be before a release.
>>
>>
>> From,
>>
>> Joel Kelley
>> Senior Software Engineer
>> George Fox University
>>
>>
>> On Fri, Aug 12, 2022 at 2:00 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>>
>>> McCoy Smith wrote:
>>> > the … site does list the Classpath Exception
>>> > (https://spdx.org/licenses/Classpath-exception-2.0.html) and the GCC
>>> RTL
>>> > Exception (https://spdx.org/licenses/GCC-exception-3.1.html), of
>>> which you
>>> > say you were a "key drafter," so I'm not sure why you think that site
>>> > should be dismissed.
>>>
>>> I think it's probably obvious that no author endorses every list that
>>> their
>>> works of authorship show up on.  But I think you were probably joking. 🤣
>>>
>>> In seriousness, the list isn't helpful for someone *choosing* an
>>> additional permission because (as mentioned) the list is incomplete, but
>>> also
>>> because there is no analysis of effectiveness, usefulness, efficacy and
>>> popularity on that site (by design, AFAIK).  The list gives just enough
>>> information to be dangerous for AP-seekers.  But, you're correct that a
>>> true
>>> unified catalog of APs and analysis of them does not exist.
>>>
>>> Tangentially, this blog post that my colleague Karen and I wrote might
>>> be of
>>> some interest in this context.  In it, we analyze two different
>>> additional
>>> permissions that are attempting to accomplish the same task and explain
>>> why
>>> (in our opinion) one is a better choice than the other:
>>> https://sfconservancy.org/blog/2019/may/11/termination-backports/
>>>
>>> While the post is about additional permissions unlike the one Joel is
>>> pondering, the on-topic point there is that there are so many ways to
>>> draft
>>> these things, and so many potential pitfalls, and that is what leads me
>>> to
>>> first focus on “are you really sure this is what you need?”  questions
>>> first.
>>>
>>>   -- 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 at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>>
> _______________________________________________
> 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 at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>

-- 
Bruce Perens K6BP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20220816/4959d7d4/attachment.html>