7 ms·

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"

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/FF75D797BF8A8562102A23936240FF60A15248A6D91AF8F8F1D741CC24A962DD/40/ja 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/A707749AD6C41F384D8CED6C08A74E7898E52A3D0239F66CE1A12E89F0D927DB/40/ja https://www.j-platpat.inpit.go.jp/c1800/TR/JP-2019-153075/A7...

asdfasgasdgasdg 6y ago
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.
- nanny 6y ago
  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.
  - asdfasgasdgasdg 6y ago
    > 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 https://bit.ly/3c21Yul
    - nanny 6y ago
      >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_organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...
      - asdfasgasdgasdg 6y ago
        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.
klyrs 6y ago
> 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.
- nanny 6y ago
  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.
  - acqq 6y ago
    > They are complying, Are they, if they removed the Zig copyright from each file in the standard library?
    - nanny 6y ago
      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."
      - acqq 6y ago
        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.
liveoneggs 6y ago
it's not okay to re-license or change copyright. You can sublicense aka make a commercial version.
nanny 6y ago
>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.
- eternalban 6y ago
  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.
  - nanny 6y ago
    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 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.
    - eternalban 6y ago
      > 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".

asdfasgasdgasdg 6y ago

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.

nanny 6y ago
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.
- asdfasgasdgasdg 6y ago
  > 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 https://bit.ly/3c21Yul
  - nanny 6y ago
    >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_organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...
    - asdfasgasdgasdg 6y ago
      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.

klyrs 6y ago

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

nanny 6y ago
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.
- acqq 6y ago
  > They are complying, Are they, if they removed the Zig copyright from each file in the standard library?
  - nanny 6y ago
    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."
    - acqq 6y ago
      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.

liveoneggs 6y ago

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

nanny 6y ago

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

eternalban 6y ago
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.
- nanny 6y ago
  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 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.
  - eternalban 6y ago
    > 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".