91–100 of 148 posts
Turns out I'm still a tyro.
> 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?
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 act…
Earlier quoted context omitted.
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.
> 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.
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.
Earlier quoted context omitted.
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: // Licensed under https://blueoakcouncil.org/license/1.0.0 Also "instructions on how to use thi…
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 libra…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 libra…
I too like the license, and wouldn't mind using it. Have you considered submitting it for approval to the OSI and FSF?
Personally, I don't care what OSI says. If someone else wants to go and ask them about it, more power to them.
Earlier quoted context omitted.
There's also this: DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE Version 2, December 2004 Copyright (C) 2004 Your Name 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…
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.
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.