It's inefficient if your assumptions about the audience are wrong. If you know your audience, sarcasm is highly effective, high-density mode of communication.
A. The other licenses include very explicit copyright grants. Copyright is a bundle of rights. Literally. The other licenses are explicitly mentioning what copyright rights you get and what you can do with them.
You aren't.
This opens the world up to fun arguments over what "Do whatever you like meant", with one side arguing that "no, i didn't mean the right to publicly perform" and the other side arguing it does.
It may seem like this would never happen, but trust me when i tell you this is what will happen (and in fact, it has actually happened out of court) :)
Unlike BSD/etc, it also makes things like "the scope of any implied patent grant" super unclear.
Without specifying exactly what the user can do with it, it's unclear what patent rights they are going to get with it.
2. It has no warranty disclaimer. In the US, you are opening up anyone who uses this license and produces commercial software to implied warranty claims. They happen. Without a disclaimer, you will lose.
I could go on. WTFPL is actually one of the few licenses the companies I work for ban, because it is so bad for people in practice.
I would love to live in a utopia where nobody should have to worry about these things and i could forget about the open source lawyer side of my life (and i spent a lot of my life trying to help get us there). But we aren't there, and acting like we are isn't going to help anyone, and doesn't advance any cause, either.
So, please, don't create new licenses, and if you are, take the time to understand why people have written existing licenses the way they have.
If you would like a non-copyleft free software license consider using the ISC license. It removes language not required by modern laws. It's the preferred license for the OpenBSD project.
Here it is:
Copyright (c) Year(s), Company or Person's Name <E-mail address>
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
I believe the "/or" was added after it was submitted the OSI and FSF, because they felt that it could be misinterpreted without. However it appears that OpenBSD didn't change their version (probably because they don't believe it's ambiguous).
Though, just a language simplification of the MIT License. (not that that is bad). However it is not as permissive as the 1-clause BSD spelled out in the article, since it still requires copyright notice in binary distribution. The Boost license is one of the licenses I remember to be in effect the same as that 1-clause BSD license. Which is nice since you can use the Boost header-only libraries without having to consider where you going to credit them, much like any standard library in most languages.
> it still requires copyright notice in binary distribution.
Really? I thought MIT/ISC just meant one can't remove that notice when redistributing the source. Is one supposed to do something particular with binaries as well?
The MIT license says: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
Typically, "Software" means also binaries [1]. The MIT license text is usually included in the software documentation or about box. If you are not sure where to put it, then ask the open source project owners how to attribute them.
That is the "warranty" section of the license. Most software contracts as a standard have the warranty section in all caps. Source - I sell a database and deal with software contracts on a weekly basis.
It doesn't have to be capitalized. US law (and probably some other places) requires key parts of a contract to be 'conspicuous' i.e. well read and not missed.
CAPS LOCK NEAR THE BEGINNING OF THE CONTRACT seems to be a convention (in the US) [for making things 'conspicuous'] where something as revolutionary such as bullet points may not be.
This is not global convention (for making things 'conspicuous') and seems peculiar to the US.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS... and continued
I think you're right. Even just writing a readme that says "you can use this software for X" is effectively a claim that it's fit for a given purpose, which I guess might open you up to damages claims.
But I agree with trying to get rid of cruft from OS licences. I think the ISC one seems like the best balance.
The 1-Clause BSD License seems to be similar to the Boost Software License (http://opensource.org/licenses/BSL-1.0). I think it's a pretty good fit for foundation libraries.
If you were going to design an optimal protocol from scratch today, you would not make TCP/IP or HTTP (check the Referer header [0]) or lots of other things. But we all use them to maximize interoperability.
For the same reason, you should almost certainly be using the MIT, Apache, or GPL license to maximize the chance that your open source software can actually be used by others. If you don't use a well known license, very few will invest in the lawyer's time necessary to evaluate your custom license. (See the problems caused by the tongue-in-cheek JSON license: http://tanguy.ortolo.eu/blog/article46/json-license )
Use the dominant license for your project (e.g., MIT for Ruby Gems). For new projects, I recommend http://choosealicense.com to pick a license.
It is certainly not a minimalist approach, but I see a lot of people discussing the various potential holes in the minimalist licenses anyway - what about the Apache Software License 2.0? It's longer, but that's precisely because lawyers have filled in a bunch of the ambiguities. In my opinion, it's a more robust implementation of the spirit with which the BSD licenses were written.
I don't understand the purpose of these extreme licenses. If you don't want to restrict the usage of your software in any way, why not place it in the public domain?
As I understand it, the point of owning something is to restrict what others can do with it. Some people want that. For example, some people choose to own the software they write so they can license it under the GPL. They want restrict my freedom to limit what others can do with any modifications I might make. If that's what they want, then retaining ownership makes sense.
If you _really_ don't want to restrict others in any way, why maintain ownership? Why take on the risk of liability, or go to the bother of disclaiming it? It's software, so giving it to the public won't deprive you of its use.
But then, I am not a lawyer. Am I wrong? Are there downsides?
Dedicating a work to the public domain is legally very ambiguous and varies globally; Some jurisdictions do not allow a creator to relinquish their moral rights. Permissive licenses are simply a way of unambiguously stating that a work may be used freely. Permissive licenses also provide important protections to the author, as liability is not necessarily waived by relinquishing a claim to copyright.
As the Zen of Python says, explicit is better than implicit.
41 comments
[ 4.0 ms ] story [ 96.8 ms ] threadWhat everyone should do is choose a license.
A. The other licenses include very explicit copyright grants. Copyright is a bundle of rights. Literally. The other licenses are explicitly mentioning what copyright rights you get and what you can do with them.
You aren't.
This opens the world up to fun arguments over what "Do whatever you like meant", with one side arguing that "no, i didn't mean the right to publicly perform" and the other side arguing it does.
It may seem like this would never happen, but trust me when i tell you this is what will happen (and in fact, it has actually happened out of court) :)
Unlike BSD/etc, it also makes things like "the scope of any implied patent grant" super unclear. Without specifying exactly what the user can do with it, it's unclear what patent rights they are going to get with it.
2. It has no warranty disclaimer. In the US, you are opening up anyone who uses this license and produces commercial software to implied warranty claims. They happen. Without a disclaimer, you will lose.
I could go on. WTFPL is actually one of the few licenses the companies I work for ban, because it is so bad for people in practice.
I would love to live in a utopia where nobody should have to worry about these things and i could forget about the open source lawyer side of my life (and i spent a lot of my life trying to help get us there). But we aren't there, and acting like we are isn't going to help anyone, and doesn't advance any cause, either.
So, please, don't create new licenses, and if you are, take the time to understand why people have written existing licenses the way they have.
Here it is:
Copyright (c) Year(s), Company or Person's Name <E-mail address>
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Really? I thought MIT/ISC just meant one can't remove that notice when redistributing the source. Is one supposed to do something particular with binaries as well?
Typically, "Software" means also binaries [1]. The MIT license text is usually included in the software documentation or about box. If you are not sure where to put it, then ask the open source project owners how to attribute them.
[1] http://stackoverflow.com/a/10681216
CAPS LOCK NEAR THE BEGINNING OF THE CONTRACT seems to be a convention (in the US) [for making things 'conspicuous'] where something as revolutionary such as bullet points may not be.
This is not global convention (for making things 'conspicuous') and seems peculiar to the US.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS... and continued
is incredibly important.
But I agree with trying to get rid of cruft from OS licences. I think the ISC one seems like the best balance.
[1] -http://opensource.org/licenses/BSD-2-Clause
http://www.hklaw.com/digitaltechblog/The-UCC-and-Software-Co...
It looks like it ends up being decided on whether or not the software is a good (covered by a warranty) or a service.
For the same reason, you should almost certainly be using the MIT, Apache, or GPL license to maximize the chance that your open source software can actually be used by others. If you don't use a well known license, very few will invest in the lawyer's time necessary to evaluate your custom license. (See the problems caused by the tongue-in-cheek JSON license: http://tanguy.ortolo.eu/blog/article46/json-license )
Use the dominant license for your project (e.g., MIT for Ruby Gems). For new projects, I recommend http://choosealicense.com to pick a license.
[0] https://en.m.wikipedia.org/wiki/HTTP_referer
As I understand it, the point of owning something is to restrict what others can do with it. Some people want that. For example, some people choose to own the software they write so they can license it under the GPL. They want restrict my freedom to limit what others can do with any modifications I might make. If that's what they want, then retaining ownership makes sense.
If you _really_ don't want to restrict others in any way, why maintain ownership? Why take on the risk of liability, or go to the bother of disclaiming it? It's software, so giving it to the public won't deprive you of its use.
But then, I am not a lawyer. Am I wrong? Are there downsides?
Anyway: CC0, WTFPL and Unlicense are indeed gaining popularity.
As the Zen of Python says, explicit is better than implicit.