[License-discuss] Discussion: AGPL and Open Source Definition conflict
Florian Weimer
fw at deneb.enyo.de
Tue Sep 24 10:33:18 UTC 2019
* 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.
More information about the License-discuss
mailing list