Hello HN and sorry for this bizarre drama! 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 fo…
Statement Regarding the Zen Programming Language
251–260 of 299 posts
Re: Statement Regarding the Zen Programming Language
#252Earlier quoted context omitted.
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."
I still think that: "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.
Re: Statement Regarding the Zen Programming Language
#253Earlier quoted context omitted.
Ok well here are the facts. Open means freely and widely available. Source means source code. Open source means the programs code is freely and widely available. If you want to add other stuff onto that you need to find a new phrase.
You're equivocating. 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…
Re: Statement Regarding the Zen Programming Language
#254Earlier quoted context omitted.
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 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...
Re: Statement Regarding the Zen Programming Language
#255Earlier quoted context omitted.
Note to self: don't ever again use MIT license for my OSS projects. [ascii art fan here..] Apache says something about "retaining category A header licenses" but not sure what category A means.
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 do…
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".
Re: Statement Regarding the Zen Programming Language
#256I 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.
Re: Statement Regarding the Zen Programming Language
#257Earlier quoted context omitted.
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.
Re: Statement Regarding the Zen Programming Language
#258Earlier quoted context omitted.
From the horses mouth [1]: > 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…
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.
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.
Re: Statement Regarding the Zen Programming Language
#259Earlier quoted context omitted.
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 do…
> Just know what you're getting into. 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 tho…
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.
Re: Statement Regarding the Zen Programming Language
#260Earlier quoted context omitted.
>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 derivativ…
Note to self: don't ever again use MIT license for my OSS projects. [ascii art fan here..] Apache says something about "retaining category A header licenses" but not sure what category A means.
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