Closed ioistired closed 5 years ago
@bmintz your comment on credits.txt
being specific to web apps was correct. I've addressed that point in 725966e3302b323ff62cbe0fa63623048a1128bb
@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?
@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.
@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.
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
@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: https://github.com/creditstxt/credit-requirement/issues/1#issuecomment-521537522
Great!
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.
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.
@bmintz if it's not clear, we should make it clear.
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).
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.
Fixed in #7. Good job!
Resolved issues have been
crossed out.Specific feedback
"Who to Credit"
This section mentions what to do if the existing credits are complete, and if they are absent. Are there any situations where independent research is needed?
"Software provided as a service" (Conventions)This assumes that all software provided as a service is a website. I've written a few Discord bots, and the convention (for providing source code) there is to provide a command that offers the source, and to link to it from your "about" command. This should be phrased to include such services.
I also think this section could be merged with the "How to Credit" section.
"How to Credit"I'm not fond of this. I was contributing to a discord.py bot library (see the end of this issue) that can only be used by the owner of each bot that uses it. Providing credit to the public at large would be overkill for two reasons:
This "and this software" tripped me up. What is it doing there?
Broad feedbackThis… wasn't what I was really after. To me this seems like a "network copyleft" of attribution, in that any software that indirectly uses software with this exception is now obligated to credit the contributors to that library. I'll tell you a bit about my situation. I wrote this library: https://github.com/bmintz/import-expression-parser with the intention of it being imported by this library: https://github.com/Gorialis/jishaku. The way that most people use jishaku is by simply installing it from
pip
and loading it as an extension into their bot. When I wrote Import Expression Parser, I was reading your blog and used the Charity public license, but eventually went back to the MIT license because I wasn't sure if @Gorialis would accept it if I used a young, unknown license. Today, I might have used the Blue Oak Model License, as I see it like an easy to read Apache 2.0, but I don't like that it doesn't require credit. Were I to use Blue Oak + Credit Requirement for Import Expression Parser, it would definitely not be accepted, since now every user of jishaku would be required to credit me. Meanwhile, as mentioned above, most users of the software cannot use my component of it. So really in my situation I was looking for Blue Oak + the attribution requirements of the MIT license. Something where attribution is only required in copies of the code.Hopefully this makes sense.