Hacker News new | ask | show | jobs
by rainfall 2108 days ago
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.

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

4 comments

> 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.
> They are complying,

Are they, if they removed the Zig copyright from each file in the standard library?

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...
"The single files (or substantial portions of them) are not what's being distributed in this case."

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

>Does a single notice in the lib/zen/std/LICENSE file satisfy the requirement "shall be included in all copies or substantial portions".

Yep. The single files (or substantial portions of them) are not what's being distributed in this case. The Software is the thing being distributed, and it meets the requirements as described in the license (that the original copyright and permission notice be included). Therefore, it is in compliance.

If there is individual notice on the file because the file is a work individually licensed under MIT, removing it from the file is removing it from an MIT protected work in violation of the license.

That the individually-protected work is also included in an compilation which is itself licensed under MIT does not remove or loosen any licensing requirements on the smaller work.

>If there is individual notice on the file because the file is a work individually licensed under MIT, removing it from the file is removing it from an MIT protected work in violation of the license.

Why is that in violation of the license? The only condition specified in the MIT/Expat license is this:

>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Each file is not "the Software". "The Software" means the Zig/Zen projects as a whole. The "above copyright notice and this permission notice" is included in the copy of Zen. Therefore, it is in compliance.

I wrote in another comment:

>In addition, the Zen headers say "This project may be licensed under the terms of the ConnectFree Reference Source License" and "See the LICENSE file at the root of this project for complete information". This statement is enough to imply that the project as a whole is covered by the specified LICENSE file.

So how do you tell the difference between the files having been licensed individually or only the whole compilation having been licensed?

Here is some of the license text:

> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software") [...]

That seems to me to indicate that it applies to the whole software package and not any single file (unless you could call that single file a "software" in its own right, maybe?)

Meanwhile, the text in each individual file only says this:

> Copyright (c) 2015 Andrew Kelley

> This file is part of zig, which is MIT licensed. See http://opensource.org/licenses/MIT

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.

Why do you think that?

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.

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.

[1] https://en.wikipedia.org/wiki/Moral_rights [2] http://www.japaneselawtranslation.go.jp/law/detail_main?id=2... (Copyright Act of Japan) Subsection 2 Moral Rights of Authors (Articles 18 to 20)

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

>OK, but I was talking about the file headers. :)

Gotcha, then you are correct. The MIT/Expat only requires: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software". As long as they are in compliance on that regard then they are in the clear.

>Sure, but the new work is the portions that you've changed, not the portions that you've copied, right?

No, the new work is the piece of software work as a whole, not the individual files. "Work" in this context is a legal term that includes all of the source code and nonliteral elements of the software, aka the Structure, Sequence, and Organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...

R.e. your second statement, I can only presume that you're right, but I'm confused about how this works with copyright license agreements, or the cases where projects have had to go and get copyright releases from authors of individual lines of code to make a license change. If the copyright is on the entire work, how can a contributor of just one line of code own the copyright? Anyway. You seem more versed in this than I am, so I bow to your expertise.
In that case, there would be multiple authors of a single copyrighted work. I'm only familiar/knowledgeable with GNU copyright assignment, however, not copyrights in general. https://www.gnu.org/licenses/why-assign.en.html
> I suspect that the license may not require you to retain the notices

It explicitly does.

Just read the MIT license. Doesn't say anything about file headers.
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.

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 don't know anything about that and I can't find anything about headers in the Apache v2.

> 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 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: metadata: I suspect that it may indeed be already incidentally covered by existing licenses. I replied elsewhere with a link to this wikipedia page: https://en.m.wikipedia.org/wiki/Structure,_sequence_and_orga...

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

You're entirely correct.

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.

it's not okay to re-license or change copyright. You can sublicense aka make a commercial version.