Elgg Licensing

TL;DR: How to accomodate Thematic Networks' SAAS setup with community-oriented free software development?

The context

Elgg core is released under a dual-license that provides compatibility with AGPLv3+ and GPLv3+ free-software-friendly development. But Elgg core plugins, such as groups, are released under an exclusive GPLv2 license that is incompatible with the above-mentioned licenses.

The problem

That situation leads to a conflict of interest between one of the copyright holders, Thematic Networks, that offers the "Software As A Service" proprietary platform Elgg.com, and the free software community willing to distribute freedom-friendly code under the (A)GPLv3+ licenses.


This discussion is to gather community feedback regarding potential solutions that accommodate all parties. Among the possibilities already mentioned in various issues on Github:

  1. change Elgg's license to GPLv2-or-later in the 2.0 release
  2. include core plugins into the MIT(X11) release
  3. rewrite core plugins and release them under (A)GPLv3


  • i am sure that many here are not fully aware of the differences with all these licenses.. i am not. so i have some questions here:

    does option 1 result in elgg's license becoming more restricted that it already is?

    what is 'the MIT(X11) release' in option 2?

    why not change the core plugins to be GPLv3? who is stopping that from occurring and why? wouldn't they change their position if they realised that the code was only going to be re-written anyway and probably improved and thus they would eventually come to be using the new versions regardless?!

  • The Licensing does not matter, elgg is opensource, i even don't know difference between GPL1,2, 3 lol but as far as i know it is opensource!

  • @Liang Please keep your comments constructive.

  • This is not a completely accurate description of the situation and puts Thematic in an unnecessarily bad light.

    Elgg is a framework that is used by many schools, governments, and businesses to provide social networking. Changing Elgg to a license that requires them to make sources available if they change Elgg introduces a number of complexities for them and makes Elgg less desirable. Thematic is important because they own a significant copyright in Elgg and would have to agree--along with all the other copyright holders--to any license changes.

    As I mentioned in the ticket that spawned this post, discussions about licensing are time consuming, premature, 100% philosophical, and are not beneficial to the project at this time. The process to change the license is complicated; the license cannot change right now. The earliest reasonable timeline for this would be Elgg 2.0.

  • I'm sorry I didn't intend to put anyone in a bad light. Feel free to edit the initial post.

    Changing Elgg to a license that requires them to make sources available if they change Elgg

    This is simply not true. Such a change would not require anyone to do anything. It would simply allow people who are willing to distribute Elgg-based code under a more freedom-friendly license to do so. People would still be able to use the GPLv2 if they want to. If that is the main argument against the license change, we're set.

    @tunis No, option 1 is not about restrictions, quite the opposite. It would lift restrictions on freedom-friendly collectives to distribute code based on Elgg. Nobody would be restricted in any way.

    If you're so inclined, you can learn more about free licenses and open-source by reading this long essay by Evgeny Morosov, or that shorter one by Richard Stallman. In any case, please don't comment them in this discussion, to keep it on topic. Instead, you're welcome to send me email at gnu dot org.

  • oh, i see the MIT license is currently used with elgg - minus the plugins; plus a GPL2 version is the 'normal' one (according to the elgg downloads page).

    i didn't comprehend option 1, since elgg is already listed as offered with a GPL2 license - so i don't see how to "change Elgg's license to GPLv2-or-later in the 2.0 release"

  • Interesting topic about licensing. It has been a long time since I release a new plugin. Anyways, so under GPLv3 you have to share the changes with the public?

  • It's not the GPLv3 license that would require you to share code modifications. Neither the GPLv2 nor the GPLv3 license require you to share your modifications if you only "use" the code. In case of web applications like Elgg or Elgg plugins "use" would for example mean you would have created a social network other people can visit. Only if you "distribute" your code (like offering your plugins here on the community site, offering - even sell - them somewhere else) you would have to publish your code (any original code plus any modified code) as source code to follow the terms of the GPL license. In case of "distribution" you would also make the code available if you haven't changed it at all (that's what people have to follow who offer Linux distributions as an example).

    The difference is the AGPL license. With the AGPL licenses the definition of "distribution" is different. Already the use of software on a website that other people can visit is defined as distrubution. In this case you would have to provide a way for everyone to get the code - and it doesn't matter if you have changed the code or not. You have to offer a way for them to download the code in ANY case. I think this is something most people either don't know or ignore (and therefore violate the AGPL licenses) even if they speak about "more freedom" of the code. The "freedom" of the AGPL license depends on your point of view. It surely is no freedom without restrictions you have to follow to not violate the license.

    The constant urging to change the license of Elgg or Elgg plugins to GPLv3 has mainly one reason: for software released under GPLv2 the AGPL licenses are not considered as "compatible licenses". Therefore, you can't change the license from GPLv2 for example to AGPLv2 without the permission of the original copyright holder. With GPLv3 this is different as AGPLv3 is considered as a "compatible license" and therefore anyone can change the license from GPLv3 to AGPLv3 without the permission of the original copyright holder.

    My opinion is: the AGPL licenses do not have more "freedom" in any way that I see an advantage in. On the contrary I even see the requirements of the AGPL licenses to provide access to the source code in any case (even if not modified) an unnecessary burden for the users: on a non-IT website I doubt very much the visitors are much interested to be offered to download the software that runs the site. And even if the site uses GPL software the site admin would still be free to offer links nonetheless while he MUST on a site that uses AGPL software (and results most likely only in many people violating the license by not offering the source code).

  • @iionly Thanks for explaining it in detail. You answered several questions I had in mind.


  • My opinion is that all our templates, JavaScript, and CSS should be MIT because you're "distributing" that code to the users' browsers. I would not want to force folks to also provide the source code in this case since doing so is just a hassle.

    But that said, I agree with Brett here. The benefit of going through all the hurdles to change the licenses is just not worth it for the merely philosophical gain.

    I've started rewriting the Elgg frontend from scratch in Angular as I believe the user and developer experience benefits to be worth it. The code is MIT licensed, so this issue is not present.


Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.