Licensing translations

[marton-balazs-kovacs]

We want to recognize the work of the translators and the original authors of the CRediT taxonomy, so we plan to add a cff-formatted license file to each translation using ccby.

Creating separate repositories for each translation would allow us to use github's functionality to automatically create releases (also on Zenodo), but we fear that in the case of multiple translations that do not change regularly, it would create an additional administrative burden to manage all the repositories, and corrupt the discoverability of the translations.

The other possibility is to store each translation and the license.cff sidecar files in a different subdirectory of the same directory.

Finally, it is also possible to store all the translations in one big JSON file with one license for the whole project that includes the names of all the translators across all the languages.

All the previously listed options have benefits and downsides. We are interested in the community's perspective on this topic.

[jcolomb]

hey @marton-balazs-kovacs , CITATION.cff file is not a license file, it is a metadata file mostly interesting here to name the authors of the translation(s), these are picked up by zenodo if you use github2zebnodo integration.

Do you want to be able to cite and recognize authors of single translation ?

If not, one file per translation, but all translations in one repository is the easiest option. One big json file is a bad idea, too difficult to work on (merge conflicts will be too common)

A propos licenses: add a License.txt file in the repository + indicate license (with URL) in the readme.md file is all you need.

[marton-balazs-kovacs]

hey @jcolomb thank you for the suggestion. We want to provide a license for each translation separately, but we would like to stick to one repository for all the translations to help discoverability. Based on your suggestion I think we will have a License.txt file in each subdirectory for each translation and list the languages in the readme.md.

We might create a zenodo to have a DOI for each translation separately by hand.

[jcolomb]

not sure why you would have a license for each translation if it is the same license (CC-By, right?).

I guess you are confused about the difference between license (dealing with what you can do when you are not the copyright holder) and copyright holder (who actually has all rights, including changing the license and giving authorisation to use the content beyond what the license allows). ?

[alexholcombe]

Thanks for explaining that about license.txt versus CITATION.cff.

It indeed will be the same license (probably CC-BY) for all translations.

You're right I am confused however, because whenever I see a CC-BY license, it also mentions the copyright holders, for example when you generate such a license on the Creative Commons website. But @jcolomb are you saying that it is ok to just say "CC-BY" in one place without saying who you have to credit (who the BY refers to), and only say that part in a different place?

Another question we have is whether if we release the translation CC-BY, does that mean that a journal using it would have to list the holders on every article they use the translation on, e.g. writing "CC-BY Marton Kovacs and Marton Varga" for every article in a Hungarian-language journal? Or could they just write "CC-BY Marton Kovacs and Marton Varga" on a page somewhere on the journal site without writing it on every article?

[alexholcombe]

About the second point, someone pointed me to this https://wiki.creativecommons.org/wiki/Recommended_practices_for_attribution#Attributing_text where there is a mention of a separate web page I see there , but it seems to be specifically about multimedia where it's difficult to embed the license, like an audio file. But maybe the intention is more general and we can rely on this: "You may satisfy the attribution requirement in any reasonable manner based on the medium, means and context in which the Licensed Material is used. For example, it may be reasonable to satisfy some or all of the conditions by retaining a copyright notice, or by providing a URI or hyperlink associated with the Licensed Material, if the copyright notice or webpage includes some or all of the required information."

[cameronneylon]

I guess two points: The version 4.0 licenses create some flexibility in how andwhere attribution is given. This gives the user a bit more flexibility as you suggest above. It also gives a little more clarity over the ability of the licensor to say how attribution is given. So you could make life easy by having an attribution page (for all the translations) and say that to attribute they should link to that page with some text either from within the CREDIT statement or a sensible place on the website (presumably linked to from the statements).

In practice its best to be explicit about what you want, probably incorporate a link to an acknowledgement page in the statement being generated. In the end its not like you are going to sue if someone does it wrong, but you will be in a good position to send a sternly worded email to ask them to fix it

The final question is who is the copyright holder. My recommendation is always to simplify that where possible. So in this case I'd suggest that the contributor guidelines state that people agree to assign or waive (cc0) copyright, and in return they get acknowledged. I guess that Tenzing isn't an actual org that can own copyright so assigning isn't an option.

To answer the original question I'd think that one repo is far easier, with a single top level statement of acknowledgement and a single license statement. What that doesn't give you is nice authorship recognition via Zenodo but (aside from doing something crafty with git submodules and multiple zenodo entries) I don't think that integration is really able to handle this use case (we have similar issues with the expanding list of authors for our software projects and whether someone ceases to be an author if a particular release, and therefore version DOI, no longer has any of their code in it - and this in turn links back to roles and contributors because they might have made architectural contributions even if there is none of their code left etc etc)