search

NLeSC / python-template

Netherlands eScience Center Python Template
https://research-software-directory.org/software/nlesc-python-template
Apache License 2.0
164 stars 74 forks source link

Add note to generated package readme about consequences of removing the credit line #292

Open jspaaks opened 3 years ago

jspaaks commented 3 years ago

suggest hiding instead with 


<!-- 

credit line goes here

-->
LourensVeen commented 3 years ago

Maybe this should be a separate issue, but I'll err on the side of keeping things together. This credit line reminds me of the BSD advertising clause, and I'm wondering if it wouldn't be better to consider the template a software dependency. That would make this an instance of the transitive software credit problem.

I remember us and Stephan talking about whether a CITATION.cff should only contain information on how to cite the software, or also references to dependencies, and I don't remember if anything was decided and if so what, but maybe this should be in the CITATION.cff?

I guess my main issue is that it feels a bit weird to prominently list this template that I used years ago to initialise the repository, and which has since been modified a lot, while not listing the library that implements half of my functionality, for instance.

If the generated code itself is licensed under the Apache 2.0 license (I'll make a separate issue for that), then we could also use a NOTICE file actually.

jspaaks commented 2 years ago

(insert Squarepants meme "One eternity later")

If I understand the advertising clause correctly, it's a legal mechanism to enforce keeping the credit notice in generated packages, right? That does seem a bit much to me, I think I'd rather make an appeal to people to keep the credit section, or if they feel like "but was such a long time ago that I used the template", ask that they simply hide it with the <!-- text here -->, which would allow us to find it back via GitHub search.

Regarding use of references key in CFF: if the generated software wants to give credit to the cookiecutter template, putting it in references would be a valid way and we could even make it part of the template, so we already cite ourselves preemptively.

I guess my main issue is that it feels a bit weird to prominently list this template that I used years ago to initialise the repository, and which has since been modified a lot, while not listing the library that implements half of my functionality, for instance.

I agree that is a bit odd

LourensVeen commented 2 years ago

Yeah, clause 3. of the original BSD license reads:

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the .

There's nothing wrong with asking people to credit you of course, but this particular one causes practical problems if you try to advertise something like a Linux distribution, which can contain tens of thousands of packages. Try getting all those credit lines into your advert! Likewise the README would get long if you had to credit all (transitive) dependencies in it. At least, that's what I think I meant, I have no recollection of writing the above :-).

So the point of this is that we want to be able to track how often this template is used, right? I agree that it would be good to explain that we need that information to justify spending more time on it, but I think I'd prefer parsing a well-defined CFF file than grepping a README.

jspaaks commented 2 years ago

So the point of this is that we want to be able to track how often this template is used, right?

Correct

egpbos commented 2 years ago

I think it would be more productive and impactful if tracking templates was done via cookiecutter itself. There are many other uses for keeping around some kind of cookiecutter metadata, for instance those mentioned in these threads: