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...
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.
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.
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 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)
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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...