On 8/12/22 16:46, Joel Kelley wrote:
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.
So your challenge here, should you allow a general "plugin exception", is that there is no difference between "plugin to validate offer letters" and "plugin to automate this application on AWS". Unless ... you make one. That is, if you've identified three areas for plugins, then make the plugin exception only for those three APIs. The lawyers on this list can comment on that from a legal perspective.
Also note that the AGPL doesn't require their contributions to come back to the main project, they just need to be open source somewhere, which can just be a matter of creating their own public GH/GL repo.
-- Josh Berkus _______________________________________________ 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
