Clarify recipient requirements under the "Who to Credit" section about credit-requirement HOT 13 CLOSED

@bmintz I read your Broad Feedback section, too. You're dead on that I had in mind to "close the SaaS loophole" for attribution rules, as network-copyleft licenses tried to close that loophole for copyleft rules.

I would be careful about using "attribution" and "credit" interchangeably. Traditional, MIT/BSD/GPL-style notice preservation requirements don't effectively require credit for component developers. Some developers have relied on those holdover legal terms for an imperfect kind of credit. But enforcement has been very lax, and most licensees treat those as bureaucratic compliance burdens, not a call for fair recognition within the practice of software development. Flip through the about pages of computing devices, and you'll notice that credits for developers of the operating system end up on one screen, but copyright notices end up scattered among copies of license terms on a separate "legal notices" screen.

I've written about the mismatch between open source notices requirements and credit expectations here: https://writing.kemitchell.com/2018/08/28/Unhappy-Coincidences.html#attribution-doesnt-mean-credit. It's not just about copyright law rules that no longer apply. It was also, in theory, about making sure contributors are protected from liability if their software misbehaves.

I can't speak for every contributor to the Blue Oak Model license, or for Blue Oak Council as a whole. But my own assessment was that it's really unclear that copyright lines or the like are actually necessary to protect contributors from liability. Since the Blue Oak Model aims to be as permissive as possible while protecting contributors from legal risk, that means dropping the requirement to include specific names. It's also the case that many, many multi-contributor projects under MIT or BSD or the GPL use a category descrition like "Copyright such-and-such project contributors", or just the name of the original developer.

In practice, we no longer rely on distribution artifacts to tell who is behind a project. We work backwards from the artifact to a URL or a Google search that leads to a source repository.

I hope you find this background useful.

from credit-requirement.

Do you think it better to require that credits be given to the audience for the good or service, without any restriction on publishing or sharing from there?

Yes

from credit-requirement.

Alright. I should take a step back from this, let it clear my mind, and return to it later. Probably over the weekend. I've made a note.

from credit-requirement.

@bmintz your comment on credits.txt being specific to web apps was correct. I've addressed that point in 725966e

from credit-requirement.

@bmintz, the motivation for making credits publicly accessible is that credits often get aggregated and used far beyond the immediate audience for the work. For example, film credits appear not just in films, but also in databases like IMDB, which agents and others then use for casting and other hiring decisions.

So even if a limited number of people actually use your Discord bot work, I still think the credit you receive for that work ought to be public and shareable, even by those who don't use work built on yours.

For the access-restricted web-app example, I think the the technical solution there is to respond 200 instead of 401 to GET /credits.txt. But that feels a bit cute.

Do you think it better to require that credits be given to the audience for the good or service, without any restriction on publishing or sharing from there?

from credit-requirement.

@bmintz in reference to the Who to Credit section, you asked whether there are some situations where independent research is required to find out who should be credited. I could see that in situations where users end up receiving binaries, minified source, or bundled source without metadata about contributors. For example, users often received bundled and minified JavaScript packages without package.json data.

My intention in the first draft of the Who to Credit section was to make clear that IF licensees end up receiving credit information in a conventional format, then the licensee can rely on that convention. But if the licensee ends up with software and no credit information, it's up to them to do basic digging, like following a link back to the source repository of the project, to find the information that's been omitted or stripped away.

from credit-requirement.

@bmintz, other than your general feedback, I think just your question about independent research on who to credit is still "open". My last comment on that was here: #1 (comment)

from credit-requirement.

Great!

from credit-requirement.

In practice, we no longer rely on distribution artifacts to tell who is behind a project. We work backwards from the artifact to a URL or a Google search that leads to a source repository.

This actually caused me to reverse course about using the Blue Oak Model License for my own code. Now I think I'm OK with using it! But I would still want to put the name of the project and its contributors in each file, so that people who copy the file would (probably) copy that too.

from credit-requirement.

whether there are some situations where independent research is required to find out who should be credited. I could see that in situations where users end up receiving binaries, minified source, or bundled source without metadata about contributors. For example, users often received bundled and minified JavaScript packages without package.json data.

So, does the Credit Requirement require this independent research be done, in this case? From my reading of it, no, but I'm not sure.

from credit-requirement.

@bmintz if it's not clear, we should make it clear.

from credit-requirement.

Well, from the text in isolation, it's clear. However, your comment seems to contradict the text. Unless you meant "independent research would be required [if the license required credit in this situation]" (emphasis mine).

from credit-requirement.

Fixed in #7. Good job!

from credit-requirement.