Page MenuHomePhabricator

Re-license Codex under MIT or some other more permissive open-source license
Open, Needs TriagePublic

Description

Currently Codex is licensed under the GPL v2.0 software license (inherited from its predecessor WVUI, which in turn used the same license as MediaWiki itself).
However, in a recent discussion on Wikitech-l some users have expressed concerns that this license is too restrictive to be able to use Codex in their projects, and that the MIT license (which is used by OOUI, the library that Codex is more or less the successor to) would be a better fit for this project.

I don't think anyone on the Design System Team is opposed to such a change, but let's use this task to discuss any potential ramifications before proceeding.

Any change to the license of Codex itself should also apply to Codex PHP.

Open questions

  • Codex better off with something else than GPL version 2?
    • We're currently setting Codex packages (exception codex-icons) GPL-2.0+ as in "GPL version 2.0 or any later version"
  • Dual license (GPL version 2 and MIT) versus re-licensing?
    • In re-license case we have to have all authors permissions to re-license existing code.

Event Timeline

What has happened here from my memory, is that the direct predecessor of CodexWVUI – has oriented itself on MediaWiki and its GPL v2 (not v3!). Codex then just followed in continuation without further discussion, as it took over a number of code fragments from WVUI.

See addition of GPL v2 in October 2020 https://gerrit.wikimedia.org/r/plugins/gitiles/wvui/+/d38936c639a64759dee80feb1fe43c13d8d30ff1

We only had a quick discussion internally in October 2021 (in reference to WiKit licensed under BSD-3-Clause):

Roan Kattouw Oct 1st, 2021 at 11:57 AM
WVUI is licensed as GPL v2 or later (same license as MediaWiki), and thankfully the 3-clause BSD license is compatible with GPL v2. So it's OK to take code from a project licensed under 3-clause BSD and copy it into a project licensed under GPL v2, which is what we would be doing here (assuming the new component library is GPL v2 or later, which is what I would suggest)

11:57
Sources: https://www.gnu.org/licenses/license-list.html#ModifiedBSD and https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

Volker E. Oct 1st, 2021 at 11:59 AM
For completion, OOUI has been licensed under MIT, something I was surprised about as well without ever digging deep (actually having the time to). I'd be for GPL as well, why v2 and not v3? (edited)

Roan Kattouw Oct 1st, 2021 at 12:03 PM
MW core and most extensions and other related software I know of is v2 or later, so that's why I suggested that. I'd be OK with v3 or later too, but I don't know what effect that would have on our ability to move code back and forth between the library and other GPL v2 or later repos. That's a question I defer to Legal on

Also note also, that for historic reasons (inheriting from OOUI) our icons (package) is MIT licensed, the icons itself CC BY 4.0.

All others, root and packages codex, codex-design-tokens and codex-docs, currently state GPL-2.0+.

some users have expressed concerns

Two community members have expressed concerns about wanting a permissive license so they can use Codex in their own projects or in permissively licensed extensions as of 2025-01-06. A one of these community members has also expressed IANAL concerns about mixing CC BY-SA and GPL-2.0-or-later licenses in on-wiki maintained code (userscripts and gadgets).

As a counter point, in T360718: Relicense Wikibugs from MIT to GPL-3.0-or-later after approval by all substantive contributors I was able to relicense Wikibugs from MIT to GPL-3.0-or-later. My personal interest there was reducing the ability of projects that have adopted licenses not approved by the OSI such as the Server Side Public License (SSPL) to benefit from the work of the Wikimedia movement without reciprocal contributions. Fairly obviously the pile of code we use to produce IRC notifications from Gerrit events is not of wide interest in the open-core world, but by using licenses like the GPL and CC BY-SA which require modifications and enhancements to be shared in the same spirit as the original work I feel that we as a movement can help increase the total amount of code available for common use.

As one of the principal deciders behind why so much of our library-like FE code is MIT, including VE/OOjs/OOUI/etc., I was a bit surprised when WVUI decided to depart from what I thought was the otherwise-agreed standard.

So WVUI was originally licensed as GPL-2.0, and Codex inherited that along with some of the initial code (TypeaheadSearch comes to mind, but I think some of the Button code was also carried over for example). Since then this project has been de-commissioned (the repo is empty, it's no longer mirrored on Github, etc).

The Wikimedia Foundation is the author of both Codex and WVUI, so I think that we could re-license Codex as MIT if we desired to do so. This should be confirmed by someone in the Legal department though.

I think that there are places where GPL licenses are more appropriate, but in the case of a stand-alone library like Codex (where we actively want adoption and contribution), I believe we are better served by MIT. Especially if this is already used in other similar projects that we maintain.

Another option, as stated in the wikitech-l thread, were to dual-license Codex – as in adding MIT license.
IANAL, but from my understanding we would have to get written author permissions to re-license for using all parts of contributors until this moment. It could be a bit less disruptive to add MIT license and avoid legal or community complexities associated with re-licensing. New users or projects can opt for the permissive MIT license.

Volker_E updated the task description. (Show Details)

Given that its meant to be a replacement for OOUI, i think it makes the most sense to just keep the same license as OOUI if it is viable. That way people who want to switch from OOUI don't have to think if their usage complies with the new license.

IANAL, but from my understanding we would have to get written author permissions to re-license for using all parts of contributors until this moment. It could be a bit less disruptive to add MIT license and avoid legal or community complexities associated with re-licensing. New users or projects can opt for the permissive MIT license.

I don't think that makes sense. MIT is compatible with GPL. There is no effective difference between licensing it only MIT versus MIT+GPL. You would need all previous contributors permission either way. Perhaps you are thinking of the other direction. You don't need permission to go MIT -> GPL. You do need to permission to go in the GPL -> MIT direction.

Unless you're suggesting that part of the code be licensed GPL and part of it being MIT, which is just really confusing.

Another option, as stated in the wikitech-l thread, were to dual-license Codex – as in adding MIT license.
IANAL, but from my understanding we would have to get written author permissions to re-license for using all parts of contributors until this moment. It could be a bit less disruptive to add MIT license and avoid legal or community complexities associated with re-licensing. New users or projects can opt for the permissive MIT license.

A more permissive license cannot just be arbitrarily added. If that were possible then anyone who wanted a more permissively licensed library could just fork the upstream and add the license of their choosing. In order to relicense from GPL all current license holders must agree to the change. Because the Wikimedia projects do not use a Contributor License Agreement (CLA) that assigns all rights to the project this means that all contributors must be contacted for approval. If the project incorporates code from an upstream project by copying the rights holders to the upstream content must also be contacted.

Another option, as stated in the wikitech-l thread, were to dual-license Codex – as in adding MIT license.
IANAL, but from my understanding we would have to get written author permissions to re-license for using all parts of contributors until this moment. It could be a bit less disruptive to add MIT license and avoid legal or community complexities associated with re-licensing. New users or projects can opt for the permissive MIT license.

A more permissive license cannot just be arbitrarily added. If that were possible then anyone who wanted a more permissively licensed library could just fork the upstream and add the license of their choosing. In order to relicense from GPL all current license holders must agree to the change. Because the Wikimedia projects do not use a Contributor License Agreement (CLA) that assigns all rights to the project this means that all contributors must be contacted for approval. If the project incorporates code from an upstream project by copying the rights holders to the upstream content must also be contacted.

That sounds correct to me. I assume we'd need to contact all the code contributors listed in https://github.com/wikimedia/design-codex/blob/main/AUTHORS.txt and ask them to agree to a change in license.

Another option, as stated in the wikitech-l thread, were to dual-license Codex – as in adding MIT license.
IANAL, but from my understanding we would have to get written author permissions to re-license for using all parts of contributors until this moment. It could be a bit less disruptive to add MIT license and avoid legal or community complexities associated with re-licensing. New users or projects can opt for the permissive MIT license.

A more permissive license cannot just be arbitrarily added. If that were possible then anyone who wanted a more permissively licensed library could just fork the upstream and add the license of their choosing. In order to relicense from GPL all current license holders must agree to the change. Because the Wikimedia projects do not use a Contributor License Agreement (CLA) that assigns all rights to the project this means that all contributors must be contacted for approval. If the project incorporates code from an upstream project by copying the rights holders to the upstream content must also be contacted.

That sounds correct to me. I assume we'd need to contact all the code contributors listed in https://github.com/wikimedia/design-codex/blob/main/AUTHORS.txt and ask them to agree to a change in license.

You probably only need to contact external contributors? WMF owns the employees' work product while they're on the clock, so just the foundation's consent should be sufficient for all internal contributors. That should narrow down the list by a lot.