- They are attempting to register "ZIG"  and "SiFive"  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.
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.
Are they, if they removed the Zig copyright from each file in the standard library?
If the single files are not being distributed how do we know then, then header has been changed on single files?
On the other hand: if somebody received these individual files - they were also distributed... each one of them...
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.
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.
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.
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.
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.
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:
> Copyright (c) 2015 Andrew Kelley
> This file is part of zig, which is MIT licensed. See http://opensource.org/licenses/MIT
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.
"in all copies or substantial portions"
also means that every source file of the standard library or the header must keep the original copyright.
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.
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.
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.
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...
It explicitly does.
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.
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.
Apache says something about "retaining category A header licenses" but not sure what category A means.
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.
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.
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.
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 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.
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.
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.
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.
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.
Before this post I never knew Zen existed. Now I know it exists and am emotionally invested in it. And there's no such thing as bad publicity.
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.
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.
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.
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".
Saying that Zig’s creators should sit down and be quiet sounds both condescending and craven.
And lay off the personal attack, 'k?
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.
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.
When did fairness go out of fashion?
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?
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.
If you want to help speed the development up:
https://github.com/ziglang/zig to contribute
https://github.com/sponsors/ziglang (or email us at firstname.lastname@example.org) to donate
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.
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.
Embedded platforms, Apple (100€£$/year), Windows, PGI/CUDA, IBM/xlc,game consoles,....
The compiler isn't commercial, unless you are saying that anything Apple makes is "commercial" because they are a for-profit business.
You only need to pay for it if you distribute your app on the app store.
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.
Symantec signed off on it a few years ago, it's been Boost licensed ever since.
These restrictions only apply to the Visual Studio 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.
Edit:  https://visualstudio.microsoft.com/vs/community/ (under "Usage")
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.
The compiler is not commercial and does not require a developer account.
Can you do something completely unrelated to the question at hand without fulfilling requirements entirely unrelated to the question at hand? No.
That doesn't make the compiler commercial.
> Or to end users in some other way?
You can put your mac application on your website more or less as you've always been able to.
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.
(Ignoring the GPL issues)
clang is always a cross-compiler, including the versions shipped by Apple.
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.
Not a compiler, but the same idea.
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."
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 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
Andrew, et al: "you're being an asshole"
Kristopher: "we're not doing anything illegal"
Which to an outsider just reads like a tacit admission of being an asshole.
They already implement a code of conduct to restrict behavior in their community.
The person in question is free to use the code and be an asshole. Everybody else is free to call him out for it.
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).
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'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.
For instance, there's Debian's (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 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.
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.
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 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.
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.
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.
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“
Just because the license allows anyone to fork it and sell it doesn’t mean that Zig is obliged to endorse it.
This is my favorite part about open source. Why are you painting it as a bad thing?
That would be against the spirit of GPL, which is ideologically opposed to all proprietary software.
It's a good way to support a project - companies don't like the GPL but they also want to spend money on support.
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.
Remember that it's not free it's about lawyer approval.
You could grant them an MIT license, I guess.
GPL does not prevent you from selling a commercial version, only from closing up the source.
Having no access to the source is to direct user determent.
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.
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?
Me telling you there is a cliff here, be careful does nothing to infringe on your rights to walk off that cliff.
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.
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.
GPL violations are not unknown. Would Zen have really cared about breaking the license? Would legal mechanisms work fast enough to limit damage?
If it were licensed GPL and they were violating that license they could sue in the legal system instead of writing a blog post with dubious effect.
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.
>If it were licensed GPL and they were violating that license they could sue in the legal system instead of writing a blog post with dubious effect.
Suing isn't a good idea even if you have a case. The blog post does more with less effort.
Even if Zig and Zen were GPL the employees agreement can be structured such that his work on Zen can not be used for Zig. There's an FAQ for this sort of stuff: https://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesU...
>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/
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.
You really believe a guy setting up a superficial fork in his basement has "millions" to pay out in damages?
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.
Pretty sure the ask isn't the Zen source.
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.“
1. Why do you believe that No. 2 can make valuable contributions to Zig if you do not value his contributions to Zen?
2. Why do you believe that No. 2 would be a potential contributor to Zig if he weren’t otherwise legally restricted?
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.
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.
IIRC the AGPL is better for this, but most GPL licenses are just blacklisted by companies; reducing the likelihood of the language catching on.
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.
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.
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?
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.
Honestly, that's one of the most important reason I'm looking favorably at Zig. And D.
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.
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.
>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.
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.
But what a PR opportunity! Here's an outfit selling Zig (because it's good enough already), which won't even hit 1.0 for "two years" \o/
("Two years" is from Andrew on a recent podcast.)
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.
edit: add "new" to programming language