If they were actual enhancements, I doubt the Zig Foundation would care. A company making a closed source release doesn't seem to be the point of ire here.
The issue is, another company has forked Zig, made 0, or negative enhancements, and the Zig foundation is making sure to distance itself from the fork incase anyone gets burned by Zen. You don't want the first impression of your new language to be tarnished by some commercial company who dumped everything in marketing and 0 in development.
The GPL wouldn't help in this case at all. It's very clear that the Zig Foundation doesn't care about the changes, it cares about it's reputation. On the contrary having a high quality commercial fork would probably be a good thing for Zig (see MySQL <-> Percona, Cassandra <-> Datastax, Postgres <-> Citus)
“Since then, “No. 2” has resigned from their position at connectFree, but won’t be able to contribute to the Zig project for some time because of a “non-compete” clause present in the contract.“
So why do you care if No. 2 is not able to work on Zig if you don’t value the contributions he’s made to Zen?
Maybe they believe that No. 2 is capable of making valuable contributions, but that the specific contributions made at the direction of the Zen founder aren’t valuable.
> 1. Why do you believe that No. 2 can make valuable contributions to Zig if you do not value his contributions to Zen?
Because the project does not care for Zen's desired direction and following this direction is the form No. 2's contributions to Zen would have taken as they were a contractor to Zen.
The contributions No. 2 would make to the Zig project as an individual and independent of Zen are… unrelated to the direction Zen wants.
> 2. Why do you believe that No. 2 would be a potential contributor to Zig if he weren’t otherwise legally restricted?
Because No. 2 is the number two contributor to Zig and is actively stopped from contributing by the NCC. That's literally in the statement.
If I'm not mistaken, if all code authors agree on the license change, then, the new release can be made fully GPL. While the old copy will be still available as MIT.
A malicious actor can pretend that they merged MIT parts with new GPL parts, but I think, it would not take a lot of time, until such merging would become technically hard, and the code can be effectively converted into GPL.
However, since Zen's guy was a contributor, it's probably not possible to get all authors' permission to change the license for the entire Zig codebase.
The issue is, another company has forked Zig, made 0, or negative enhancements, and the Zig foundation is making sure to distance itself from the fork incase anyone gets burned by Zen. You don't want the first impression of your new language to be tarnished by some commercial company who dumped everything in marketing and 0 in development.
The GPL wouldn't help in this case at all. It's very clear that the Zig Foundation doesn't care about the changes, it cares about it's reputation. On the contrary having a high quality commercial fork would probably be a good thing for Zig (see MySQL <-> Percona, Cassandra <-> Datastax, Postgres <-> Citus)