Hacker News Reader

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

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.

> Why do you think that?

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.

I don't agree that each file on its own is a separate work subject to copyright. Even the original Zig headers say that each file "is part of zig" (emphasis mine). The "work" in this case is the software project as a whole. That's what's being distributed.

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.

> I don't agree that each file on its own is a separate work subject to copyright.

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.

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

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

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

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.

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:

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

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

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.

How can you be sure the license notice wasn't meant to apply to the project as a whole, as I imagine is overwhelmingly the more common intention? That is the obvious question here.

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

> Each file is not "the Software".

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.

I don't know of any court cases or other precedent, no. I am working with the definitions of "software" and "program" as I am familiar with them being used in various software licenses. But that doesn't really matter because the only assumptions I'm basing this argument on are contained in the MIT/Expat and what connectFree has done with Zen.

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.

Wrong. If every source file is "software" the copyright should not be removed from the source file.

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.

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.

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.

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)

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