weso / shapes-rs

RDF data shapes implementation in Rust
https://www.weso.es/shapes-rs/
Apache License 2.0
23 stars 1 forks source link

ambiguous licensing #62

Closed jonassmedegaard closed 2 weeks ago

jonassmedegaard commented 2 weeks ago

README.md states that licensing is Apache-2.0 or MIT, but Cargo.toml states it is GPL-3.0-or-later. Which is it?

jonassmedegaard commented 2 weeks ago

While at it, MIT license is included both as LICENSE and LICENSE-MIT, the former with an unfinished copyright statement lacking a copyright holder.

labra commented 2 weeks ago

Thanks a lot for reviewing this...you were right that the licenses were not properly declared.

I have changed the information in Cargo.toml to indicate that we have two licenses: MIT and Apache. If you think it would be better to add a GPL license, I would have no problem at all (I am not sure if it is possible to publish it with three licenses).

I have also edited the line in the LICENSE-MIT and LICENSE-APACHE files adding me as copyright holder (I am not sure if I should add the other contributors...or how I could do it in a way that is more maintainable.

If you think this is OK, you can close the issue.

jonassmedegaard commented 2 weeks ago

In my understanding (I am not a lawyer, but has spent some years staring at licenses), there is no benefit in adding GPL as an additional alternative license: GPL-3 is compatible with Apache-2.0 (but the inverse is not true: The resulting license when combining works licensed as GPL-3 and Apache-2.0 is GPL-3).

There is a problem in your editing the LICENSE-APACHE files, though: The Apache-2.0 license text is intended as a fixed document, which at the end contains an example of how to use it. You should not edit that example, but instead reference the document. In fact, the paragraph just above the line you edited states quite clearly how the authors recomend that you use the document.

MIT license, by comparison, is an older license, much shorter and intended to be declared verbatim each time it is used - originally it was not stored as an independent document, referenced from other files.

My recommendation is to treat both those files as static, and add single-line SPDX copyright and licensing statements to each and every file containing creative work - i.e. every code file and every "interesting" graphics file.

I also recommend to add your email address with your copyright statement, as a unique identifier.

Ideally, every legal entity (person or organisation) that has made substatial creative contribution should be listed as copyright holder. I cannot tell if those you consider constributors fit that bill or not, nor if your university fit that bill (I notice that you've added yourself, but list your university in lib/docs/mkdocs.yml - generally an employer should be listed if your creative work was done "paid by them" - i.e. if your contract with them says that they own your intelligense while you work for them - often american contracts are more aggressive in that regard, but in newer times it becomes more common for that predatory attitude towards ownership of labor).

jonassmedegaard commented 2 weeks ago

Just for clarification: One reason you might want to license as GPL-3+ is if you appreciate its copyleft nature, but in that case you will want to not "water it down" by dual-licensing as Apache-2.0 or MIT: You would then license only as GPL-3+.

jonassmedegaard commented 2 weeks ago

small nit: Instead of copying the license text documents, I suggest symlinking the files at the root of the project.

labra commented 2 weeks ago

In my understanding (I am not a lawyer, but has spent some years staring at licenses), there is no benefit in adding GPL as an additional alternative license: GPL-3 is compatible with Apache-2.0 (but the inverse is not true: The resulting license when combining works licensed as GPL-3 and Apache-2.0 is GPL-3).

So I understand it is fine for us to keep Apache 2.0 by now.

There is a problem in your editing the LICENSE-APACHE files, though: The Apache-2.0 license text is intended as a fixed document, which at the end contains an example of how to use it. You should not edit that example, but instead reference the document. In fact, the paragraph just above the line you edited states quite clearly how the authors recomend that you use the document.

OK, I created PR #65 with the idea to revert those files.

My recommendation is to treat both those files as static, and add single-line SPDX copyright and licensing statements to each and every file containing creative work - i.e. every code file and every "interesting" graphics file.

I didn't know about the REUSE software...it looks interesting, and maybe we should adopt it in the future. I will create an specific issue to keep track of that.

I also recommend to add your email address with your copyright statement, as a unique identifier.

OK, I added my email to the LICENSE-MIT file.

Ideally, every legal entity (person or organisation) that has made substatial creative contribution should be listed as copyright holder. I cannot tell if those you consider constributors fit that bill or not, nor if your university fit that bill (I notice that you've added yourself, but list your university in lib/docs/mkdocs.yml - generally an employer should be listed if your creative work was done "paid by them" - i.e. if your contract with them says that they own your intelligense while you work for them - often american contracts are more aggressive in that regard, but in newer times it becomes more common for that predatory attitude towards ownership of labor).

I think it is safe if we keep it by now with the individual contributors. Indeed, I didn't want to add myself alone and I prefer the idea of having a list of contributors in a file and refer to it from the Copyright as the "Shapes-rs" team, or something like that.

Do you know about some Rust project that has the license statements right that we could use as an example. Until now, my main source of inspiration is Oxigraph.

labra commented 2 weeks ago

I merged the PR with the changes...at this moment, I am a bit hesitant about adding the single line SPDX copyright statement to each source code file, mainly because we have a lot of files...

But once you consider that what we have now is more or less OK, we could close this issue and open a new specific one about that.

jonassmedegaard commented 2 weeks ago

Regarding project-wide licensing, Oxigraph handles copyright and licensing decently, in my opinion.

I agree that file-specific copyright and licensing statements is a different (and arguably less important) issue, sensible to track separately.