MIT license violation

[zatherz]

0b301da#diff-61e0bdf7e1b43c5c93d9488b22e04170

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

[flajann2]

Since I maintain both Jeweler and Juwelier, it is unclear to me if there is an MIT license violation, though there may appear to be one. To avoid confusion, I will deal with this shortly.

[zatherz]

Whoever wrote the original code has copyright to it.

[flajann2]

Unless the original owner passes along the copyright to a new owner. It's a fine point, and I know the original owner doesn't really care. We talked at length before he handed me the reigns. And the original code base is still on his account, so he could yank it back anytime he likes.

I hate legal stuff. If he tells me differently, then I will comply with his wishes. Other than that, I assume copyright. And it's Open Source, anyway. It is not a big deal to me. But I know a lot of pedantic corporations might have an issue with the ambiguity, so I will address it shortly.

Thank you for bringing this to my attention.

[pboling]

@flajann2
Traditionally you would keep the original copyright line, unmodified, and add additional lines as the project moves through different maintainers. Any changes to the project become legally unlicensed if you make changes and are not the original author, unless the author accepts those changes into their project under their license and copyright.

As the new maintainer, and where the old copyright holder is no longer approving or making copyright claim to the additions to the code, you have two options:

1. Accept changes to the project under the same license, and you would need to add a new copyright line under the original indicating that the license remains the same, and the copyright for changes is claimed by you.

   Copyright (c) 2008 Josh Nichols
   Copyright (c) 2016 Fred Mitchell
   

2. Change the license for the new additions and alterations. This makes the code very difficult to use for a corporation, and the correct way to do this varies depending on the license you are moving to, but in any case you can't change the original license for the original portions of the code, and might then need to move to a file by file licensing.

Here is an example from a project I took over in 2012, where I kept the same license, and just copyrighted the changes to the original code:
https://github.com/pboling/flag_shih_tzu/blob/master/LICENSE

There are, to be sure, many examples of repositories that are doing the license and copyright thing incorrectly. I have probably done it wrong myself. I think I'll go clean some up.

[flajann2]

I'll take a look at this.

[pboling]

I've learned a bit more about "best practices" with the copyright notice since my last comment almost 5 years ago(!). You should, at minimum, add Copyright years for each year that changes to the code were accepted into the authoritative branch from which releases are produced. Consecutive years can be represented with a dash for the intervening years, and commas can be used to separate gaps.

Bottom line is if there were no code changes in a given year, then you would skip that year in the copyright notice.

There would never be a 2015 or a 2021 listed, because no changes were applied, thus the copyright notice literally doesn't apply to anything in the codebase for 2015 or 2021.

I just paged through all the dates of all commits, and it looks like this would be the most accurate Copyright notice for this project:

Copyright (c) 2008-1014 Josh Nichols
Copyright (c) 2016-2020 Fred Mitchell

Separately, to address some misunderstanding:

Unless the original owner passes along the copyright to a new owner.

• Historical copyright can be transferred, but in a case like this probably has not been.
• The statement above is "true", but such an act isn't as simple as what likely happened here.
• The rights to the future of the project have been transferred, but the historical copyright, legally, probably hasn't changed.

The requirements to change the historical copyright (which is to say the ownership of the existing, dated, copyright, which is historical, since future copyright always belongs to the author) are:

(a) A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner’s duly authorized agent.

The good news is, because this is open source, the historical copyright doesn't need to change!

[AndyObtiva]

Now, if only @flajann2 would hand me the reigns for the Juwelier and Jeweler projects, I’d be a happy camper! Hahaha! I include Juwelier in my Glimmer gems/apps (https://github.com/AndyObtiva/glimmer-dsl-swt) as the main mechanism for generating projects and building gems. I’ve reported and submitted a number of issues and pull requests. If only they’d get merged. I’ve been waiting for years now. Id be happy to modernize Juwelier/Jeweler going forward. I don’t know.. maybe the issue is I don’t pronounce Juwelier properly in German. I guess I gotta work harder on that!

[pboling]

Here is a good explainer on how to follow best practices with the years in the license / copyright:

https://opensource.stackexchange.com/questions/5778/why-do-licenses-such-as-the-mit-license-specify-a-single-year