[License-discuss] Question about AGPLv3 with a Plugin Exception
Bradley M. Kuhn
bkuhn at ebb.org
Mon Aug 15 21:35:05 UTC 2022
Joel Kelley wrote:
> 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.
It's definitely an engineering problem if there is hard-coding of this sort
of information in code, rather than an input file. Nevertheless, it is a
relatively common problem and usually these engineering issues are cleaned up
as part of releasing a previously-internal codebase to the public.
Is that at all possible here?
For example, it should be relatively straightforward to add to the plugin
documentation:
"if you want to exclude an employee ID from this report, create a file
called /etc/private/app/employee-exclusion-list.conf with one-employee per
line"
Then change the code from saying:
if (employee in SET) then
to read that file and build the SET from that.
Yes, this is mundane and annoying work to ask the engineering team to do just
to release the code, but it's probably a lot less work than writing an
additional permission, which, as Bruce says, might eviscerate AGPL.
Another option is you could buy yourself time by giving *yourselves* an
exception that expires. You could write an exception that expires in three
years, that says that your entity is allowed to keep the source code of the
plugins that you write out of the Corresponding Source disclosed to users.
This isn't ideal, but it has the nice effect of, once others start
contributing upstream, it forces your institution within three years to
either fork under a version solely contributed to by your organization, *or*
to fix the hard-coding problems and release the plugin.
If the project gets no traction of other contributors, then you don't have to
do anything anyway since you'd still be the only copyright holder.
There is a devil in these details though: you still have to define what a
plugin is and what you're allowed to keep proprietary.
-- bkuhn
More information about the License-discuss
mailing list