5

I have 2 small C programs (each is the inverse of the other) and a common header, <500 lines of code total, and it seems a waste to include a whole license file, so I've just written this comment at the top of all 3 files:

/* © 2020 Lucy Phipps
Do anything
Keep this notice
No warranty */

My question is, do I need more than this from a legal standpoint, especially if I'm planning to reuse it with future projects?

For example, the MIT, BSD and ISC licenses all have a long paragraph in all caps just for the warranty disclaimer, with "as-is" (in quotes) and a list of adjectives for damages that could be caused. Am I reasonably safe without that? The zlib license doesn't include such a paragraph, but it's been called a "crayon license", which is apparently a bad thing?

And in regards to the "keep this notice", does the fact that it's written in the source code itself sufficiently imply that I only want the copyright to be in the source and don't mind so much about binary copies, or should I say it explicitly so people don't have to pull the license out of my code and put it in a .txt file for distributions?

Also the programs themselves are simple wrappers for 2 existing libraries, zlib licensed and BSD 3-clause licensed respectively.

To summarize: basically I want something equivalent to the 1-clause BSD license but in as few characters as possible.

Update: https://github.com/landfillbaby/licenses copyright isn't real

4
  • 11
    The big advantage of using existing licenses is that the recipient can often treat it as a tick-box item. "Oh, another MIT license. Easy". Your license may appear simpler, but it's different and requires a separate legal analysis. That makes it harder to use, not easier, despite the simplicity. Your desire for a low character count is counterproductive. Lawyers are a lot more expensive than disk storage. – MSalters Dec 8 '20 at 14:10
  • If that's the case I guess I should go for the zlib license, since it's short, it doesn't have a whole liability paragraph in all caps, and it only needs the license in the source like I want. It has the "plainly marked edits" clause which I don't really need, but again without that long loud paragraph it's still shorter. – landfill baby Dec 8 '20 at 14:16
  • BSD-x is more wide-spread known and recognized than the zlib license - as such it would IMHO be the better choice. Why care about the no-liability being inall-caps? It's just legalese for "take it or leave it, I don't care, but please also don't complain to me" – planetmaker Dec 8 '20 at 15:19
  • how about just ISC? i guess? – landfill baby Dec 8 '20 at 16:46
8

The comments hit on a lot of these points, but let me try to provide a more comprehensive response.

Unless you have a strong reason to do so (and character count of your file header comments is not a strong reason), you should stick with one of the well-known software licenses. Your header just needs to mention the license that it is covered under and you include the license text as an additional file. This will actually reduce your overall header character count.

There are two main reasons to do this: ease of use and ensuring your bases are covered.

Ease of Use

Sticking with a well-known open source license will make it easier for organizations to use your open source software.

This is because some organizations may only permit development teams from choosing to use open source dependencies that have a pre-approved well-known license. While there's usually a step out process that they could potentially follow to get approval to use software with a custom license, most developers will simply look for an alternative library that has a license that meets their needs.

Organizations make these decisions because it's best practice when preparing to release a piece of software to do a full review of any 3rd party dependencies to ensure license and export compliance. Corner cases like custom licenses may require their legal department's involvement in this process, and it is complex and time consuming for the legal department to understand a wide variety of software licenses and their potential interactions with each other. So pre-approved lists of software licenses are born out of a need for efficiency.

Covering Your Bases

This is similar to the recommendation to never roll your own crypto: there are simply too many intellectual property complexities for the average person to get it right if they roll their own license. Getting it wrong may expose you or users of your code to unexpected liability.

Intellectual property rights are complex and vary from country to country. The well-known licenses have benefited from scrutiny from legal minds in many countries and have clauses that are carefully designed to convey the rights you want to convey while protecting against a whole host of issues that you may not have ever even heard of.

As an example, one of the more subtle issues is moral rights. I always struggle with moral rights, but it's one of the whole reasons why licenses exist that do what you're trying to do rather than people just putting code out in the public domain. I think this answer does a good job of explaining the idea: https://opensource.stackexchange.com/a/9873/18378. The TL,DR version is that people may not be able to grant some of the rights they think they are granting so good open source licenses include additional language to work around this as best as is possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.