I think the (hard)fork is legal under the MIT license, but IANAL, so I'm not sure they dotted all their i and crossed all their t. The possibility to fork and change the license is a standard point in the old discussion of GPL vs MIT.
I feel part of that post is unnecessary, like:
> We cannot see a future for Zig where the founder does not allow corporate entities to use and support Zig, so in respecting Mr. Kelley's ideals, we felt forced to fork Zig.
I also don't like that they use their own license "ConnectFree Reference Source License (CF-RSL)". (I can't find a copy of it.) If the idea is to make a corporate friendly fork, why not stick to a standard license? Corporate lawyers hate weird licenses because they have to read them and be sure there are not weird hidden clauses there. To make a corporate friendly fork, I suggest MIT.
The linux tarball comes with the CF-RSL, an EULA and and an ACKNOWLEDGMENTS.md file that contains 3 licenses and copyrights, including the zig original.
It does, with really minimal conditions (keep the license text and copyrights intact).
I do not understand what the problem is. Zen seems to be a hard fork that uses the zig code and sub-licenses it. That may be unfortunate, but it seems perfectly legal.
I think the expectation was the part of the MIT license which says:
> keep the license text and copyrights intact
It sounds like the Zen project removed/moved license text itself. Is it ok to fork a project and rename a LICENSE file to ACKNOWLEDGMENTS and then add your own LICENSE file? Or does the MIT imply that you must retain the original license text in the LICENSE file?
IANAL so I have no clue as to the legality of that aspect in particular, but it sure /seems/ a bit unsavory, even if it may be legally ok.
The text of the MIT licence specifies that:
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
So, yes they can rename and move the license file. The ACKNOWLEDGEMENTS.md file includes all other licenses for code.
I took a look. IANAL, however it is clear that they lift library sources and substitute their own LICENSE file to claim a copyright with different license terms. Just because the Zig sources don't carry a copyright notice does not mean they are not subject to copyright, so the least they could do is provide the original LICENSE file from Zig and make clear what their own contributions are and what license applies to them.
On the Zig side it would be better to include copyright notices with the files and maybe consider relicensing to GPL to avoid these situtations in the first place. Unfortunately many authors today are choosing non-copy left licences which might go against their intentions and probably their interests as well as software creators.
Yeah, the MIT license is small/short enough that it is probably best practice to just slap it onto the top of every file. A single file LICENSE is instructive, but shouldn't be the only place you put a license, or it is apt to be fiddled around with and/or make it unclear which parts of the source are under which license, should the project be incorporated into something downstream.
A copyright notice could be a single line in a source file, just mentioning the authors and the license that applies.
It gets a bit complicated when you have many authors all contributing to a github repo. Some projects require the authors to sign off so that the copyright is assigned to a single entity, that makes relicensing easy. With an open source project like Zig it might be complicated to relicense since you have many contributors.
It seems that Zig should maintain a contributors file since they have chosen the joint copyright model with the MIT license. They could then refer to that in a copyright notice, which could be a single line per file.
On the Zen side however there seems to be a gross misunderstanding of copyright. Just because you make some changes to a source file (or no changes at all) does not allow you to completely reasign the copyright to yourself.
15 comments
[ 4.7 ms ] story [ 52.2 ms ] threadhttps://zen-lang.org/zig/
I feel part of that post is unnecessary, like:
> We cannot see a future for Zig where the founder does not allow corporate entities to use and support Zig, so in respecting Mr. Kelley's ideals, we felt forced to fork Zig.
I also don't like that they use their own license "ConnectFree Reference Source License (CF-RSL)". (I can't find a copy of it.) If the idea is to make a corporate friendly fork, why not stick to a standard license? Corporate lawyers hate weird licenses because they have to read them and be sure there are not weird hidden clauses there. To make a corporate friendly fork, I suggest MIT.
Um.... What? I was under the impression MIT allows me to do what ever I want.
Not only is it legal, normal, and also morally correct.
I just cant see the problem.
> keep the license text and copyrights intact
It sounds like the Zen project removed/moved license text itself. Is it ok to fork a project and rename a LICENSE file to ACKNOWLEDGMENTS and then add your own LICENSE file? Or does the MIT imply that you must retain the original license text in the LICENSE file?
IANAL so I have no clue as to the legality of that aspect in particular, but it sure /seems/ a bit unsavory, even if it may be legally ok.
It sounds like the Zig author wanted to use something like the GPL and chose the wrong license.
On the Zig side it would be better to include copyright notices with the files and maybe consider relicensing to GPL to avoid these situtations in the first place. Unfortunately many authors today are choosing non-copy left licences which might go against their intentions and probably their interests as well as software creators.
It gets a bit complicated when you have many authors all contributing to a github repo. Some projects require the authors to sign off so that the copyright is assigned to a single entity, that makes relicensing easy. With an open source project like Zig it might be complicated to relicense since you have many contributors.
It seems that Zig should maintain a contributors file since they have chosen the joint copyright model with the MIT license. They could then refer to that in a copyright notice, which could be a single line per file.
On the Zen side however there seems to be a gross misunderstanding of copyright. Just because you make some changes to a source file (or no changes at all) does not allow you to completely reasign the copyright to yourself.