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 _______________________________________________ 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 [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
