As a Japanese-speaking software engineer, I found that the company, connectFree, did too many suspicious acts as below:
- They are attempting to register "ZIG" [1] and "SiFive" [2] as trademarks in Japan. Only this is enough for me to see them as a trademark troll.
- Since Zen is a fork, Zen comes with Zig's (or its derived version of) standard library, but when they copied Zig's library source files, they removed the original copyright notice from each file header and replaced with "Copyright (c) 2018-2020 kristopher tate & connectFree Corporation." Sure, because it's MIT license, you can relicense, but is replacing the original copyright notice OK? Even if it's OK, why did they do that?
- I once attended a meetup where the CEO of connectFree, Kristopher, gave a presentation about Zen. He gave many reasons to use Zen, but most of them were Zig's features. Until someone pointed out in the meeting, Kristopher didn't mention or even imply that Zen is a fork of Zig. Many of my friends didn't actually know until this statement was made that Zen is a fork of Zig.
- connectFree recently published license terms for Zen (perhaps only in Japanese), and in the license they claimed that you are required to obtain a paid license to distribute a program even in the source code form as long as the program is written in Zen. I can't believe that you are able to force it, and it looks like Kristopher retracted the license later, but at least they tried to do that once. And you still need to buy a license to distribute a program in binary form if it's written in Zen and compiled with connectFree's Zen compiler.
> The above copyright notice and this permission notice shall be included in all copies or portions of the Software.
If they aren't complying with that, then they're in violation of the MIT license. Further, by removing Andrew's copyright and claiming his work as their own, that runs afoul of copyright law independent of any software licensing considerations (e.g. the reason we're told to use an actual permissive license instead of declaring things "public ___domain"; things don't work that way in all jurisdictions).
If that is the case, legal action is warranted.
Edit: nanny's response is correct; compliance with MIT is a very low bar that seems to be satisfied. I still question the legality of their copyright claims.
They are complying, the original Zig license is at the bottom of the file lib/zen/std/LICENSE (complete with "Copyright (c) 2019 Andrew Kelley"). I just downloaded it from the Zen website, and the tarball is dated 2020-09-04.
Yes, because, as I explained above, they still retained the original Zig copyright in their LICENSE file. The MIT/Expat license doesn't say anything about the file headers. It only requires that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
Does a single notice in the lib/zen/std/LICENSE file satisfy the requirement "shall be included in all copies or substantial portions". If many (source) files are copied and if each file contains the copyright notice, then the copyright statement "shall be included in all copies" (or substantial portions) of these files - and not just in one file...
>Does a single notice in the lib/zen/std/LICENSE file satisfy the requirement "shall be included in all copies or substantial portions".
Yep. The single files (or substantial portions of them) are not what's being distributed in this case. The Software is the thing being distributed, and it meets the requirements as described in the license (that the original copyright and permission notice be included). Therefore, it is in compliance.
If there is individual notice on the file because the file is a work individually licensed under MIT, removing it from the file is removing it from an MIT protected work in violation of the license.
That the individually-protected work is also included in an compilation which is itself licensed under MIT does not remove or loosen any licensing requirements on the smaller work.
>If there is individual notice on the file because the file is a work individually licensed under MIT, removing it from the file is removing it from an MIT protected work in violation of the license.
Why is that in violation of the license? The only condition specified in the MIT/Expat license is this:
>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Each file is not "the Software". "The Software" means the Zig/Zen projects as a whole. The "above copyright notice and this permission notice" is included in the copy of Zen. Therefore, it is in compliance.
I wrote in another comment:
>In addition, the Zen headers say "This project may be licensed under the terms of the ConnectFree Reference Source License" and "See the LICENSE file at the root of this project for complete information". This statement is enough to imply that the project as a whole is covered by the specified LICENSE file.
Can you give any support for this which is not your own "I say so because that's how I understand what I have read"?
That is, can you give a link of some court case where your claim was confirmed, or a link to a project where some big company changed the copyright lines in some library source files, when these lines were previously MIT licensed?
If not, repeating your own claims in many posts here doesn't make your claims more believable.
I still understand that every source file (as in, having the lines that produce executable code) containing a copyright is a "software" where the copyright lines have to be preserved as soon as the author initially wrote the lines, and I need some independent evidence, as stated before, to be convinced otherwise.
I don't know of any court cases or other precedent, no. I am working with the definitions of "software" and "program" as I am familiar with them being used in various software licenses. But that doesn't really matter because the only assumptions I'm basing this argument on are contained in the MIT/Expat and what connectFree has done with Zen.
For the sake of the argument, let's grant you the premise that each file is its own "software" (as the word is used in the MIT/Expat). The only requirement of the license is this: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." So even if connectFree removed all the copyright notices in the source code files, they still meet that condition because the original Zig license is included in their modified copy of Zig. It doesn't matter what the definition of "software" is here, because they meet the conditions regardless of what that definition is.
Wrong. If every source file is "software" the copyright should not be removed from the source file.
There are even international laws about copyrights, and removing the original copyright is simply a violation even on the international level -- the original author has to remain an author. It is he who initially copyrighted the files. Your "working as you are familiar" doesn't mean a thing.
So how do you tell the difference between the files having been licensed individually or only the whole compilation having been licensed?
Here is some of the license text:
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software") [...]
That seems to me to indicate that it applies to the whole software package and not any single file (unless you could call that single file a "software" in its own right, maybe?)
Meanwhile, the text in each individual file only says this:
> So how do you tell the difference between the files having been licensed individually or only the whole compilation having been licensed?
One way you could check is if each of the files has their own copyright and license notice, and the license notice includes, directly or by reference, terms which require preservation of the accompanying copyright notice.
How can you be sure the license notice wasn't meant to apply to the project as a whole, as I imagine is overwhelmingly the more common intention? That is the obvious question here.
They are distributing a modified copy of the software and including the original copyright and permission notice. Therefore, they are in compliance. It's as simple as that.
If they were distributing the individual files (or "substantial portions" of them) without a copy of the original copyright and permission notice, then you'd be correct. But that's not the case here.
Because each source file on its own is a work subject to copyright, with a copyright notice and particular license attached, and the license attached requires retaining the notice.
The fact that they are also included in a compilation which, as a compilation, is separately subject to copyright and has it's own copyright notice and license attached, which happens to be the same license, doesn't change that one bit.
I don't agree that each file on its own is a separate work subject to copyright. Even the original Zig headers say that each file "is part of zig" (emphasis mine). The "work" in this case is the software project as a whole. That's what's being distributed.
In addition, the Zen headers say "This project may be licensed under the terms of the ConnectFree Reference Source License" and "See the LICENSE file at the root of this project for complete information". This statement is enough to imply that the project as a whole is covered by the specified LICENSE file.
> I don't agree that each file on its own is a separate work subject to copyright.
Each is an individual work of authorship meeting the requirements for protection under copyright law and as such is automatically protected on creation as an individual work. Each is distributed with an individual copyright notice and individual statement of the license terms, so the recipient also has notice that the protection which is automatic under copyright law is claimed by the author, and the licensing terms applicable to the work. Redistribution without preservation of the copyright notice that appears in the work as required by the license is a clear, willful violation of the license.
IANAL, but to your point about the copyright notices: I suspect that the license may not require you to retain the notices, but that doesn't mean that you can "take" the copyright. Copyright is associated with authorship and can't be taken by mere declaration. I could publish a copy of Shakespeare's works on my website, and I could put "(c) My Name 2020" at the top, but that would not confer actual copyright ownership of the work on me. It would simply be an incorrect assertion.
IANAL, but I believe you cannot put "(c) Your Name 2020" on Shakespeare's works
in Japan and other countries. Their copyright acts protect the moral rights of authors[1][2]. So I think Zen's file headers would be violating the law in Japan and other countries.
You have it backwards. The MIT/Expat does required you to retain a copyright notice (in the form of a copy of the license, not in the form of file headers), which Zen does. In addition, creating a derivative work does in fact give you copyright on the new work. The Shakespeare comparison does not apply because Shakespeare is not licensed under the MIT/Expat license.
> MIT/Expat does required you to retain a copyright notice (in the form of a copy of the license, not in the form of file headers)
OK, but I was talking about the file headers. :)
> In addition, creating a derivative work does in fact give you copyright on the new work
Sure, but the new work is the portions that you've changed, not the portions that you've copied, right?
"The derivative work cannot be an uncreative variation on the pre-existing work or it would simply be a copy of the pre-existing work . . . " from here: https://bit.ly/3c21Yul
Gotcha, then you are correct. The MIT/Expat only requires: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software". As long as they are in compliance on that regard then they are in the clear.
>Sure, but the new work is the portions that you've changed, not the portions that you've copied, right?
No, the new work is the piece of software work as a whole, not the individual files. "Work" in this context is a legal term that includes all of the source code and nonliteral elements of the software, aka the Structure, Sequence, and Organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...
R.e. your second statement, I can only presume that you're right, but I'm confused about how this works with copyright license agreements, or the cases where projects have had to go and get copyright releases from authors of individual lines of code to make a license change. If the copyright is on the entire work, how can a contributor of just one line of code own the copyright? Anyway. You seem more versed in this than I am, so I bow to your expertise.
In that case, there would be multiple authors of a single copyrighted work. I'm only familiar/knowledgeable with GNU copyright assignment, however, not copyrights in general. https://www.gnu.org/licenses/why-assign.en.html
It doesn't need to say anything about file headers. A source file is a copyrightable work. The copyright notice and license file in that source file provide the copyright notice for that work and it's licensing terms. The MIT license, under which the work is licensed, requires the copyright notice of the work to be preserved. By removing and replacing the notice on the work, and distributing it without preserving the original notice as required by the license on the work, the license is violated.
The fact that the work is also included in a compilation, which is a separate copyright protected work, and that work has its own copyright notice and is offered under the same license, does not somehow alter the license requirements on the component work within the compilation, so that of the compilation’s copyright is preserved as required by the license of the compilation, there is no obligation to preserve the copyright notice of the component work as required by the license on the component.
>Sure, because it's MIT license, you can relicense, but is replacing the original copyright notice OK? Even if it's OK, why did they do that?
The file headers don't matter to the MIT/Expat license, what matters is that the original copy of the license is included in the redistribution, which it is (it's at the bottom of lib/zen/std/LICENSE). Replacing the file headers makes sense in this context because the derivative work is now (correctly) copyrighted by connectFree. Zen looks to be in total compliance with the original Zig MIT/Expat licensing terms.
Just know what you're getting into. Choosing the MIT/Expat license for your project is a conscious decision that explicitly allows people to do things like connectFree did with Zen. Whether you consider that a good or bad thing is on you. Although, I do highly recommend GPLv3, AGPL, or LGPL. You can read more about all kinds of software licenses here: https://www.gnu.org/licenses/licenses.html
As for the Apache, I don't know anything about that and I can't find anything about headers in the Apache v2.
This is the whole issue. It's all so complicated. Thinking about it, I suppose it should have been obvious they can just yank comments from an altered source. Somehow I had the wrong idea that original top-level headers were left untouched. IIRC I may have even seen appended top-level lic notices in the wild. Thanks to your informative comments here, I now know otherwise. The thought occurs that OSS licenses are very much mired in du jour technology of writing code. If a future language supports metadata for code, such as history, I would think none (?) of the current batch of OSS licenses would protect the metadata.
I've been warming up to GPL flavors for a while as well now. I'm even careless enough (I seem to suffer from a tendency to "wrong think") to toss around in my head a re-evaluation of merits of non-OSS licenses as worker in this field. An unfortunate thought that keeps cropping up is that "big business and big brother the ultimate benefitiaries of OSS".
The SSO of a piece of software is called a "nonliteral element". Just speculation on my part here, but I'd bet that version history might fall under this "nonliteral element" part of copyright law.
Let's say the MIT license demanded that you retain the copyright notice in all source files in addition to just the license file.
What benefits would that give you over the current situation? Anyone who makes a copy already has to include the license text, why does it matter where they include it as long as it's in a conspicuous place?
The real decision point here should be: Do you want people to be able to use your work for commercial purposes, for free, without recontributing their changes? If not, then don't use the MIT license
Just now I remembered that back in my squandered youth I used to consider code to be a form of creative expression. Code is not my only creative outlet, but it remains an important one. I should not be using OSS at all. I don't even code for the user if I am ever honest about it: I code for the thing itself. Somehow, it seems, I got caught in a dominant paradigm and lost a sense of my own self and values regarding my creative work.
As somebody that just got into Zig and loves the language, it makes me super sad that the developers on this project have to spend their valuable time stressing about BS like this.
Also, the ideas the Zen people list on their website for forking Zig are terrible ideas- They were pushing to turn Zig into a hard-to-reason-about vanilla object-oriented programming language.
That's one of the costs of using the MIT and BSD licenses: anybody can take it and go private/for-profit with it (without giving back even a "thanks"), and all the author can do is issue a strongly worded statement about it.
Moreover, they can't even claim the moral high ground when writing the strongly worded statement, since they've made the explicit choice to give up any and all rights to the product.
> Moreover, they can't even claim the moral high ground when writing the strongly worded statement, since they've made the explicit choice to give up any and all rights to the product.
You are oversimplifying things here. One can be a bad actor while remaining perfectly legal.
Your friend has an upcoming surprise birthday party. You didn't enter in to an agreement not to tell them, so you do. Your friend group doesn't sue you in a court of law, they shun you.
It's totally OK to decide that you want your project to be MIT, and call out hostile forks operating in bad faith. You're not going to stop them, but the community can judge for themselves whether you've got a point and which fork they want to associate with.
It's OK to say: well if you made the project GPL, they couldn't do what they're doing legally.
It's not OK to say: well you didn't make your project GPL, so you don't get to complain.
I agree, however it is worth noting that I don't think many maintainers consider the explicit value of copyleft these days.
I think BSD/MIT is more popular because it is simple and "less hassle", which is true but also makes it so that it is less of a hassle to be actively hostile to the project.
> One can be a bad actor while remaining perfectly legal.
Yep, that's exactly it. Obeying the letter of the law is not the same as following the spirit of the law. Ethicality and legality are not the same thing.
If they were the same, Zig would deserve scorn and vitriol for daring to question the character of another legal entity. After all, legal entities cannot be criticized for poor ethics because only illegal entities are unethical... right?
It's a twisted, craven worldview that we ought to be more wary of.
> It's not OK to say: well you didn't make your project GPL, so you don't get to complain.
I kind of agree with you and kind of disagree with you. You should be able to complain all you want. However, if explictly decide to give people certain rights when you complain about them using those rights it shouldn't hold much value. Which is what I think was the original point in the sentence you replied to.
Well if you complain about a "hostile fork" that's just somebody stripping your branding and releasing a commercial fork, that should fall on deaf ears. That's in the spirit of MIT, and you've just picked your license poorly.
But what's being alleged here is actual hostility and deception. If it's true, Zig being MIT licensed in no way removes their "moral high ground" (as GP put it) to make a post like this.
Here's my point of view - why does Zig even care what Zen is doing? Zen's shortcomings don't impact the userbase or development of Zig in any real fashion.
The fact that the Zig foundation wrote this letter condemning the actions of Zen's founder/employees - especially when they closed the letter with a call to action to return to Zig - shows that Zen's fork actually matters to them, that they don't believe it should remain functional.
Except essentially none of the statement takes issue with the forking itself.
In fact the author of the statement is active in this very thread and specifically notes that this is very much allowed and is not what they take issue with.
Other than encouraging Japanese users to use Zig instead of Zen, that is.
The fact that most of the message was pointing out how poor the character of the Zen authors is doesn't feel good to me, no matter whether the allegations are true or not. It's an appeal to our sense of fairness, "Look at these big bad guys who are profiting off our work".
And yet it's really the only argument that could be made by the Zig author.
> Other than encouraging Japanese users to use Zig instead of Zen, that is.
They're not encouraging users to use zig instead of zen because zen is a private fork, they're discouraging users from using zen because it is zen.
> The fact that most of the message was pointing out how poor the character of the Zen authors is doesn't feel good to me
Most of the statement has to do with Zen's dubious relationship with the truth (with the lack of significant value despite lofty claims being but one of the examples thereof).
The statement also doesn't point out the poor character of Zen's creator but their poor behaviour. You can infer poor character from poor behaviour but that is not what is pointed out in the statement.
> It's an appeal to our sense of fairness, "Look at these big bad guys who are profiting off our work".
You may want to re-read the statement if that's what you got from it.
> they're discouraging users from using zen because it is zen.
And I quote: "we invite all Japanese developers ... to join the global Zig community and enjoy the real deal, without having to pay a single Yen for the privilege."
> doesn't point out the poor character of Zen's creator but their poor behaviour
Potato, tomato. You're correct that the specifics are different, yet the underlying message is the same: "these guys are bad, come over to Zig".
It’s perfectly reasonable for an Open Source software foundation to point out how a private company is misusing their software and misappropriating their brand.
Saying that Zig’s creators should sit down and be quiet sounds both condescending and craven.
No, Zig's creators putting up a stink about a for-profit fork (a developer IP assignment clause, how.. actually quite common, come to think of it) sounds like they made a decision that they now regret, and so they'll use whatever tactics they can to pull people off the fork.
>a developer IP assignment clause, how.. actually quite common
It is absolutely not normal to demand copyright for code written by a developer in off-hours. It is extremely not normal to write non-compete clauses for software developers and the ban on non-compete clauses in California has been cited as a key policy promoting the growth of the software industry. And it is obviously adversarial to fork a project and then try to get developers on the project to sign non-competes saying they will not work on the project.
> It is absolutely not normal to demand copyright for code written by a developer in off-hours.
In the US, it's the standard. There are exceptions, but most companies will demand it. I've been bound by IP assignment contracts exactly like this for my entire career - from Oracle to a pair of startups.
> sign non-competes saying they will not work on the project.
Also, in the US, this is a long-established standard. You will not work for your competitors. Zig is a competitor for Zen.
It's fine for Zen to fork the Zig code. It's not fine for Zen to claim authorship of code that was written by someone else (such as the async/await code)
If he's being a dick about it (e.g. splitting the community, attempting to take credit, trying to register the trademark for a name it's not his, etc), then yes.
When I put the BSD license on something, I'm not condoning activity of hiring people away from working on the free version with non-competes that prevent them from contributing to the original. That's not in the scope of the license.
I think the situation could easily exist with a GPL-ed project. It seems possible to hire someone to extend the fork of some GPL-ed code base in specific ways, and use non-compete clauses to disallow any other activity with regard to that fork, or any other.
On paper, you might think that the GPL would hamper such at hing; after all, you have to release the source code. But in practice, things fall through the cracks. Someone with a fork of some GPLed code has certain customers. Those customers get access to the source code, but don't necessarily make it public. If you have key developers bound up with non-competes, and only they understand some code that only certain customers have, ... see the picture?
I feel so bad for Andrew. It must be frustrating to pour your heart into something beautiful like zig only to have this sort of thing happen. Now is a great time to sponsor the zig project on github!
How close to "production ready" do you feel Zig is, especially in terms of tooling and cross-platform support? It's a super interesting language for me, but I am hesitant to invest in a language which might not be truly usable for years if ever
Hi, right now Zig is still a bit wild. If you don't feel like looking into a language that is still moving at this speed (if you read the changelogs for the last few releases you'll see what I'm talking about), then you might want to wait a little.
Zig 0.7.0 is scheduled to be released soon and the main effort is being spent on porting the current C++ compiler to a self-hosted version. Once that's done, we'll be in a much better position to provide better stability for features.
During the last fundraiser we announced the intention of launching a Zig Stability Program once the self-hosted compiler is done, so that we can guarantee that any bug found in features that we decide to support are going to be prioritized appropriately. To be clear, this is a bug stability program, not an API stability one: we'll still redesign things from one version to the next if necessary.
In terms of timelines, we hope to have the self-hosted compiler replace the current one in version 0.8.0, indicatively 6 months from now.
You're ignoring or hand-waving the questions asked of you in this thread, in order to attempt to convert a sale, in a thread about the poor behavior of Zen. Ugh.
Maybe he shouldn’t have used the MIT licence if he didn’t understand what it meant. You can always hire a lawyer to explain it to you.
Excuse my cynicism but this story where someone starts a MIT or BSD licenced project so they can attract more contributors and then cry when someone makes money off the project is getting far too old.
The situation is a little more nuanced than that - it's the way they are trying to make money from Zig that people find objectionable. In particular, what they are doing could damage the future of Zig and potentially splits the ecosystem. In addition, they have done some obviously scummy things like try to register a trademark on Zig in Japan.
Probably the strangest part of this is a person trying to sell a paid version of a compiler. Did that person miss the boat by 30 years? All mainstream programming languages today are free and open source. Programming languages are platforms that thrive only when they're widely adopted. The community that adopts it builds the libraries and ecosystem necessary for it to be viable. You can't possibly build a new platform with a high barrier to entry if you're competing with established platforms where the barrier to entry is next to nothing.
Almost all of those you're forced to use because there's no/little competition that runs on the hardware, or it's an alternative compiler for a popular language (piggybacking on what OP described)
On top of that, you are only going to use those when you have to release on their platform using their tools and their publishing systems. You can just as easily run your own code, compiled by your own compiler. That said, some of those would be in a bit of a grey area considering that you would have to hack/jailbreak all of those consoles and handhelds etc.
Apple's Xcode is a free download, the Swift compiler is open source. However, to become an "official" developer on the Apple platforms and publish apps you do need a paid developer account.
And if you're doing ruby or nodejs or a handful of other languages, you can use the XCode CLI and most of your code (possibly all) will never see the App Store submission queue.
It makes sense for Apple though, because what the devs are really paying for is access to Apple's closed-source ecosystem, not the tooling itself. This company has no such market power; why would anyone want to pay for Zen, when it has no established ecosystem or audience?
They generally sell you an ecosystem though, and are often tied to specific hardware, not "just" a language.
The only examples that come to mind of a "pure" commercial compiler, not tied to a particular environment or piece of hardware are the Comeau C++ compiler (defunct for well over a decade) and arguably the original D compiler (although I don't know if it qualifies as proprietary, just not open source). Swift as well, although it was open sourced relatively quickly.
The D compiler is now completely open source. It was always source available, but Walter wrote the backend when he was at a different company and he was able to use it but because of copyright it couldn't be open sourced as per se.
Symantec signed off on it a few years ago, it's been Boost licensed ever since.
Apple's and Microsoft's compilers are downloadable for free (Apple's is actually Clang), they're not forcing you to pay if you want to use them; even the IDEs have been free for a while without any kind of payment or subscription.
That is not quite true in the case of Visual Studio. There is a community edition, but it is only free under a very constrained set of circumstances (mostly company revenue < 100.000$/year, IIRC). Most business need to buy Visual Studio Professional to legally use that IDE.
> Any individual developer can use Visual Studio Community to create their own free or paid apps.
No revenue cap to be found. Also:
> In non-enterprise organizations, up to five users can use Visual Studio Community.
Again - no revenue cap. And finally:
> enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue)
Now call be a naive buffoon, but in my book, >$1M annual revenue and/or >250 IT workplaces means that licensing costs for software are not a problem at all. This restriction also only applies to commercial use - academic, OSS, and classroom environments are still allowed.
I really don't see how this is constricting in any way.
I got the revenue limit wrong, but it doesn't change the fact that the Community edition isn't free for everybody. It has strings attached. That was my point.
It doesn't have strings attached that concern users - that was my point. It's also not just "getting the revenue limit wrong" if said limit doesn't even apply to individuals and small companies.
As soon as a commercial organisation enters 250+ IT workplaces and >$1M annual revenue, license management becomes relevant in any case and isn't exactly "strings attached"-territory. Feel free to disagree, but I still think your argument is pretty weak.
Surely the usefulness of what the compiler outputs is at least related to whether it's commercial or not.
If I forked GCC and made a version where the produced binaries would only run on the machine where the compiler ran, and removing that was a subscription...I'd call it a commercial product.
That's something of a technicality. If the output of the compiler isn't useful without paying for something else, it's effectively a commercial compiler.
Sometimes "whataboutism" is just a comparison to something more common that a broader audience can relate to.
Fwiw, I find the canned responses like "appeal to authority", "whataboutism", etc, kind of lazy. I'd prefer you tell me why I'm veering off in your own words.
"If you are not an enterprise (defined below), then up to 5 of your individual users can use visual studio community concurrently to develop and test your applications.
An “enterprise” is any organization and its affiliates who collectively have either (a) more than 250 PCs or users or (b) one million U.S. dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization."
Something which people don't always recognize about open source is how "value-capture" works for creators. FOSS eschews direct monetization (selling licenses to the core product) based on an ethical premise (it's unfairly limiting to end-users) and/or a business premise (the ecosystem is a key to the value prop and licenses would slow down the ecosystem growth).
None of that means that the creator isn't capturing value. You capture social credibility and market awareness which you can convert in a variety of ways, including monetarily (by selling complementary products/services, by donation models, or by getting a job that you might not have had the career-credentials to get otherwise). As an aside to elaborate on this point: a lot of the recent debate about paying FOSS maintainers has to do with projects which realized all the potential social value-capture, and left creators with an externality of maintenance.
Intuitively, I think people understand that forking and rebranding a project without a really strong motivation can be scummy, but I don't think people can verbalize why. This is why: you're attempting to steal the upside which the creator is the in the process of capturing.
And FWIW, anybody saying that a blogpost is weak action and you ought to be going to court is ignoring that, when the value you're capturing is reputation, then public discourse is the tool you want to be using to manage it.
I think that's a perfectly good point. The ZSF wants to build momentum and have the language take off. We also are looking for money in order to pay core contributors.
I can also share that my own role at the ZSF has as ultimate goal of increasing the total amount of effort spent on Zig.
The core problem with what kristate is doing is that, in a moment where the Zig community needs community members to take initiative and build things around Zig, and where likewise there's a tremendous potential for those individuals to capture a good chunk of value for themselves, all while making the pie bigger, he instead chose to cut a slice and run away with it for what amounts to pure vanity.
Right now we are trying to encourage people to start thinking about building a business around Zig, be it programming in Zig, or writing a Zig programming book, or whatever. I personally started https://zig.show before coming on board and I plan for my own, independent, Zig-related activity to become my main source of income one day.
If you add on top of that, that the guy creating this useless fork has a history of offering a free wifi service that steals personal information and rewrites amazon affiliate links, then you can see why we want to put as much distance as we can. For context: https://internet.watch.impress.co.jp/docs/news/496423.html
If being an asshole is something the Zig community does not want people to do with its code, why not just license Zig in such a way to prevent this type of usage of its code?
They already implement a code of conduct to restrict behavior in their community.
So in general yes, if you don’t have copyright assignment it is a lot of work to relicense. But that is not necessarily the case here... things like the MIT license (which ziglang uses) are often so permissive that you can relicense them as GPL.
With that said this sort of thing can result in mass contributor exoduses. One might prefer an in-between license like a per-file copyleft as you see in the Mozilla Public License, which is still GPL-compatible but does not put the full onus of the GPL on the software, solving this problem in a more narrow way (connectFree has to keep their proprietary software separate from ziglang when combining the two together, which forces them to be much more transparent about their value-add—things which they cannot keep separate need to be contributed back upstream).
Because then it wouldn't be open source. The open source definition prohibits developers from placing a lot of arbitrary license restrictions. One of the examples of this is that Gab, an alt-right site, now uses Mastodon, a platform written and used largely by a pretty far-left community.
We can get into semantics on what open source means, but I don't think the definition has to include a prohibition on any licenses. Open source just means the source code is freely available.
Except, we do have a rigorous definition on what Open Source really means. The best place to check is the OSI's definition[0] and the licenses they approve[1]. What you're describing is commonly described as Source Available and doesn't readily meet the definition of Open Source.
Our terms matter. And considering this conversation is really about what it means to be OSS and what the tradeoffs are, we need to "get into semantics on what open source means". Too many people co-opt the term and we need to defend it.
I reject the OSI's claim to have authority over what "open source" means. We do not have a rigorous definition of what open source means beyond the source code is freely available.
> I reject the OSI's claim to have authority over what "open source" means. We do not have a rigorous definition of what open source means beyond the source code is freely available.
I'm genuinely sympathetic, in that it rubs me a little bit the wrong way to say that one organization can define "open source". In practice, however, the only people I've ever seen actually arguing this are people trying to pretend that their license is open source when it really isn't.
That's fine if you reject the OSI's definition. We've been having this conversation as a community for decades and "the source code is freely available" is not enough.
For instance, there's Debian's[0] (which was considered authoritative enough that the OSI basically used it as their own) which spells out the freedoms necessary for software to be considered Open Source. This extends beyond the source being available to not discriminating against people groups, allowing for modification, etc.
There's another from the FSF/GNU projects[1] which lay out the Four Essential Freedoms. These extend beyond source availability to the ability to run the program as you wish, to study the program and to redistribute it (among others).
To say source availability == Open Source is to rewrite history. It's about user freedom and always has been.
Ok well here are the facts. Open means freely and widely available. Source means source code. Open source means the programs code is freely and widely available. If you want to add other stuff onto that you need to find a new phrase.
Grey is a color somewhere between white and black. Water is the liquid that we drink, wash our dishes and cars with, the stuff that sits in the world's oceans, &c. "Grey water", however, is not supposed to be applied to anything that contains fecal matter, whether or not you can argue that it is both grey and water. There are such things as specialization and context. They're pretty important to the way language works.
Grey water would be a nonsensical phrase if it didn't have another meaning. No one would think it's actually referring to water that is simply grey. Open source is a phrase that makes complete sense without any context.
Im not a lawyer but I’m fairly certain it’s possible for the Zig foundation to craft a license that reduces Zig’s anxiety w.r.t. malicious actors and that still satisfies DFSG. The GPL is an example.
I just want to say that I really admire and support what Zig is trying to do here. It takes guts to try to launch an ecosystem from a fun hobby to something that can be used in production and hopefully sustain its contributors. They're not there yet, but it looks like they may well be on that journey.
This thing looks very unpleasant, but hopefully it conveys the message that Zig is potentially valuable. Figuring out how to fund such a project and organize the community is a hard problem, and again I wish them well in finding a good path.
> This thing looks very unpleasant, but hopefully it conveys the message that Zig is potentially valuable.
This is a great point. One unfortunate mark of success is attracting bad actors, because it implies you have something with enough value to be worth exploiting.
Re branding a MIT license software and selling a commercial version is a good thing if done correctly. Clearly Zen is not providing any added value.
The key takeaway from this is you don't sign contracts with overly aggressive business executives. I also think Non-competes should be almost completely banned for most employees.
The key takeaway for me is that a third party is able to use thousands of manhours of someone else’s labor as a basis for their closed source product without having to share their enhancements or pay a dime.
If zig were licensed GPL, the zig foundation would be able to sell permissive licenses to companies that don’t want to share source as a way to fundraise.
As the author of the statement, I disagree. Parent poster got it right: the license is MIT precisely to allow the highest degree of freedom.
Companies that want to profit from Zig are welcome to do so, but in this particular case, we consider connectFree a bad actor and so we crossed the language barrier to make sure Japanese developers would be able to hear from both sides.
“We can’t in good conscience recommend to Japanese professionals and businesses to make their livelihood depend on a closed-source, superficial rebranding of Zig“
Does the zig foundation have a problem with recommending closed-source superficial rebrandings of Zig or just from connectFree?
Regardless of the legality of a thing, the foundation might of course recommend against using it. Imagine that someone wrote a shitty book (without stealing any content) which ends up as the only result on Amazon. It’s perfectly legal to release such a book and it would be sensible for the foundation to warn the Zig community about the lacking quality.
Just because the license allows anyone to fork it and sell it doesn’t mean that Zig is obliged to endorse it.
It’s fine for the foundation to recommend against certain companies, but it’s inconsistent to recommend against any specific company on the basis of it being “closed source superficial rebrand” if they claim to have no issue with people using their code on those terms.
then I submit that your rhetorical question at the end of your statement is flawed. Maybe consider the question: Does zig have a problem with closed-source rebrandings by companies that cause serious damage to the ecosystem outside of merely forking the code?
It was not flawed nor rhetorical, if their concern is with ecosystem damage, then the fact that the company makes a closed source superficial rebrand should have no bearing on that. Unless they indeed have a problem with companies profiting from Zig.
> a third party is able to use thousands of manhours of someone else’s labor as a basis for their closed source product without having to share their enhancements or pay a dime.
This is my favorite part about open source. Why are you painting it as a bad thing?
There's a difference between using open-source in your work and doing a superficial fork & rebrand. The latter is clearly trying to steal the upside from the creator of the code.
Of course there is a difference, but again that's what I love about open source. You put something out there, and then it has a life of its own. So what if some people come along and try to sell your code with a new name? Good luck to them, I hope they become very rich off my code (are there any examples of this actually happening?). Personally I write open source code because I like writing open source code, not to get rich.
I disagree. GPL/Commercial dual licensing is always a game of perverse incentives. Even if you aren't actively crippling the free part of your product you're incentivised to make it difficult enough to work with or otherwise support that companies will be inclined to pay you to do it.
Maybe, the idea is that a company who wants to use my work can either comply with the GPL and give back that way or financially support the project (and therefore not need to comply).
For those that believe in software freedoms as fewer restrictions, you have to accept that people may take advantage of your fewer restrictions. This is the cost of giving more (beer) freedom, and you don't have to abandon your principles because of how it manifests. (this has obvious political analogies in other restriction-less freedom contexts too)
> For those that believe in software freedoms as fewer restrictions, you have to accept that people may take advantage of your fewer restrictions.
This argument has never made sense. "The software is more free because you can impose restrictions on the way it's used." It's more of an attempt to rationalize than a concern about the freedom of the software.
To paraphrase Stallman on the topic of permissive Free Software licences:
Some people prefer permissive Free Software licences, and feel that copyleft licences like the GPL introduce unwelcome restrictions. I don't understand this objection. They're unhappy that the licence doesn't grant the power to deny other people their freedom?
The existence of this blog post suggests to me that they either don’t believe in total software freedom or they haven’t yet accepted that people will take advantage of it.
I read it a bit different, I read it as they're proud of their freedom stance, and they are just informing users about a hostile fork without even hinting at reducing their principals henceforth.
This is precisely my point. Why allow anyone to walk off the cliff if you’re just going to tell them it’s wrong anyway? They could have avoided all of this if it were GPL in the first place.
I do not mean this disrespectfully but isn’t that taking the idea of “personal freedom” to absurdity? I believe in personal freedom as well but I don’t think walking off a cliff or maliciously using someone Else’s labor is freedom.
Tools like EULAs end up being fairly coarse in practice.
Presumably the Zig authors prefer a world in which it is possible to maliciously use the tools under MIT, and non-malicous actors could do various things downstream that the GPL would be a barrier to, to the world in which the GPL prevents both of those things.
There is a cost to preventing harms, and people will disagree whether the cost is worth it. There are many evils in this world that I do not push for collective action to eliminate merely because I do not yet see a feasible solution that is worth the cost. That doesn't preclude me from individually speaking against those things, warning people about the pitfalls of them, and shaming those who do them.
I replied to the substance of your comment already, but I also wanted to say that it's a bit frustrating to me that you are downvoted without other replies.
While "freedom" is a fairly generic term (I can be free to kill you or not free to kill you), circumscribing "personal freedom" is reasonable in such situations. Many libertarians would agree that "personal freedom" is bounded by the "Harm principle" so any supposed right to shoot you without fear of reprisal would not be included in the term "personal freedom." Those same people would probably also argue that self-harm (and behavior that places one at risk of self-harm), are absolutely part of personal freedom.
Anarchists might say that "personal freedom" encompasses the right to harm others, and would argue that the repercussions would be natural; the damage to your reputation from harming others would deny you the assistance of others that could be necessary to succeed (or even survive) in the future, and it could also open you up to reprisal.
Some people argue that "personal freedom" includes all, or nearly all forms of free speech. In the US, it is generally agreed upon that defamation and incitement to riot are exceptions due to the harm principle. Many people take it further and say that allowing e.g. a KKK parade in a town should be excluded because it causes harm to the black community by fostering an environment of fear and mistrust, resulting in mental, emotional and financial harm.
I take no disrespect, and agree that a reasonable person could exclude harm to others as part of "personal freedom" I'm less convinced that harm to self isn't "personal freedom" as I think even most of those who support e.g. seatbelt laws would agree that they are a very small infringement on personal freedom in exchange for a very large public-health benefit and are knowingly making that tradeoff.
Taking the story at face value: Zen lied to customers and the community, hired a developer away from Zig, and that developer cannot work on Zig now due to an NDA.
GPL violations are not unknown. Would Zen have really cared about breaking the license? Would legal mechanisms work fast enough to limit damage?
>>All of that developers work on zen would be available to the zig foundation if it were licensed GPL.
>False. the changes and the license only need to be extended to Zen's customers. They don't need to be provided back to Zig.
Zen makes their system available for free download to the public, thus would be forced to provide source to the public. https://zen-lang.org/ja-JP/download/
Has anyone ever perused legal action based on a GPL violation? Last I checked, even the biggest piece of GPL software in existence, the Linux kernel, gets its violated without legal repercussions.
that's laughable. How much do you suppose it would cost to hire an international lawyer to pursue a case in a foreign country. Even if there were enough resources, do you think that the stakeholders in the Zig Foundation would consider that to be a reasonable use of the funds that they've donated?
I certainly wouldn't. As a donor, as far as I can tell, this is as good as they could do. I'm much happier that they spend their money on code, and leave it at a statement that can grab attention, like what they have done.
good lord. our budget is public; you can see we have some 30K in the bank, with $3500 income per month. We will not be wasting donors' money on a lawyer.
In this specific case it may not be worth it but if a large corporation were redistributing a hypothetically GPL-licensed version of zig without releasing source, then you would be doing your donors a disservice by not seeking retribution to the foundation.
The point of the blogpost isn't to shutdown Zen, it's to ensure new people who find Zig or Zen aren't confused into thinking there is a relationship between the two.
I have more faith in my fellow human beings that when they do due diligence to decide whether they should pay a monthly fee to use a language, that they would do a little due diligence and look into the history and syntax of the language and see that it's a fork of Zig instead of taking marketing at face value.
By that logic, If you have faith in the due diligence of your fellow man, why would a rational person assume there is a relationship between software forks with no claim to that effect?
>why would a rational person assume there is a relationship between software forks
Because many open source foundations bless commercial offerings. Having the open source foundation come out and say the commercial package is rubbish is the exception, not the norm.
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.
A language licensed as the GPL likely would not see any users, as programs built on it would link to it (or at least parts of it, such as the standard library); thus requiring either an exception clause, or that all software using the language also be licensed as GPL.
IIRC the AGPL is better for this, but most GPL licenses are just blacklisted by companies; reducing the likelihood of the language catching on.
I remember the hype about how it was going to kill off Flickr - we set up graphs of how many photos were being uploaded per day to each service and ... well.
I wonder why they decided to go with the MIT license rather than GPL or something similar. Choosing GPL would protect the project from situations like this, attract more contributors, and have no impact on commercial usage of the language itself.
MIT license allows it, so where's the problem. It's like people who support freedom of speech, and then cry anytime someone used it to say something they don't like.
Some of the wording there sounds petty. "whose founder uses flawed technical arguments" rubs me the wrong way. Like "The science on this is settled and everyone who ever disagreed should be personally discredited" kind of thing.
Having said that, I don't know why would anyone sane tie their codebase to a closed source language owned by some random company. I don't understand why Zig Foundation even bothers with this - seems like it is just giving publicity to something that has little to none chance of gaining market traction anyway.
> MIT license allows it, so where's the problem. It's like people who support freedom of speech, and then cry anytime someone used it to say something they don't like.
You can support freedom of speech and still publicly disagree with what people say. Freedom of speech says that people should not be silenced, not that they can't be disagreed with.
If we take the claims of zig at face value, then it seems quite a bit of their frustration is around the mistreatment of one of their valued contributors. That alone would seem like worth complaining about; and the rest of the stuff establishes a pattern of misbehaviour.
If all of this is true, I'm glad this gets attention in hn - so that the community as a whole can have insight into what happens sometimes in our subcommunities and know what to look out for.
That link is what the statement references as a sign of Mr. Tate's "flawed technical arguments". I'll admit I'm an outsider and a bit ignorant except for having read the linked issue, but it seems like Tate was reasonable and respectful, and that what seemed like an interesting technical discussion was shut down pre-maturely. Other contributors also said as much.
Again, I'm somewhat ignorant, but seems like some brash and stifling behaviour from a project seeking technical correctness. And then the commit linked above? Immature.
I'll be steering clear.
edit: to be clear, I'm not siding with Tate. Just commenting on the only negative behavior I see.
Massive Streisand effect here. The Zig project should just completely ignore this. There is no way this Zen thing is going to go anywhere. Nobody in their right mind would pay for anything of the sort in the year 2020.
Come on, "a licensing model for the Zen compiler that requires software developers to buy a yearly subscription to distribute compiled releases of their code". That has to be a joke?
All this drama reminds me of the business culture of Japan, building walls around their gardens, growing stuff with seeds from public parks while having unethical work policies for gardeners.
The entire problem of Japan is that they specialized in perfecting what others invent, which can only take you so far.
If companies want to fork Zig and distribute it commercially in such an early stage, then Zig is doing something right.
Please don't think this is standard on Japanese OSS scene. Zen's origin and owning company was not well known until now. Now it is thought as BS also on Japanese community.
I do admit that I find the "anti-business" citations pretty strange from the context of developing a programing language. I can understand this mindset if you're doing some work of art and don't want it corrupted by corporate drones, but for a technical tool I don't really get what could go wrong.
What would a corporate sponsor of a programing language want? A clear release schedule and roadmap, stability, practicality and efficiency. Those are all positive things IMO. Unless the original author wants to maintain Zig as an ultra-experimental toy language I don't really see the problem.
There are many ways to create relationships between opensource projects and corporations. Some are sane, some are not.
I can't speak for Andrew, and certainly even less for past Andrew (this is an old link), especially when quoted by somebody banned from the community.
What I can say about present-day Zig, as VP of Community at the Zig Software Foundation, is that, to put it in simple terms, we want to take a step away from the usual "get vc money, build a moat" dance that big tech likes to play.
That said, we aren't anti-business and in fact the choice of an MIT license is deliberate to provide the highest degree of freedom to any Zig user, be it individuals or companies.
The problem is that the Zig project just doesn't want anything to do with connectFree and so Andrew took appropriate measures to cut them off.
In light of the consequences of Mozilla depending so much on corporate sponsorships, it almost seems weird to me that we need to clarify why we'd like to walk a different path.
That sounds interesting but I'm not sure I understand what this means in practice. In particular I don't get this at all:
>In light of the consequences of Mozilla depending so much on corporate sponsorships, it almost seems weird to me that we need to clarify why we'd like to walk a different path.
I think Mozilla's funding is very unhealthy for Firefox in particular because it's a web browser and there can be a clear conflict of interest, especially when a lot of the money effectively comes from advertisers. What I want from a browser and what Google wants from a browser probably differs significantly. I want good privacy and control, Google wants me to see ads and build a profile.
But how does that translate to Zig, the programing language? For instance as far as Rust is concerned I'd argue that more corporate involvement is actually a good thing, it means that the language is here to stay. I may be naive but I don't really see the failure mode here. What I want from a programing language and what Google/Amazon/Netflix/Samsung want from a programing language probably has a lot of overlap.
Yeah I agree, sorry, I didn't make the point super clearly.
For the Zig programming language, it means that the commercial entity that supports the project is the Zig Software Foundation, a non-profit company. Being non-profit means that we don't have shareholders nagging the board of directors for dividends, nor we have a VC company forcing decisions on us to pursue a hockey stick.
Right now we depend on donations and we are accountable to the community through the restrictions and duties that 501(c)(3) non-profits have.
If at one point we decide that the donation business model doesn't work out, we'll think of something else, but at least we'll be free from pressure that would potentially compromise the quality of the final product (i.e. Zig and its community).
To VCs and other investors that might be reading: we're not against VC money, but we're not a tech startup. If you decide to invest in Zig, it's because you have a strategical interest in having succeed one of the most energy-efficient programming languages ever created.
We're happy to take donations, exchange logos and be vocal about our appreciation for your support, but the only terms we're going to accept are: X money for 0 shares and 0 board seats.
Are there examples in today's market where a business can depend on a new programming language? I'm curious because I'm writing a programming language, and I'd love to turn it into a business.
The most popular new programming languages (of the recent decade) are backed up by major corporations (Kotlin, Swift) or improve something (Elm, Julia) or both (Rust, TypeScript). So if you design a programming language attempt to improve something that will make your language stand out.
There are multiple companies who are dependent on a programming language. Jane Street has adopted ocaml as the main language - they are the part of the ecosystem by now with many "core" libraries they created. RStudio is depending on R.
I don't understand why the Zig developers are getting so stressed over this. So a company forked your open source project. If you are worried about closed source forks use GPL. If you are worried that people will confuse Zig with Zen just post a warning. Honestly, I don't understand why they are comparing source code and dragging three people into it.
Although we have a page documenting some outlandish comments that the founder of Zig has made about Zen[0], we find it well inside of our rights to fork the MIT Licensed Zig and make a better product with commercial support.
We had initial plans to support Zig in Japan, but efforts to localize Zig were not accepted and we could not take the risk of not having some sort of formal role.
Regarding commercializing compilers: our main market is in embedded and as others have pointed out, charging for compilers and support is not uncommon.
One of our big main differences between Zig is that Zen natively supports vtables and traits that we call interfaces[1].
Although our core market is in Japan, we are preparing our English website and hope to have it out soon.
On a more personal note, I am happy that Zig is growing and that they got the foundation together. At the peak before the fork, I was the 5th largest contributor to Zig, so I am very happy to hear when people say that they are enjoying the language.
It's midnight in Japan, but I will try to field questions if any.
Hi Loris, thanks for the question and congratulations on your new role at the Zig Software Foundation. We originally planned on supporting Zig in Japan via support contracts and this is from that preparation. Trademarks have multiple categories and one such category is for contract work and related materials. We don't plan to use this trademark to harm Zig.
since you have instead settled on forking as the zen PL, which is your right to do, would you turn that trademark over to the zig foundation as a show of good faith?
I find this hard to believe. There are plenty of companies out there providing some kind of product built on top of another (e.g. a language), without registering the name of said product as a trademark of their own.
To me it sounds more like you didn't get the things you wanted, and instead decided to try and take them by force.
Can you share your justification for non-compete clauses in employment contracts as well as contracts which take ownership of employee work done outside work hours?
What is your statement about the fact that Zen clearly takes code from Zig post fork? Do you not find it - extremely - hypocritical that you are using thousands, if not hundreds of thousands of lines of someone elses code for free while also mandating your employees enter draconian contracts? Do you think your actions will ostracize you from more communities, as has already occured with yourself and Zig?
How quickly after posting this did you regret it as a foolish midnight decision?
You were the 5th top contributor, which isn't much considering the actual top contributor (Andrew Kelley) still accounts for 60% of commits, even years after your fork "at 0.3".
Speaking of the fork at v0.3, in your response you forgot to address the claim that Zen has lifted changes almost wholesale made to Zig post-0.3. You'd think if Connectfree was doing all this heavy-lifting (as you seem keen to claim), it would be the other way around, no?
Thank-you for the question. Most of heavy lifting is in the actual compiler itself and in the vtables/trait interface feature. Although the cpp implementation now differs most, we never claimed to be a hard fork of Zig.
Of course, I don't deny that, what I'm asking is about the code that was incorporated into your project from Zig after version 0.3, such as async/await, mentioned in this very post.
I contributed to Zig by not forking it for my own financial gain ;). What features did you work on in Zig that gives you the right to claim work you didn't do and incorporate it into your project?
From your method of half responses I can see immediately why you were banned from the Zig community; I expect the next thing I will hear about Zen is its eventual closure. Also, 89 out of 10k commits makes you a footnote, not a major contributor.
- They are attempting to register "ZIG" [1] and "SiFive" [2] as trademarks in Japan. Only this is enough for me to see them as a trademark troll.
- Since Zen is a fork, Zen comes with Zig's (or its derived version of) standard library, but when they copied Zig's library source files, they removed the original copyright notice from each file header and replaced with "Copyright (c) 2018-2020 kristopher tate & connectFree Corporation." Sure, because it's MIT license, you can relicense, but is replacing the original copyright notice OK? Even if it's OK, why did they do that?
- I once attended a meetup where the CEO of connectFree, Kristopher, gave a presentation about Zen. He gave many reasons to use Zen, but most of them were Zig's features. Until someone pointed out in the meeting, Kristopher didn't mention or even imply that Zen is a fork of Zig. Many of my friends didn't actually know until this statement was made that Zen is a fork of Zig.
- connectFree recently published license terms for Zen (perhaps only in Japanese), and in the license they claimed that you are required to obtain a paid license to distribute a program even in the source code form as long as the program is written in Zen. I can't believe that you are able to force it, and it looks like Kristopher retracted the license later, but at least they tried to do that once. And you still need to buy a license to distribute a program in binary form if it's written in Zen and compiled with connectFree's Zen compiler.
[1] https://www.j-platpat.inpit.go.jp/c1800/TR/JP-2020-078615/FF... [2] https://www.j-platpat.inpit.go.jp/c1800/TR/JP-2019-153075/A7...