* Howard Chu: > Clause #10 of the definition https://opensource.org/docs/osd > > 10. License Must Be Technology-Neutral > > No provision of the license may be predicated on any individual > technology or style of interface. > > I note that the Affero GPL > https://www.gnu.org/licenses/agpl-3.0.en.html clause #13 > > 13. Remote Network Interaction; Use with the GNU General Public License.
I think this is usually a consequence of applying the AGPL to works without a built-in compliance mechanism (such as database libraries). I believe the AGPL, as it was intended originally, would apply to web applications which were deployed as source code (e.g., PHP scripts). Then the web server would be able to serve the source code of the application just by changing the URL from ending in ”.php” to “.phps”, giving a built-in source code distribution mechanism that automatically provides compliance even in case of local modifications. Of course, this is no longer how many PHP applications are deployed today, and it clearly will not work for compiled code which is linked deeply into some networked application, especially if the compiled code licensed under the AGPL does not implement any relevant network interaction of its own. My impression is that AGPL has gained a reputation of a GPL version that enables “open core” business models, and this is why most people choose it. The FUD it creates for non-networked AGPL code appears to be a welcome side effect, one that can be remedied with support/service contracts or separate licensing deals. If my theory is right, high-profile AGPL projects would use asymmetric contributor license agreements, where the license “in” is different from the license ”out”, and the original developer retains the ability to relicense the code under something else than the AGPL at any time. _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
