Proposal: Require Giving Credit

[kemitchell]

Currently, the free license implementing the “standard deal” for strictEq is basically just a short noncommercial license. It requires keeping copies of the license terms with copies of the software, but doesn’t include a copyright line or any form of personal attribution.

Should the free, paid, or both licenses require giving developers credit when their work is used on other projects?

I’ve done work on a credit-requiring license before. Here’s the latest, just relevant terms:

Credit

You must give this software and each contributor credit for contribution to other work, be they goods or services, that you produce or provide using this software.

How to Credit

In general, you must give credit in such a way that the audience for your work can freely and readily find a written notice identifying this software, by name, as a contribution to your work, as well as each contributor, by name, as a contributor to this software. You must not do anything to stop the audience for your work from sharing, publishing, or using credits.

Conventions

If widespread convention dictates a particular way to give credit for your kind of work, such as by end credit, citation, acknowledgment, or billing, then follow that convention. For software provided in copies to run or install, give credit in documentation and notice files. For software provided as a web service, give credits in credits.txt, according to https://creditstxt.com.

Who to Credit

If this software includes this software’s name and contributor names to credit in a standard way, such as in software package metadata or on an “about” page or screen, you may rely on that information for accuracy and completeness in giving credit. If this software does not include names to credit in a standard way, but includes a link to a webpage for this software, you must investigate that webpage for names to credit. If this software provides neither names to credit nor a software-webpage link, you do not have to perform independent research to find names to credit.

Right to Decline

On written request from a contributor, you must remove their name from any credits you make available for work they do not want to be associated with going forward. On written request from all contributors to this software, you must do the same for the name of this software.

[kemitchell]

I did a license called “Posterity” for Dominic Tarr a while back. I’m not sure if he ever took to it.

I also cooked up a “Credit License” as part of the creditstxt.com project.

I’ve had another look at that drafting work, and am ready to publish a 1.0.0. I’m not sure whether to call it “Posterity” or not. “Vanity” also rhymes, but might be a bit too much fun.

[boris]

Parity, Prosperity, and Posterity.

Posterity is a bit too close to Prosperity, Vanity could fit in this triplet well?

The perfectly workable Credit License is nice too

[kemitchell]

I agree “Posterity” is awful close to “Prosperity”.

“Vanity” is the most fun. At least for my sense of humor.

Do you think “Vanity Public License” is too much? Should I just stick to “Credit License”?

[orlandohill]

I like catchy license names, but Vanity probably sends the wrong message. I don’t consider it vain when someone offers their work for free, with the only condition being that people give credit.

I think requiring credit would increase adoption friction. That might be acceptable for free users. They would effectively pay by giving credit, just as Parity users pay by contributing.

When selling paid licenses, I would want the friction to be as low as possible.

[kemitchell]

@orlandohill

I like catchy license names, but Vanity probably sends the wrong message. I don’t consider it vane when someone offers their work for free, with the only condition being that people give credit.

I really appreciate this feedback! I had a feeling my sense of humor would get me in trouble here…

@orlandohill

I think requiring credit would increase adoption friction. That might be acceptable for free users. They would effectively pay by giving credit, just as Parity users pay by contributing.

When selling paid licenses, I would want the friction to be as low as possible.

Interesting. So the upshot would be to add a credit requirement to the free license, which is mostly for noncommercial uses, but to leave any credit requirement out of the paid license, for paying customers.

I’d also note that back when 99+% of software was distributed and installed, the attribution requirements of common open source permissive licenses often worked as credit requirements, at least within the software industry. Very few people sit around reading notice files, or screen credits for that matter. But a copyright line in a notice file made it so you could list those users on your CV, and people could verify them.

[boringcactus]

@orlandohill

I think requiring credit would increase adoption friction

This depends on what you compare against. If you compare against not using anything, or using something in-house, then yeah, there’s more friction in using a third-party library requiring credit. But if you compare against, say, the MIT License, propagation of the copyright notice is already required, so you’ll need to tuck something into a credits file somewhere anyway.

[boringcactus]

@kemitchell

Do you think “Vanity Public License” is too much?

That name brings to mind something more than just credit:

So a Vanity Public License saying “if your project uses this library, the name of your project needs to include the name of the primary developer of this library” would make sense, and be mildly amusing, but if that is not the license you want to write, then that is probably not the name you should use.

[makkus]

Dunno whether that makes much sense, but how about emphasizing the ‘genealogical’ aspect, where projects build upon and respect their ‘heritage’? ‘Pedigree’ would start with ‘P’, but probably doesn’t hit the mark just right.