ModOrganizer2 / modorganizer

Mod manager for various PC games. Discord Server: https://discord.gg/ewUVAqyrQX if you would like to be more involved
http://www.nexusmods.com/skyrimspecialedition/mods/6194
GNU General Public License v3.0
2.15k stars 159 forks source link

Copyright and licenses #1106

Open isanae opened 4 years ago

isanae commented 4 years ago

For all projects:

For all projects except modorganizer and uibase:

For the modorganizer project:

For the uibase project:

TanninOne commented 4 years ago

I have no problem with removing the license block from the individual files and putting them into a LICENSE file at the base of the project, because the LICENSE is the same across the entire project.

The copyright notice is a bit of a different beast because everyone holds the copyright of whatever code they wrote (In most countries you can give up your copyright to someone else if you want. In Germany where I live that's not legally possible. Even if I wanted to I can not give up the copyright to my code). The copyright line, to my knowledge, is not legally relevant, it's merely there to make it easier to figure out who owns the code. Having a central CONTRIBUTORS file may misrepresent or make it confusing who owns code, it does not legally change it. Assume you write a new library or class within Vortex from scratch, you can just slap your copyright at the top of the file and then it's clear that you, and only you, have the right to reuse that same class under a different license (e.g. in your next project that is closed source, or in your job). Everyone else can only use it under the GPL. I have the same right for the files that were exclusively developed by me. If you have a central contributors file that lists me first, people may think that you violate my copyright even when you just re-use your own code in a different project under a different license.

If you centralize the contributors it will become extremely difficult to figure out who owns the rights to re-license parts of the code. Imagine at some point you want to factor out part of the MO code into an MIT licensed library, how do you figure out who you need to ask for permission?

So therefore I would advice against removing copyright notices, rather I would suggest you add a line "Modified by x, y, z" to keep track of everyone who holds copyright to any part of the file.

isanae commented 4 years ago

If you centralize the contributors it will become extremely difficult to figure out who owns the rights [...] I would suggest you add a line "Modified by , , " to keep track of everyone who holds copyright to any part of the file.

I don't think it's feasible to keep track of individual contributors in every file. It's not even strictly correct: people own the code they write, not the whole file. The CONTRIBUTORS file is a middle-ground: it lists everybody who contributed to something. If anybody needs to know exactly what's owned by whom, they can peruse the git history.

I think that's as far as we need or want to go.

Imagine at some point you want to factor out part of the MO code into an MIT licensed library, how do you figure out who you need to ask for permission?

To do it properly, you'd need to contact the people who contributed to whatever code you want to use. Having a dump of author names at the top doesn't help you with that, you still need to go through the git history.

And this is a problem with how everything is a set up right now in any case, this change wouldn't make it more difficult.

TanninOne commented 4 years ago

You can't easily rely on git history/blame. Just because someone contributed to a file once doesn't mean they actually hold copyright to anything. If I go and change the indentation style on a file from space to tabs, git will display me as the author for almost the entire file but I didn't author anything. That's why a manually maintained list is actually pretty important even if it's tedious. If you don't have one it will be borderline impossible to re-license the code, it would take a lot of manual work to figure out the actual owners and at that point it might be easier to just rewrite it.

That may not be relevant though, how likely is it that you want to relicense MO as a whole?

isanae commented 4 years ago

Just because someone contributed to a file once doesn't mean they actually hold copyright to anything. [...] That's why a manually maintained list is actually pretty important even if it's tedious.

It not tedious, it's infeasible. I'd have to check the history of any line of code I delete to check if I can safely remove a name. It'll become stale very quickly. Nobody wants to manage this stuff.

TanninOne commented 4 years ago

Well, it would fall upon the individual contributing to a file to put their name into the header and removing names from there isn't really all that important, at the point where you actually need to know the list of contributors you can still filter. That is still a lot easier than at that point going back through the history trying to find out who holds any rights to the file.

And if you have the list of contributors and you have someone on there who doesn't actually hold a copyright (any more), worst case scenario is you ask someone for permission who doesn't actually have the right to say no. If you don't have a list your worst case scenario is that you violate copyright law because you failed to ask someone who did have the right to say no.

Again, all this is probably extremely hypothetical

isanae commented 4 years ago

You said that the git history is unreliable because not all contributions are copyrightable, so you might end up with false positives. Maintaining a manual list would be more accurate.

I'm saying it wouldn't more accurate, because it still gives false positives for authors whose contributions have since been removed.

In any case, this is all stuff we don't even have as of now. I'm trying to simplify what we have, not add new stuff.

TanninOne commented 4 years ago

That's not the same. If "user a" writes code and then "user b" runs a prettifier over the code, git history will show "user b" as the author of practically the entire file. This doesn't just put user b on the list of authors when he shouldn't be, it may remove user a from that list because his contribution appears as being removed.

If "user a" authored code, put themselves on the list, then "user b" authored code which made user a's code unnecessary and added himself to the list, both users are on the list, both would be treated as authors... ...which might not be incorrect because if user b's code is based on user a's code, even if the actual code lines have been removed, user a might still be able to claim copyright, arguing that user b's contribution is just derivative. You, as the maintainer, would be well advised to treat user a as a contributor to avoid misgivings.

My point is: treating someone as a copyright holder who isn't is just an inconvenience. The other way around might have serious legal repercussions. (which is the point where I guess I need to state very clearly that I'm not a lawyer, this is just my understanding of it)

isanae commented 4 years ago

treating someone as a copyright holder who isn't is just an inconvenience

I get that. But we also have to be practical about it. It's not required to maintain a list of authors in files and I find it unlikely that we'd be able to maintain it correctly. I definitely wouldn't want to maintain it myself. I don't want to create a policy that would be ignored.

In any case, the chances that such a list would be useful to anybody is so remote that I would qualify it as useless, while forcing us to spend a lot of time 1) creating such a list in every file, and 2) maintaining it.

If we already had something equivalent, then things would be different, and I would be wary of losing that kind of information. But we don't.

Al12rs commented 4 years ago

If we add the contribution agreement it means that we don't need to worry about having to curate a list apart from making clear who the current maintainers are, for which we can use the CONTRIBUTORS file.

TanninOne commented 4 years ago

Yeah, I know that it's impractical, I'm just saying that in an ideal world you'd have that list and people who add code would add themselves and so it would mostly maintain itself. If you have a CONTRIBUTIONS file that lists everyone who everyone who contributed anything to MO at all you can just treat (implicitly) every individual file as "copyright by one or multiple people from contributors". And then you can still become more concrete for individual files when the need arises.

I think my whole point was simply "There is a really good reason to have a correct list of copyright holders for a file.". If it's impractical to maintain it, fine, just be aware that you're also giving something up when you don't have it.

Holt59 commented 4 years ago

The other way around might have serious legal repercussions.

I don't really understand the issue with what you said before. It is quite easy to extract the list of all authors from git log, even if nothing remains from their actual code.

Yes, this would probably add some contributors that actually did not contribute anything or anything copyrightable (or if nothing remains from the code), but that's more an issue for people that want to use MO2 code than for MO2 developers.

TanninOne commented 4 years ago

If all you care about a list of everyone who's ever touched the file, sure. But a manual list can be updated by people. You can then remove someone from the list when you have verified their contribution is no longer there (for that file). No one who's ever contributed anything will ever disappear from the git log.

If you properly keep track of contributions from the get go it's not a lot of work, only if you retroactively want to figure it out do you have a problem. This proposed solution (a central contributions file) simple pushes the problem off, hoping (quite rightly so) that it might never really come up. Again, this is fine, I don't know how often I said this now, I'm ok with your approach. I'm simply arguing that the proper solution would be per-file copyright notices that actually list everyone they need to list. A central LICENSE file is a completely valid, perfectly sensible solution that correctly reflects the legal situation (as in: the entire project is released under one license) A central CONTRIBUTORS file is not, it's a "hack" that may be a sufficient, pragmatic, approach but it does not reflect reality.

AnyOldName3 commented 4 years ago

I don't really understand the issue with what you said before. It is quite easy to extract the list of all authors from git log, even if nothing remains from their actual code.

What if someone copied and pasted code from somewhere else (e.g. another MO2 repo, like has recently happened for a few of the things that got moved to UIBase, or another GPL project)? They then show up as the only contributor in the Git log, despite someone else being the original copyright holder.

I'd be inclined to say we should have something for new contributors saying they need to do something like ensure we have an up to date way of contacting them (and if it doesn't work maybe say they have to let us treat their work as public domain/CC0) or have them state all the licences we can treat their work as so we know what needs purging if we relicense. We should also make sure people note down when stuff came from somewhere else.

It would be nice if copyright law was sane enough that Git could have a metadata system for keeping track of who actually owned what.

TanninOne commented 4 years ago

I wrote earlier that in germany, copyright can't be transferred. In commercial settings this is a non-issue. Even though every individual employee in a company holds the copyright of the code they produced, their employment contract gives the company the exclusive license to do whatever they want with the code and agree to not use the code outside the company. At that point the employer still has the copyright, it's just not worth anything.

I think what you want in an open source project is something similar. ASAP you want a contributor agreement that states: If you send us a pull request or code snippet, you implicitly give the active maintainer of the repo the following rights: a) To transfer these rights to someone else (if the repo changes hands) b) To relicense the entire repo, including your code (maybe add a bunch of assurances, i.e. the contributor will always be attributed, only OSS licenses, ...) c) To use, modify, publish the code for however long they want under that license (obviously you'd want to copy&paste some proper lawyer text for this)

Before you can re-license (if you ever want to) you need to get previous contributors to agree to the same conditions. If they refuse (or don't reply): rewrite their code passages and drop their code. The first part you might want to do asap as well because the sooner you do the better the chance you can reach everyone and get their permission. Rewriting code passages, if necessary, you only need to do if you actually want to change the license, you just have to keep track whose code you can't re-license.

At that point you should be safe. Who the copyright holder of the code passages are isn't really important to you any more. Again, you should always attribute all contributors but that shouldn't be a problem. The copyright holder can still take their own code and also re-license it however they feel, that doesn't concern you because they can't take the license away they gave you.

Karandra commented 4 years ago

I think what you want in an open source project is something similar. ASAP you want a contributor agreement that states: If you send us a pull request or code snippet, you implicitly give the active maintainer of the repo the following rights:

Do you have an example of how that document would look like in more formal way than these tree points?

TanninOne commented 4 years ago

You could dig through this wiki article: https://en.wikipedia.org/wiki/Contributor_License_Agreement One example would be the python CLA (contributor license agreement): https://legacy.python.org/psf/contrib/contrib-form/contributor-agreement.pdf