The MIT License, Line by Line(writing.kemitchell.com)
writing.kemitchell.com
The MIT License, Line by Line
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html
147 comments
I doubt there's any single answer that isn't tautological. In other kinds of development, like embedded programming, notice files are a part of the cycle. Web developers simply haven't developed the habit.
Which is a real head scratcher, because as a rule, JavaScript developers use JavaScript package managers, and JavaScript package managers, especially npm, provide good license metadata and auditability. You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you, no many how many direct and transitive dependencies you have.
I think there's also a chicken-and-egg problem, in that it's not exactly clear how to make the notices file for front-end code available. Link from website footer? At the top of the client bundle? Comment at the top of the client bundle, with a URL for the notices files?
Which is a real head scratcher, because as a rule, JavaScript developers use JavaScript package managers, and JavaScript package managers, especially npm, provide good license metadata and auditability. You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you, no many how many direct and transitive dependencies you have.
I think there's also a chicken-and-egg problem, in that it's not exactly clear how to make the notices file for front-end code available. Link from website footer? At the top of the client bundle? Comment at the top of the client bundle, with a URL for the notices files?
I've seen at least some minified/bundled JS files that neatly preserved the copyright notices for each minified blob they included.
Minifiers and obfuscators are one reason newer licenses like MPLv2 don't require minified JavaScript to carry attribution and copyright notices.
MPLv2 does require you to inform the recipient that the software is under MPLv2 and where to find the source code for it.
Yes, but not necessarily as part of the minified code.
> Q16: Is "minified" JavaScript Source Code?
> No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.
> This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.
> Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.
Ref: https://www.mozilla.org/en-US/MPL/2.0/FAQ/
> Q16: Is "minified" JavaScript Source Code?
> No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.
> This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.
> Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.
Ref: https://www.mozilla.org/en-US/MPL/2.0/FAQ/
> You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you,
I think the tl;dr is that this is feasible but not common, and there's no single widely-used default way of doing it.
E.g. Many packages put their copyright/license info in special inline comments (using /! ... / tags), and every minifier I've used keeps such tags by default. But including these tags in your bundles can be undesirable - if a dependency has: /! Copyright foo@bar / without specifying the package name, then your bundle will appear to be entirely (c) that author.
OTOH the huge majority of projects do include a valid license identifier in a package.json tag (since npm complains if you don't). But I don't think there's any widely-used default way of generating a good licenses declaration from them.
I think the tl;dr is that this is feasible but not common, and there's no single widely-used default way of doing it.
E.g. Many packages put their copyright/license info in special inline comments (using /! ... / tags), and every minifier I've used keeps such tags by default. But including these tags in your bundles can be undesirable - if a dependency has: /! Copyright foo@bar / without specifying the package name, then your bundle will appear to be entirely (c) that author.
OTOH the huge majority of projects do include a valid license identifier in a package.json tag (since npm complains if you don't). But I don't think there's any widely-used default way of generating a good licenses declaration from them.
I'm not following your train of thought here really. Are you saying that people are stripping out the notice from the source code as a matter of course and then redistributing it?
He's saying that if you depend on A and A depends on B and they're both MIT licensed then technically you should include the licenses for A and B on your site, but most people only include A.
Surely the MIT license only mentions leaving the notice intact, It doesn't say anything about including the notice on your website.
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
If you are using some js library with the MIT license in your frontend then you are distributing a copy of the software. You have to include the notice somewhere on your website (typically next to the library)
If you are using some js library with the MIT license in your frontend then you are distributing a copy of the software. You have to include the notice somewhere on your website (typically next to the library)
People viewing your website don't get a copy of the software, nor do they get a substantial portion. The MIT license (like most licenses) applies to the code, not to what that code produces.
If people are downloading the source, and executing that code, eg as parent said "frontend", then yes, it's on their computer. It's not server side, such as with PH, or python or backend js.
However, the license doesn't have to appear on the website portion specifically highlighted for human viewing. It merely needs to exist, say, at the top of every javascript file.
Or a link to where the text form of the license is.
Just because it's inconvenient, and just because people are ignoring it, doesn't mean it's being done as it should be...
However, the license doesn't have to appear on the website portion specifically highlighted for human viewing. It merely needs to exist, say, at the top of every javascript file.
Or a link to where the text form of the license is.
Just because it's inconvenient, and just because people are ignoring it, doesn't mean it's being done as it should be...
My point is that if you install the code through a dependency of a dependency it should be leaving license notices entirely intact, fulfilling the license.
Of course javascript optimizers and the like might throw a wrench in the works these days, but that's a pretty recent and specific problem.
Of course javascript optimizers and the like might throw a wrench in the works these days, but that's a pretty recent and specific problem.
Is that minification?
I thought minifiers were supposed to keep licenses (they can detect the license header). I suppose this could get turned off or messed up by accident with the gigantic custom webpack bundlers even stuff like create-react-app ship with.
Lots of libraries don't put the license in the header, only in a separate LICENSE file.
I've looked at Webpack's output before, and I don't recall seeing any headers there.
Webpack definitely keeps the license headers even when minification is on. They have to start with something like "@license".
Are their product/business owners aware of the legal obligations that their developers are signing them up for? Do the developers actually have the authority to enter into these licences?
Webpack keeps the licenses when outputting bundles. Given the popularity of this tool a lot of people are respecting the attribution clause.
Why is there ''and/or'' in the MIT license text? Why is it needed?
Does the phrase ''this permission notice'' cover the following disclaimer?
Also, what is the shortest possible license that is functionally equivalent to the MIT license?
The shortest ''license'' I've ever seen is this: https://git.suckless.org/dmenu/file/arg.h.html
Does the phrase ''this permission notice'' cover the following disclaimer?
Also, what is the shortest possible license that is functionally equivalent to the MIT license?
The shortest ''license'' I've ever seen is this: https://git.suckless.org/dmenu/file/arg.h.html
/*
* Copy me if you can.
* by 20h
*/
I use a minimal version of the ISC/OpenBSD license.
- I don't know of anything in the Berne Convention or Title 17, U.S. Code, that would require the phrase "with or without fee" so I remove it.
- I use "work" instead of "software." There's no reason to be over-specific.
- I treat the entire text as one notice, rather than specifying each paragraph separately.
- I don't know of anything in the Berne Convention or Title 17, U.S. Code, that would require the phrase "with or without fee" so I remove it.
- I use "work" instead of "software." There's no reason to be over-specific.
- I treat the entire text as one notice, rather than specifying each paragraph separately.
Copyright (c) 2021, MyOrganization
THIS WORK IS PROVIDED "AS IS," WITH NO EXPRESS OR IMPLIED WARRANTIES. THERE
IS NO WARRANTY OF MERCHANTABILITY, FITNESS, NON-INFRINGEMENT, OR TITLE.
NO AUTHOR SHALL BE LIABLE FOR ANY DAMAGES RELATING TO USE OF THIS WORK.
Permission to use, copy, modify, and/or distribute this work for any purpose
is hereby granted, provided this notice appears in all copies.> provided this notice appears in all copies.
A derivative isn't generally a copy. Which is one of the weaknesses of the ISC license that doesn't appear in either the N-Clause BSD licenses or the MIT license.
Because of the poor wording, permission is granted, but the notice is only required on things considered to be copies, rather than all the "children" of the original work.
You really want something like:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the work.
A derivative isn't generally a copy. Which is one of the weaknesses of the ISC license that doesn't appear in either the N-Clause BSD licenses or the MIT license.
Because of the poor wording, permission is granted, but the notice is only required on things considered to be copies, rather than all the "children" of the original work.
You really want something like:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the work.
You seem to be claiming that modified copies and partial copies are not copies for the purpose of copyright law. Do you have any case law to support that position?
See Ford Motor Co. v. Summit Motor Products, Inc., 930 F.2d 277, 291 (3d Cir. 1991), cert. denied 502 U.S. 939 (1991); Madrid v. Chronicle Books, Pixar, 209 F. Supp. 2d 1227, 1237 n. 5 (D. Wyo. 2002); Micro Consulting, Inc. v. Zubeldia, 813 F. Supp. 1514, 1531 (W.D.Okla. 1990)("a derivative work does not [implicate the underlying copyright] unless it has been substantially copied from the preexisting work" (emphasis added)).
See Ford Motor Co. v. Summit Motor Products, Inc., 930 F.2d 277, 291 (3d Cir. 1991), cert. denied 502 U.S. 939 (1991); Madrid v. Chronicle Books, Pixar, 209 F. Supp. 2d 1227, 1237 n. 5 (D. Wyo. 2002); Micro Consulting, Inc. v. Zubeldia, 813 F. Supp. 1514, 1531 (W.D.Okla. 1990)("a derivative work does not [implicate the underlying copyright] unless it has been substantially copied from the preexisting work" (emphasis added)).
"substantially" is the keyword that should have been emphasised there, and is actually in my post in the above and the wording that was used.
This is because when it comes to copyright law there _is_ such a thing as something being too insubstantial to be considered copyright infringement. "de minimis" falls under fair use.
> You seem to be claiming that modified copies and partial copies are not copies for the purpose of copyright law.
Lets break it down a little bit more clearly:
> Permission to use, copy, modify, and/or distribute this work for any purpose is hereby granted, provided this notice appears in all copies.
+ You are granted the permission to modify.
+ You must provide the notice in all copies.
If a work is substantially modified from the original, such that it constitutes a new work, it would no longer be considered a copy of the original, which is why you are now granted copyright on the new work at all:
> "Unless sufficient of the pre-existing work is contained in the later work so as to constitute the latter an infringement of the former, the latter by definition is not a derivative work." 2 Nimmer on Copyright § 8.09[A], p. 8-138 (2004); see Litchfield v.Spielberg
If you arrive at this point, where you are no longer a derivative because of the substantial divergence from the original work, it may no longer be considered a copy under copyright law.
For a random example from software, the source code for "alpine" the mail client, and "nano" the text editor have an undisputed shared origin, but arguing that they share substantial similarities today would actually be a difficult case to present.
The permission to modify has allowed you to create this new work, but you are no longer required to show the notice, because what you have is no longer a copy.
Whereas the wording in license such as the 3-Clause BSD license:
> 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Do not allow you to differentiate between a new work and a copy, and close shut that particular escape hatch.
This is because when it comes to copyright law there _is_ such a thing as something being too insubstantial to be considered copyright infringement. "de minimis" falls under fair use.
> You seem to be claiming that modified copies and partial copies are not copies for the purpose of copyright law.
Lets break it down a little bit more clearly:
> Permission to use, copy, modify, and/or distribute this work for any purpose is hereby granted, provided this notice appears in all copies.
+ You are granted the permission to modify.
+ You must provide the notice in all copies.
If a work is substantially modified from the original, such that it constitutes a new work, it would no longer be considered a copy of the original, which is why you are now granted copyright on the new work at all:
> "Unless sufficient of the pre-existing work is contained in the later work so as to constitute the latter an infringement of the former, the latter by definition is not a derivative work." 2 Nimmer on Copyright § 8.09[A], p. 8-138 (2004); see Litchfield v.Spielberg
If you arrive at this point, where you are no longer a derivative because of the substantial divergence from the original work, it may no longer be considered a copy under copyright law.
For a random example from software, the source code for "alpine" the mail client, and "nano" the text editor have an undisputed shared origin, but arguing that they share substantial similarities today would actually be a difficult case to present.
The permission to modify has allowed you to create this new work, but you are no longer required to show the notice, because what you have is no longer a copy.
Whereas the wording in license such as the 3-Clause BSD license:
> 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Do not allow you to differentiate between a new work and a copy, and close shut that particular escape hatch.
So... no then.
And if it is "no longer a derivative because of the substantial divergence from the original work" -- the situation where you have a problem with the ISC language -- then what right under 17 U.S.C. § 106 is implicated?
You can't have it both ways. Under situations involving copies of my work, the ISC license works fine. Under situations not involving copies of any my work within the meaning of copyright law, then copyright law has no applicability.
And if it is "no longer a derivative because of the substantial divergence from the original work" -- the situation where you have a problem with the ISC language -- then what right under 17 U.S.C. § 106 is implicated?
You can't have it both ways. Under situations involving copies of my work, the ISC license works fine. Under situations not involving copies of any my work within the meaning of copyright law, then copyright law has no applicability.
> Why is there ''and/or'' in the MIT license text? Why is it needed?
It's a stupid lawyer thing. A lot of us still write like this. I'm sorry.
> Does the phrase ''this permission notice'' cover the following disclaimer?
Arguable, but why would anyone bother chopping off the disclaimer?
> Also, what is the shortest possible license that is functionally equivalent to the MIT license?
Form and function aren't so neatly separated in natural language.
> Is this really a license?
It's a cute suckless thing. They're edgy like that, among other ways.
> What about the SQLite blessing?
SQLite holds their work out as in the public domain. But you can buy a license (and some commercial guarantees) to make your company's lawyers happy: https://sqlite.org/purchase/license
It's a stupid lawyer thing. A lot of us still write like this. I'm sorry.
> Does the phrase ''this permission notice'' cover the following disclaimer?
Arguable, but why would anyone bother chopping off the disclaimer?
> Also, what is the shortest possible license that is functionally equivalent to the MIT license?
Form and function aren't so neatly separated in natural language.
> Is this really a license?
It's a cute suckless thing. They're edgy like that, among other ways.
> What about the SQLite blessing?
SQLite holds their work out as in the public domain. But you can buy a license (and some commercial guarantees) to make your company's lawyers happy: https://sqlite.org/purchase/license
Another stupid question: under what terms the licenses themselves are licensed? It is very clear in the Blue Oak Model license page. But what about all of these licenses like MIT, ISC, BSDs etc.?
Last question, how much change in the software allowes me to add my name and where to add it, before or after original author(s)?
Last question, how much change in the software allowes me to add my name and where to add it, before or after original author(s)?
The "and" means include and the "or" means optional. It needed because it basically states your rights on what you can do with the software and means you can distribute if you choose to distribute the software, it your choice or right to distribute the software (from the MIT License).
The phrase "this permission notice" also cover the "NO WARRANTY" disclaimer for the software because you will have to include the license if you use it in another software but you can provide warranty under a close source license or your license states you will provide warranties. The "copyright notice" and "this permission notice" means the license.
The shortest possible license that is functionally equivalent to the MIT license is the ISC license, it was created to remove language that is not needed. Read the Wikipedia article here https://en.wikipedia.org/wiki/ISC_license. I do not know other licenses than this.
Technically it is a license but do not use it and it is just probably a joke. The SQL Blessing is technically probably a Public Domain waver.
This is not legal advice and I am not a lawyer.
The phrase "this permission notice" also cover the "NO WARRANTY" disclaimer for the software because you will have to include the license if you use it in another software but you can provide warranty under a close source license or your license states you will provide warranties. The "copyright notice" and "this permission notice" means the license.
The shortest possible license that is functionally equivalent to the MIT license is the ISC license, it was created to remove language that is not needed. Read the Wikipedia article here https://en.wikipedia.org/wiki/ISC_license. I do not know other licenses than this.
Technically it is a license but do not use it and it is just probably a joke. The SQL Blessing is technically probably a Public Domain waver.
This is not legal advice and I am not a lawyer.
Probably to clarify against exclusive or?
Does anyone know of a similar breakdown for licences like GPL v2 and the like? It's a part of programming I feel like I should know more about but never took the time to look at.
Linked on the first line of the article:
https://writing.kemitchell.com/series/line-by-line.html
https://writing.kemitchell.com/series/line-by-line.html
Contains a post about the AGPL, which specifically does not go into detail about the GPL but just the difference between them.
Not super helpful
Not super helpful
Needs a new edition but comprehensive enough for GPLv2: https://www.oreilly.com/library/view/understanding-open-sour...
There you go http://richardbestlaw.com/download/734/
It's called "A Practical Guide to WordPress and the GPL" and I must admit, it's easy to understand.
It's called "A Practical Guide to WordPress and the GPL" and I must admit, it's easy to understand.
> The implied warranty of “merchantability” under UCC section 2-314 is a promise that “the goods”—the Software—are of at least average quality, properly packaged and labeled, and fit for the ordinary purposes they are intended to serve.
So, all goods have an implied warranty requiring they must be of at least average quality? How does that work? Does average have a different meeting in a legal context?
So, all goods have an implied warranty requiring they must be of at least average quality? How does that work? Does average have a different meeting in a legal context?
Suppose I sell you an oil filter for your 2019 Mazda. When you get it home, you realize there's a big hole in it, and it can't be used to replace the one currently on your car.
You call me up and I say "I never said it would work in a car, I just said it was an oil filter (true) which would fit into a 2019 Mazda (true)."
The law says "nice try, you can't be that pedantic. The ordinary purpose of oil filters it to actually filter oil in a car, so when you sold it, there was an understanding that it would work for that purpose."
You call me up and I say "I never said it would work in a car, I just said it was an oil filter (true) which would fit into a 2019 Mazda (true)."
The law says "nice try, you can't be that pedantic. The ordinary purpose of oil filters it to actually filter oil in a car, so when you sold it, there was an understanding that it would work for that purpose."
Your example doesn't highlight something important about this though: they explicitly disclaim the "implied" warranty of merchantability in addition to disclaiming all warranties in general. In other words, that means that in your example, you hadn't merely declined to say it works in a car, but you had in fact already said "I guarantee NOTHING about this oil filter; it comes with absolutely NO WARRANTIES", and yet someone would've still called you up and said "despite all your disclaimers you still have an implied warranty because you didn't disclaim it explicitly"... which is far less obvious than what you wrote.
What if the oil filter doesn't have a hole in it, but just has 10,000 miles on it so it doesn't work well anymore. Would selling that be ok? What about a filter with 9,000 miles, or 5,000 miles, or 1,000 miles? Who decides what the cutoff is?
> Who decides what the cutoff is?
ultimately, a judge.
ultimately, a judge.
This is where technical people hit a wall with the law.
Many legal systems, especially the American one, aren’t based on strict enumerable lists of what my lawyer friends would call “bright line tests”.
This is probably a good thing, all in all.
Many legal systems, especially the American one, aren’t based on strict enumerable lists of what my lawyer friends would call “bright line tests”.
This is probably a good thing, all in all.
I have had this discussion (argument) with so many software engineers and pilots who think they found a loophole. If someone in power thinks you broke the law, you don’t have to explain yourself to a law interpreter. It’s a human being on the other side of that table. And they can be just as clever and capricious as you. Most bodies of law also have a catch-all (I like to call it “fuck you”) clause to cover whatever shenanigans you try that they haven’t yet enumerated. 14 CFR 91.13 comes to mind.
Also, check out my new cryptocurrency that skirts all SEC laws. http://orangegrovecoin.com
Also, check out my new cryptocurrency that skirts all SEC laws. http://orangegrovecoin.com
Indeed. And things don’t go to court if they’re obvious. The whole point of going to court is to resolve conflicts that don’t have obvious answers. (Or where the more powerful party is being stubbornly wrong, but that’s a separate issue.)
That's because the world is too complex and nuanced for such strict cutoffs to be stipulated in law. Just the number of products on the market is huge and changes all the time.
The law therefore specifies things in general terms and uses 'reasonableness', or "fitness for purpose", or what would be expected by an "average bystander" (in English law), etc. in the same way this piece of legislation does.
This allows courts and juries to then make a judgement on the infinite number of particular cases that get before them.
The law therefore specifies things in general terms and uses 'reasonableness', or "fitness for purpose", or what would be expected by an "average bystander" (in English law), etc. in the same way this piece of legislation does.
This allows courts and juries to then make a judgement on the infinite number of particular cases that get before them.
The article doesn't really get it right. This is what the UCC actually says:
(2) Goods to be merchantable must be at least such as: (a) Pass without objection in the trade under the contract description; and (b) In the case of fungible goods, are of fair average quality within the description; and (c) Are fit for the ordinary purposes for which such goods are used; and (d) Run, within the variations permitted by the agreement, of even kind, quality and quantity within each unit and among all units involved; and (e) Are adequately contained, packaged and labeled as the agreement may require; and (f) Conform to the promises or affirmations of fact made on the container or label if any.
Here is what the official comments to the UCC say:
Paragraphs (a) and (b) of subsection (2) are to be read together. Both refer, as indicated above, to the standards of that line of the trade which fits the transaction and the seller's business. “Fair average” is a term directly appropriate to agricultural bulk products and means goods centering around the middle belt of quality, not the least or the worst that can be understood in the particular trade by the designation, but such as can pass “without objection.” Of course a fair percentage of the least is permissible but the goods are not “fair average” if they are all of the least or worst quality possible under the description. In cases of doubt as to what quality is intended, the price at which a merchant closes a contract is an excellent index of the nature and scope of his obligation under the present section.
So if you understand (a) and (b) in unison, it means that you can't sell someone a lot of goods but then send them all below-average quality units. But, of course, a truck load of apples can still have a "fair percentage" of low-quality apples. Where you're selling a single item, like a computer, then (a) is the better lens of looking at it.
None of this is legal advice. I'm not your lawyer.
(2) Goods to be merchantable must be at least such as: (a) Pass without objection in the trade under the contract description; and (b) In the case of fungible goods, are of fair average quality within the description; and (c) Are fit for the ordinary purposes for which such goods are used; and (d) Run, within the variations permitted by the agreement, of even kind, quality and quantity within each unit and among all units involved; and (e) Are adequately contained, packaged and labeled as the agreement may require; and (f) Conform to the promises or affirmations of fact made on the container or label if any.
Here is what the official comments to the UCC say:
Paragraphs (a) and (b) of subsection (2) are to be read together. Both refer, as indicated above, to the standards of that line of the trade which fits the transaction and the seller's business. “Fair average” is a term directly appropriate to agricultural bulk products and means goods centering around the middle belt of quality, not the least or the worst that can be understood in the particular trade by the designation, but such as can pass “without objection.” Of course a fair percentage of the least is permissible but the goods are not “fair average” if they are all of the least or worst quality possible under the description. In cases of doubt as to what quality is intended, the price at which a merchant closes a contract is an excellent index of the nature and scope of his obligation under the present section.
So if you understand (a) and (b) in unison, it means that you can't sell someone a lot of goods but then send them all below-average quality units. But, of course, a truck load of apples can still have a "fair percentage" of low-quality apples. Where you're selling a single item, like a computer, then (a) is the better lens of looking at it.
None of this is legal advice. I'm not your lawyer.
I paraphrased, because I don't think the nuances matter that much in context. The subject is a broad disclaimer of implied warranties, after all. Quoting the UCC and commentaries would only distract the reader and make the post longer.
In this case, I think it'd be better to leave the "average" language out of it altogether. It doesn't really capture any useful intuitive notion for the reader and instead engenders misunderstanding, as shown by this thread.
Thank you, this clarifies things. If I understand correctly, then, the requirement is that the average of a set of goods sold within a contract must be at least the quality specified by the contract. So it's not really talking about the average overall in a market of that good, it's talking specifically about the average quality of, say, a shipment of goods.
That's almost right.[1] I think an example might help explain the abstract statement in the UCC comments. Say you order a truckload of USDA Choice tenderloin. Meat quality is continuous, so really, USDA Choice refers to a range of quality; some Choice meat is on the lower end, almost Select, and some Choice meat is on the higher end, almost Prime. It would be a breach of the implied warranty of merchantability if the seller sent you a shipment of tenderloin that was all at the low end of the Choice range. Someone in the business of meat would balk at receiving such a shipment, so it wouldn't be the kind of shipment expected to "pass without objection". The quality should roughly center around the average of the designation (USDA Choice) specified in the contract.
These are all default rules, like most of contract law. A particular contract can by its express terms lay down a different rule, such as disclaiming any warranty (as-is) or specifying its own terms of warranty (an express warranty).
[1] What you described is just a straight-up breach of contract, even in the absence of a warranty. If you order USDA Choice meat, a shipment of USDA Select meat is such a breach of contract. In agriculture, and especially outside of meat, some of a shipment will always fall outside of the quality range. This is dealt with in the grading definition. So when you buy USDA Grade AA eggs, that actually means that at least 72% of the eggs are AA, and of the remaining, 10% are at least A and the balance can be B (basically... see https://www.ams.usda.gov/grades-standards/shell-egg-grades-a... ).
These are all default rules, like most of contract law. A particular contract can by its express terms lay down a different rule, such as disclaiming any warranty (as-is) or specifying its own terms of warranty (an express warranty).
[1] What you described is just a straight-up breach of contract, even in the absence of a warranty. If you order USDA Choice meat, a shipment of USDA Select meat is such a breach of contract. In agriculture, and especially outside of meat, some of a shipment will always fall outside of the quality range. This is dealt with in the grading definition. So when you buy USDA Grade AA eggs, that actually means that at least 72% of the eggs are AA, and of the remaining, 10% are at least A and the balance can be B (basically... see https://www.ams.usda.gov/grades-standards/shell-egg-grades-a... ).
We’re in English class, not math class. Forget statistics. There is a sense of the word “average” that means “not out of the ordinary; common.” That’s the sense meant here.
Average has exactly the meaning it has in all other contexts. It seems to be a bizarrely common (and obviously incorrect) meme on HN that half of all elements of a set are below average.
GP comment did not imply that half of elements are below average. It just said that _some_ have to be. By definition, we cannot have all elements be above average: at least one has to be below.
> By definition, we cannot have all elements be above average: at least one has to be below.
Ludicrously pedantic nitpick: this only applies to finite sets - consider the sequence 1,1/2,1/3,1/4,... (the harmonic series). The average (mean, median, mode[0]) is (depending on how pedantic you want to be) either 0 or 0+ε[1], but in any case strictly less than any positive real number, while every element of the sequence is a positive real number.
So it's not true by definition; it's a consequence of the basic sanity constraints that you're working with.
0: Strictly speaking mode only applies to continuous ditributions (ie, with a continuous probability density function) or fully discrete distibutions (eg heads vs tails), but 0 is the only (real number) x such that for any sufficiently small positive distance δ, the number of elements in x±δ is strictly greater than the number in x±2δ but not in x±δ (namely, all but a finite number of the inifitely many elements in x±2δ are also in x±δ).
1: Where ε is some surreal number[2] strictly less than any positive real number, but not necessarily 1/ω specifically.
2: https://en.wikipedia.org/wiki/Surreal_number
Ludicrously pedantic nitpick: this only applies to finite sets - consider the sequence 1,1/2,1/3,1/4,... (the harmonic series). The average (mean, median, mode[0]) is (depending on how pedantic you want to be) either 0 or 0+ε[1], but in any case strictly less than any positive real number, while every element of the sequence is a positive real number.
So it's not true by definition; it's a consequence of the basic sanity constraints that you're working with.
0: Strictly speaking mode only applies to continuous ditributions (ie, with a continuous probability density function) or fully discrete distibutions (eg heads vs tails), but 0 is the only (real number) x such that for any sufficiently small positive distance δ, the number of elements in x±δ is strictly greater than the number in x±2δ but not in x±δ (namely, all but a finite number of the inifitely many elements in x±2δ are also in x±δ).
1: Where ε is some surreal number[2] strictly less than any positive real number, but not necessarily 1/ω specifically.
2: https://en.wikipedia.org/wiki/Surreal_number
The average (median, mode, rounded mean) package of a dozen eggs contains 12 yolks. Occasionally there are 13 or even 14. Some packages intentionally contain 24.
Vanishingly few if any contain 11 or fewer yolks.
Vanishingly few if any contain 11 or fewer yolks.
With all due respect, you are just trying really hard to be pedantic. Your convoluted, contorted, corner-case example does not invalidate anything that was said here. You even had to resort to the word "rounded" to make it work. Without "rounded", most would be below mean.
> at least one has to be below (average)
this is the pedantic part. Normal usage of average means "pretty much what I expected", which is what they are trying to convey, imo.
this is the pedantic part. Normal usage of average means "pretty much what I expected", which is what they are trying to convey, imo.
I think normally usage, that is non mathematical usage, doesn't mean what I expected, it means the middle of available options, or perhaps the most common option. When applied to quality one would expect that means there is low quality, average quality, and high quality. So I seriously don't know what this means in a legal context.
[deleted]
Buying eggs is not a corner case. But buying 12.1 eggs certainly is. I think you're projecting a little bit here.
In any case, "average" does not mean "arithmetic mean." It means, mathematically, any of the median, mode, or mean or in standard vernacular, of typical or usual characteristics (i.e., close to mode).
You don't get to just arbitrarily pick a definition that fits your viewpoint and start going "all due respect" on other people.
In any case, "average" does not mean "arithmetic mean." It means, mathematically, any of the median, mode, or mean or in standard vernacular, of typical or usual characteristics (i.e., close to mode).
You don't get to just arbitrarily pick a definition that fits your viewpoint and start going "all due respect" on other people.
> It means, mathematically
In this case we're not in a mathematical context though.
In this case we're not in a mathematical context though.
This is wrong. See my other comment. The "average" language in the UCC provision is referring to a specific notion for a particular kind of situation.
[deleted]
>> It seems to be a bizarrely common (and obviously incorrect) meme on HN that half of all elements of a set are below average.
When is that not the case? I'll grant you that not all distributions are "normal" distributions, so when is it not the case that 40 percent are not below average?
When is that not the case? I'll grant you that not all distributions are "normal" distributions, so when is it not the case that 40 percent are not below average?
I gave an example upthread that was downvoted into oblivion. Anything that is standardized, frankly. On average, a Fun Size package of M&Ms contains 17 M&Ms. Many contain 18. Rarely, they contain 19 or 16 or 15. ONLY APPROXIMATELY 20% HAVE FEWER M&MS THAN AVERAGE
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
What’s the reasoning behind asking users to carry around a notice? Why not just let users go without it? Is it for legal reasons or for crediting the authors? I’ve released MIT licensed software before and frankly when someone is using my code, I really don’t care about credit or leaving behind a legacy or such things.
What’s the reasoning behind asking users to carry around a notice? Why not just let users go without it? Is it for legal reasons or for crediting the authors? I’ve released MIT licensed software before and frankly when someone is using my code, I really don’t care about credit or leaving behind a legacy or such things.
You're removing the license in that case, which means downstream users aren't informed that they are direct licensees. It's dishonest.
Additionally, the Berne Convention recognizes a "moral right" to claim authorship.
https://wipolex.wipo.int/en/text/283698
Additionally, the Berne Convention recognizes a "moral right" to claim authorship.
https://wipolex.wipo.int/en/text/283698
This is what I was looking for, thanks for the insight. The way I understand this - if I don't put my authorship, it becomes a liability for the users of my code since they have no traceability of where the code came from. Am I reading this right?
Yeah downstream users wouldn't know that the license text came from someone who can actually license it.
The combination of the copyright and permission notice says
"This is mine AND you can do these things with it if you want."
Claiming ownership by itself does not result in it being open source.
Saying you're giving permissions, but without claiming the right to be able to do so, also does not result in it being open source.
The combination of the copyright and permission notice says
"This is mine AND you can do these things with it if you want."
Claiming ownership by itself does not result in it being open source.
Saying you're giving permissions, but without claiming the right to be able to do so, also does not result in it being open source.
>I really don’t care about credit or leaving behind a legacy or such things.
Then use a different license. In 1-clause BSD and Boost licenses the requirement of preserving copyright notices applies only to source code, while 0BSD and CC0 don't require that at all.
Then use a different license. In 1-clause BSD and Boost licenses the requirement of preserving copyright notices applies only to source code, while 0BSD and CC0 don't require that at all.
Also MIT-0. Note that CC0 is not an OSI-approved license. It was withdrawn because the OSI didn't like that it explicitly does not grant patent rights to use the software.
When I read your comment I initially thought "that can't be right".
And then I found [1]:
> CC0 was not explicitly rejected, but the License Review Committee was unable to reach consensus that it should be approved, and Creative Commons eventually withdrew the application. The most serious of the concerns raised had to do with the effects of clause 4(a), which reads: "No ... patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.". While many open source licenses simply do not mention patents, it is exceedingly rare for open source licenses to explicitly disclaim any conveyance of patent rights, and the Committee felt that approving such a license would set a dangerous precedent, and possibly even weaken patent infringement defenses available to users of software released under CC0.
For the record, the FSF also recommends against using CC0 for software for the exact same reason [2].
I was surprised because my first impression was that this clause does not legally do anything more, anything less than a license that does not explicitly grants the rights to use the related software patents anyway. But I can imagine that without an explicit mention, a judge could still decide that a user receiving a program could reasonably feel allowed to use the related patents from its authors.
Anyway, CC0 should not be used or software indeed I guess, given the vagueness around it.
[1] https://opensource.org/faq#cc-zero
[2] https://www.gnu.org/licenses/license-list.html#CC0
And then I found [1]:
> CC0 was not explicitly rejected, but the License Review Committee was unable to reach consensus that it should be approved, and Creative Commons eventually withdrew the application. The most serious of the concerns raised had to do with the effects of clause 4(a), which reads: "No ... patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.". While many open source licenses simply do not mention patents, it is exceedingly rare for open source licenses to explicitly disclaim any conveyance of patent rights, and the Committee felt that approving such a license would set a dangerous precedent, and possibly even weaken patent infringement defenses available to users of software released under CC0.
For the record, the FSF also recommends against using CC0 for software for the exact same reason [2].
I was surprised because my first impression was that this clause does not legally do anything more, anything less than a license that does not explicitly grants the rights to use the related software patents anyway. But I can imagine that without an explicit mention, a judge could still decide that a user receiving a program could reasonably feel allowed to use the related patents from its authors.
Anyway, CC0 should not be used or software indeed I guess, given the vagueness around it.
[1] https://opensource.org/faq#cc-zero
[2] https://www.gnu.org/licenses/license-list.html#CC0
>I was surprised because my first impression was that this clause does not legally do anything more, anything less than a license that does not explicitly grants the rights to use the related software patents anyway. But I can imagine that without an explicit mention, a judge could still decide that a user receiving a program could reasonably feel allowed to use the related patents from its authors.
Yes, many lawyers believe in implicit patent license: http://en.swpat.org/wiki/Implicit_patent_licence
Yes, many lawyers believe in implicit patent license: http://en.swpat.org/wiki/Implicit_patent_licence
Here's a piece by Scott Peterson (Red Hat legal) that analyzes this with respect to the MIT license specifically: https://opensource.com/article/18/3/patent-grant-mit-license
Thanks. I was wondering which license actually satisfies "Don't care" philosophy and gets me out of any legal responsibility/liability.
There's also this:
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2004 Your Name <[email protected]>
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE FUCK YOU WANT TO.That license doesn't seem to satisfy the parent's requirements:
> gets me out of any legal responsibility/liability
The license you posted doesn't disclaim any warranties or liabilities. I suggest reading what TFA's "Warranty Disclaimer" section says about UCC defaults. The way I read it (IANAL), you would have more liability with the license you posted than you would under the MIT license.
> gets me out of any legal responsibility/liability
The license you posted doesn't disclaim any warranties or liabilities. I suggest reading what TFA's "Warranty Disclaimer" section says about UCC defaults. The way I read it (IANAL), you would have more liability with the license you posted than you would under the MIT license.
It's even worse than that. The longer the text, the stronger it is in court.
That's why contracts like proprietary licenses, buying a house, renting are so verbose.
"do wtf you want" is very unclear from a legal PoV.
That's why contracts like proprietary licenses, buying a house, renting are so verbose.
"do wtf you want" is very unclear from a legal PoV.
Just commit the work to the public domain then.
Not legally possible in many jurisdictions.
Wouldn't you still need language to disclaim warranties and liabilities?
The MIT license was written in the late 1980s.
It was typical for software to be distributed in physical media (floppy disks, and, later, CD-ROMs) through brick-and-mortar retail stores. It was not uncommon for someone to sell physical media with otherwise-free software, and so it was desirable to make end-users aware that the software was available for free. The GPL's "accompany it with a written offer... of the corresponding source code" is also an interesting holdover from this era (nowadays everyone just distributes source over the Internet, instead of sending checks and CDs through the mail).
Copyright notices were also typically visible when you first started a program in the 80s and 90s. These were relegated to "about" menus when it became the norm to "design a launch screen that’s nearly identical to the first screen of your app" to make apps feel faster.
It was typical for software to be distributed in physical media (floppy disks, and, later, CD-ROMs) through brick-and-mortar retail stores. It was not uncommon for someone to sell physical media with otherwise-free software, and so it was desirable to make end-users aware that the software was available for free. The GPL's "accompany it with a written offer... of the corresponding source code" is also an interesting holdover from this era (nowadays everyone just distributes source over the Internet, instead of sending checks and CDs through the mail).
Copyright notices were also typically visible when you first started a program in the 80s and 90s. These were relegated to "about" menus when it became the norm to "design a launch screen that’s nearly identical to the first screen of your app" to make apps feel faster.
Understanding the license in use and the permissions associated with it are important in many contexts. In fact, the MIT license was created in the first place because there were issues associated with just releasing X Windows into the public domain.
FWIW, the 0BSD license omits this line and has been OSI approved.
The MIT No Attribution License (MIT-0) is also OSI approved now which is effectively a public domain license. The caveat is that it won't be an approved license at a lot of companies, both because it's new and because many companies shy away from public domain software.
My understanding is that companies are leery of public domain because it means disclaiming copyright. It looks to me as though with MIT-0 you still retain copyright and are just granting an extremely liberal license?
That may prove to be a distinction without a difference if it's ever tested in court, but "giving up copyright" is scary to management so it's meaningful in practice.
That may prove to be a distinction without a difference if it's ever tested in court, but "giving up copyright" is scary to management so it's meaningful in practice.
IANAL but my understanding is you're pretty much right. The problem is that there is no standard established way to disclaim your rights. And, in continental Europe in particular, it's not totally clear that you can disclaim "moral rights" to something you've created.
A lot of this is mostly theoretical legal stuff but lawyers worry about that sort of thing with the result that a lot of companies won't touch public domain software even if they know its provenance.
A lot of this is mostly theoretical legal stuff but lawyers worry about that sort of thing with the result that a lot of companies won't touch public domain software even if they know its provenance.
The CC0 license and the Unlicense attempt to do this with language to the effect of:
> This work is placed in the public domain.
> In regions where this is not possible, the author grants unlimited license to this work.
Unfortunately, the CC0 explicitly does not waive patent rights, the Unlicense doesn't mention patents at all, the Blue Oak Model License and Apache 2.0 don't attempt to place the work into the public domain, and 0BSD and MIT-0 neither address patents nor attempt to place the work into the public domain. None of these licenses aggressively waive all of the author's rights to their work; I wonder why there isn't a strong public-domain no-patents-or-anything-else license ?
> This work is placed in the public domain.
> In regions where this is not possible, the author grants unlimited license to this work.
Unfortunately, the CC0 explicitly does not waive patent rights, the Unlicense doesn't mention patents at all, the Blue Oak Model License and Apache 2.0 don't attempt to place the work into the public domain, and 0BSD and MIT-0 neither address patents nor attempt to place the work into the public domain. None of these licenses aggressively waive all of the author's rights to their work; I wonder why there isn't a strong public-domain no-patents-or-anything-else license ?
IANAL but I suspect the answer is that it's not clear if you can or how you can "aggressively waive all of the author's rights to their work" at least in some jurisdictions.
What we need is effectively CC0 minus the patent exclusion, plus the patent grant of the Apache License 2.0.
But it really ought to be drafted by professionals, and vetted by the wider community. None of this amateurish "crayon license" foolishness.
Creative Commons probably isn't interested. Their patent language was surely deliberate.
But it really ought to be drafted by professionals, and vetted by the wider community. None of this amateurish "crayon license" foolishness.
Creative Commons probably isn't interested. Their patent language was surely deliberate.
What is the advantage of mentioning patents? I would rather not speak on that so 0BSD and Unlicense are nice.
The theory is presumably that better to explicitly state that you won't assert patent rights against users of the software rather on rely on implicit patent grants. Plenty of IP lawyers are fine with the implicit patent grant in something like the MIT license but there's also a school of thought that, if you intend to grant a right, why not say you are so there's no question for lawyers to debate over.
How is this “inclusion” typically done for a project that is deployed in compiled format and contains hundreds of libraries with dozens of different licenses? It must be especially difficult on devices where it’s difficult to accept user input or display licenses.
In commercial desktop software I have shipped, it has been a section in help>about with a long list of third party libs each showing a text document.
In commercial desktop software I have shipped, it has been a section in help>about with a long list of third party libs each showing a text document.
I downloaded trivy (a go CLI tool) recently and they have some tooling to pack up dependency licenses and include them in the release tarball.
It is possible and quite easy, if you plan ahead. Notably, Debian binary packages include extensive copyright information.
It is possible and quite easy, if you plan ahead. Notably, Debian binary packages include extensive copyright information.
But are licenses only included in e.g a zip with binaries but not available from “within” the software counting as included/available?
For anything distributed as source it’s easy enough.
For anything distributed as source it’s easy enough.
[deleted]
The article gives 3 reasons for the notice requirement right below that quote. Which ones do you disagree with?
This line confused me for a while, because it looked like a copyleft provision to me.
It's not copy left, but users have the right to see the license "tree" if you will of all the things you've built your code with.
I think, as others have pointed out in the replies, 0BSD or MIT-0 is more suitable for me.
I think, as others have pointed out in the replies, 0BSD or MIT-0 is more suitable for me.
> I think, as others have pointed out in the replies, 0BSD or MIT-0 is more suitable for me.
Why not go with [CC0] in that case? It's a lot more robust, and recommended by the FSF over options like the Unlicense.
[CC0] https://creativecommons.org/publicdomain/zero/1.0/
Why not go with [CC0] in that case? It's a lot more robust, and recommended by the FSF over options like the Unlicense.
[CC0] https://creativecommons.org/publicdomain/zero/1.0/
Note that the OSI does not recommend CC0 however because of its patent language. [1] The OSI didn't reject it but the license was withdrawn after it was presumably clear that it would not be approved.
[1] https://opensource.org/faq#cc-zero
[1] https://opensource.org/faq#cc-zero
I can't imagine using CC0 under any circumstances. If you're in the U.S., commit to public domain. If you aren't, then veering way off into contract law instead of copyright law is distinctly unhelpful. There isn't a Berne Convention to cross-level contract law.
One of the main reasons why I find the CC0 attractive is that it can be used, and is widely used, for works other than software. As a result, it seems to have better name recognition, especially outside of programmer circles, and it's nice to be able to use a single legal text for software that also contains images, audio, or similar assets. (Slapping software licenses onto media files impedes their re-use outside the context of that particular software project.)
Is there an alternative you'd recommend?
Is there an alternative you'd recommend?
Where is the FSF recommendation? And did they only consider unlicense?
Is requiring attribution copyleft? I thought copyleft implied needing to make source code available.
Just needing attribution is not copyleft, you are giving credit to the original author. Share-Alike or using the same license to make source code available like GPL is copyleft.
Great article, similar to a blog post I did recently.
This is a minor nitpick and shouldn't be read as an overall criticism of the author or this post, which is better than the one I did. However, I will note that non-infringement and title are, in fact, implied warranties in the UCC. I'm not sure why the author missed it.
https://www.law.cornell.edu/ucc/2/2-312
This is a minor nitpick and shouldn't be read as an overall criticism of the author or this post, which is better than the one I did. However, I will note that non-infringement and title are, in fact, implied warranties in the UCC. I'm not sure why the author missed it.
https://www.law.cornell.edu/ucc/2/2-312
Minor correction: Under UCC § 2-312(3) (link in parent), non-infringement is an implied warranty only if the seller is a "merchant," i.e., one who regularly deals in goods of the kind.
The implied warranty of noninfringement can be disclaimed under § 2-316, and vendors almost universally do so (preferring to make specific express warranties instead when they perceive a market need).
https://www.law.cornell.edu/ucc/2/2-316
The implied warranty of noninfringement can be disclaimed under § 2-316, and vendors almost universally do so (preferring to make specific express warranties instead when they perceive a market need).
https://www.law.cornell.edu/ucc/2/2-316
[deleted]
Hiya, DC. Glad to see your name here. :-D
The UCC nerds are out in force this round!
The UCC nerds are out in force this round!
[deleted]
> Lastly, as a result of this mishmash of legal, industry, general-intellectual-property, and general-use terms, it isn’t clear whether The MIT License includes a patent license. The general language “deal in” and some of the example verbs, especially “use”, point toward a patent license, albeit a very unclear one.
I think this is a very carefully couched way of saying "the MIT license doesn't protect the licensee from being sued by the licensor for patent violation." If person A has a patent on algorithm X, and he wrote open source code which implements X, and he licenses this code to person B under the MIT (or BSD) license, and B uses the code, it's feasible for A to sue B for patent violation.
For this reason alone, I think MIT and BSD are awful, archaic licenses that should be avoided at all costs. The Apache 2.0 license is a great substitute.
I think this is a very carefully couched way of saying "the MIT license doesn't protect the licensee from being sued by the licensor for patent violation." If person A has a patent on algorithm X, and he wrote open source code which implements X, and he licenses this code to person B under the MIT (or BSD) license, and B uses the code, it's feasible for A to sue B for patent violation.
For this reason alone, I think MIT and BSD are awful, archaic licenses that should be avoided at all costs. The Apache 2.0 license is a great substitute.
Other very capable analysts have argued that MIT does grant patent rights, either express or implied. They've also argued that other legal rules, especially patent "exhaustion", remove the risk.
I'm with you on this, though. It doesn't have to be broke. We can fix it.
Blue Oak Council, a nonprofit I'm a part of, published a tier-ranked list of permissive licenses. All of those at the top handle patent explicitly: https://blueoakcouncil.org/list
We also published a model permissive license, which comes with a very explicit, very broad patent grant: https://blueoakcouncil.org/license/1.0.0
I'm with you on this, though. It doesn't have to be broke. We can fix it.
Blue Oak Council, a nonprofit I'm a part of, published a tier-ranked list of permissive licenses. All of those at the top handle patent explicitly: https://blueoakcouncil.org/list
We also published a model permissive license, which comes with a very explicit, very broad patent grant: https://blueoakcouncil.org/license/1.0.0
Until 5 minutes ago, I thought myself pretty copyright-savvy. I've spent perhaps $200,000 on IP attorneys over the last couple of decades--far more than most HNers, far less than many others. I also follow IP law loosely because it interests me.
Turns out I'm still a tyro.
Turns out I'm still a tyro.
For what it's worth, the author of the post has a lot to learn, too.
Aside from my enjoyment of the subtle humor expressed in the above comment, I find it interesting that there was no way to express either approval or disapproval of it without that action being subject to misinterpretation. I sat frozen for two minutes, mouse poised above the up and down triangles, unable to act. An appreciative reply seemed to be the only way out. Bravo.
I would be interested in reading a similar piece from the perspective of someone with a background in the law of continental Europe. I adore this piece of writing, but it's very U.S.-centric in parts.
I think most of this (other than the historical references) is in reference to the effective “strong minimum standards” of the Berne Convention, and to the later treaties established between WIPO member nations. Therefore, it’s almost† globally applicable.
† From Wikipedia, WIPO non-members: Kosovo, Federated States of Micronesia, Palau, South Sudan, and the states with limited recognition. Palestine has observer status.
† From Wikipedia, WIPO non-members: Kosovo, Federated States of Micronesia, Palau, South Sudan, and the states with limited recognition. Palestine has observer status.
The devil is, however, most often in the details. Lines such as
> United States law calculates copyright terms differently for individual and “corporate” authors.
make me wonder what it is like in, say, France or Germany.
> United States law calculates copyright terms differently for individual and “corporate” authors.
make me wonder what it is like in, say, France or Germany.
In Germany Copyright (Urheberrecht) is always with the original author and can not be sold or given to somebody else. It can be inherited.
One can sell or give permission the right to publish, duplicate, whatever (Verwertungsrecht).
Writing a book on company time and money automatically awards the company the rights to publish, make money, etc.
Writing a book in you spare time with "work related knowledge" might award the company with a claim for buying (at fair value) the publishing rights.
If you write a bestseller on company time you might also be entitled to a compensation in addition to your payrole. (But always best to have a contract beforehand)
But on the whole Germany is in the Berne convention.
One can sell or give permission the right to publish, duplicate, whatever (Verwertungsrecht).
Writing a book on company time and money automatically awards the company the rights to publish, make money, etc.
Writing a book in you spare time with "work related knowledge" might award the company with a claim for buying (at fair value) the publishing rights.
If you write a bestseller on company time you might also be entitled to a compensation in addition to your payrole. (But always best to have a contract beforehand)
But on the whole Germany is in the Berne convention.
Yes, my understanding is that is one of the reasons why trying to just place something in the public domain is problematic in various countries in continental Europe. There are potentially issues in other countries as well but "moral rights" aren't really a problem in common law countries.
> 171 words every programmer should understand
Except there really isn't any agreement on some of the finer details of the license, no matter how much you want to study and understand it. Does the license text have to be included in only the source code or the compiled software? What if the source code of the derived software isn't made public? What is "substantial portions" of the software? Can a MIT project be relicensed? What is the point of any of these clauses then?
While it is a great license, I wish something closer to just public domain would have become the OSS default, since that is what 99% of developers want anyways.
Except there really isn't any agreement on some of the finer details of the license, no matter how much you want to study and understand it. Does the license text have to be included in only the source code or the compiled software? What if the source code of the derived software isn't made public? What is "substantial portions" of the software? Can a MIT project be relicensed? What is the point of any of these clauses then?
While it is a great license, I wish something closer to just public domain would have become the OSS default, since that is what 99% of developers want anyways.
> Can a MIT project be relicensed?
Among more sophisticated users I don't think there's disagreement on this point. The answer is "no", if by "relicense" you mean "remove the MIT license and put in something else". You can never legitimately remove the MIT license from a file unless you're the copyright holder or their authorized agent.
Where there's less than total agreement is whether the MIT license may be subsumed by another license — e.g. the Apache License 2.0 — when an MIT licensed work is bundled within a package. Can you claim that the complete package is available "under the Apache License 2.0", omitting the fact that the licenses are actually polyglot?
The answer to that question seems to be "everybody does that" and "in practice, the legal risk seems to approach zero", but in theory should two licenses ever prove to have incompatible provisions then things could get sticky in a court case.
Among more sophisticated users I don't think there's disagreement on this point. The answer is "no", if by "relicense" you mean "remove the MIT license and put in something else". You can never legitimately remove the MIT license from a file unless you're the copyright holder or their authorized agent.
Where there's less than total agreement is whether the MIT license may be subsumed by another license — e.g. the Apache License 2.0 — when an MIT licensed work is bundled within a package. Can you claim that the complete package is available "under the Apache License 2.0", omitting the fact that the licenses are actually polyglot?
The answer to that question seems to be "everybody does that" and "in practice, the legal risk seems to approach zero", but in theory should two licenses ever prove to have incompatible provisions then things could get sticky in a court case.
I was involved with a group of open licensing lawyers that ended up publishing a "model" permissive license: https://blueoakcouncil.org/license/1.0.0
It's not everything anyone ever wanted, but we think it's a lot closer.
It's not everything anyone ever wanted, but we think it's a lot closer.
I like the way this license is much clearer about rights and obligations. From the standpoint of software developers being able to grok it, it looks like a strong improvement on the MIT and BSD families.
If you are serious about adoption, I suggest providing an official header to embed in files. Something simple like this:
If you are serious about adoption, I suggest providing an official header to embed in files. Something simple like this:
// Licensed under https://blueoakcouncil.org/license/1.0.0
Thanks. We didn't originally set out to write a new license, but when we did, we put real time and thought into it. It's nice to see that appreciated.
We've shied away from declaring one "right" way to use the license, because norms, conventions, and expectations vary so much across development communities. What's right and normal for, say, Maven artifacts would seem a bit strange in, say, an npm package or a C library.
We've shied away from declaring one "right" way to use the license, because norms, conventions, and expectations vary so much across development communities. What's right and normal for, say, Maven artifacts would seem a bit strange in, say, an npm package or a C library.
I too like the license, and wouldn't mind using it. Have you considered submitting it for approval to the OSI and FSF?
Everyone involved in the drafting has been through the OSI license process---or some ever-changing version of it---before. Last we discussed, nobody wanted to do that process again, even for an uncontroversial permissive license.
Personally, I don't care what OSI says. If someone else wants to go and ask them about it, more power to them.
Personally, I don't care what OSI says. If someone else wants to go and ask them about it, more power to them.
I did not realize the MIT License had so many variants [1]. Compare that to Apache License 2.0, which has one canonical form [2]. For this reason alone, Apache seems like a plainly better choice (IANAL).
[1] https://fedoraproject.org/wiki/Licensing:MIT
[2] http://www.apache.org/licenses/LICENSE-2.0
[1] https://fedoraproject.org/wiki/Licensing:MIT
[2] http://www.apache.org/licenses/LICENSE-2.0
I was hoping for a discussion of the “substantial portions” term. The explanation focuses on use as a dependency, but what if I take some MIT code and modify it and include it directly in my project? What counts as “substantial portion”?
In general it means "this applies to derivative works." At best, it might provide an argument that APIs aren't covered (now that that's a thing). But copyright law doesn't really recognize "substantial portion" as a term of art (though it's arguably related to one of the prongs of a Fair Use inquiry). IANYL but my personal practice is and would be to ignore the word "substantial."
So if I copy a 3 line example off stackoverflow I may need to add a license disclaimer... Wow.
It depends on SO's terms of use. Without any terms to the contrary, which I am confident exist, you would be violating copyright by copying that example, regardless of attribution.
Assuming the example is the original work of the author of the post (and again, assuming no other terms), then that post author would hold copyright to the work. You would have no license to copy or distribute it.
I have great confidence that SO's terms include a section wherein contributors grant license or grant copyright to SO. At that point (again, assuming no other terms), you would still have no right or license to copy or distribute the work.
Assuming SO has a very permissive license to the work, including the ability to re-license it, they can grant you a license to copy or distribute the work. At that point you are bound by the terms of the license SO grants you.
Read the terms to get specifics.
Assuming the example is the original work of the author of the post (and again, assuming no other terms), then that post author would hold copyright to the work. You would have no license to copy or distribute it.
I have great confidence that SO's terms include a section wherein contributors grant license or grant copyright to SO. At that point (again, assuming no other terms), you would still have no right or license to copy or distribute the work.
Assuming SO has a very permissive license to the work, including the ability to re-license it, they can grant you a license to copy or distribute the work. At that point you are bound by the terms of the license SO grants you.
Read the terms to get specifics.
Read the SO TOS. Probably can't legally include that unless SO gives you license.
Thanks to the 197? Law that provided automatic copyright the instant anyone says or does anything copyrightable.
I'm sure SO TOS states by using this site you assign or grant copyrights to SO. Same as HN and any site otherwise they'd be liable for reproducing what I wrote in this comment which in USA is automatically copyrighted to me the moment I hit "reply".
Thanks to the 197? Law that provided automatic copyright the instant anyone says or does anything copyrightable.
I'm sure SO TOS states by using this site you assign or grant copyrights to SO. Same as HN and any site otherwise they'd be liable for reproducing what I wrote in this comment which in USA is automatically copyrighted to me the moment I hit "reply".
(2016)
It's not like anything in the license has changed since late 80s.
At risk of piling on, it is silly to cargo-cult dating articles. This is a case where the date truly is not relevant, and that should be recognized. That's a minor point compared to the larger phenomenon which is the insistence on recency for our attention. Why? Probably because the long tail isn't profitable enough, but it is a shame every portal onto the 'net except archive.org and wikipedia.org insist on recency for relevance.
Providing a date for context is not "insisting on recency for relevance", it's providing context. Even if that context is just that some people recognize "ok, that's the article I read a while back and not an updated version".
In fact the author did later post a follow-up highly critical of the MIT license, recommending their own creation instead:
https://writing.kemitchell.com/2019/03/09/Deprecation-Notice...
https://writing.kemitchell.com/2019/03/09/Deprecation-Notice...
That's not quite true. Sometime in the 1990s, before the OSI version became the canonical one, it seems to have morphed from a variant of the X Consortium license to the ECMA license. [1] But, yes, nothing has changed in the past 20 years.
[1] https://opensource.com/article/19/4/history-mit-license
[1] https://opensource.com/article/19/4/history-mit-license
Duh, that should be Expat license, not ECMA.
That was nicely done!
I am glad to see an actual IP lawyer's view on this thing.
I am glad to see an actual IP lawyer's view on this thing.
The JavaScript and npm ecosystem are extremely dependency-heavy. Even if you only take a few yourself, the number of sub-dependencies of even a simple application are often in the hundreds.
Why does "everyone" ignore the attribution of their dependencies and sub-dependencies? Laziness? Risk of getting sued too low? What happens if Oracle buys all the left-pads in the world?