js-must
js-must copied to clipboard
moll
Why I Passed on Must
I just wanted to let you know that Must looks like a great library, but I opted to pass on it for two easily correctable reasons:
- it modifies the core prototype
- it uses the Lesser GNU Affero General Public License
If there had been some way to not modify the prototype (and simply require demand around everything), and if you'd gone with the MIT license I would have used Must for my next project, so I just thought I'd share in case you wanted people with my concerns to use the library in the future.
In any case, thanks for pushing JS testing forward!
Hey!
Thanks for the feedback! It's great to hear negative criticism in addition the more common silence.
As for the reasons, the published version does indeed always modify the prototype, however the master that I've been postponing releasing for a while (as it's a breaking change) doesn't. When you require must, you actually just get the demand function and need to include must/register for the global version.
As for the license, what's wrong with LAGPL?
however the master that I've been postponing releasing for a while (as it's a breaking change) doesn't
Awesome, I will keep an eye out for it.
As for the license, what's wrong with LAGPL?
Here's my thinking, and please understand it's nothing against you or this project specifically.
The Facebook/React patent thing has made me (and a lot of devs I think) suspicious of anything other than the standard licenses (BSD, GPL2, or MIT), which are used by 99% of the JS OSS projects. If I see a project using one of those licenses I know what I'm getting in to, and I know I'm not going to get "screwed" by the license. But when I see a project using any other license, my first thought is "why would they use any license except the standard ones unless they're trying to screw me out of a right protected in the standard ones?"
Please understand that I'm not at at all saying that's what you're doing, but since I don't have the time to read yet another licensing agreement (and just as importantly, the pontifications of various lawyers about what it actually means) that's just my default assumption.
If you're going to use a non-standard license I think it would really help to explain exactly why you chose to zig when everyone else is zagging, and to explain what rights the user is being "screwed" out of by agreeing to this license (so that they can determine whether those rights matter to them or not). But to quote Steve Krug (author of "Don't Make Me Think"), I think the ideal solution is to not make people using a library have to think at all about its license, and choosing a standard license achieves that.
That's an interesting take. Thanks for sharing. I guess I indeed presumed that those who care about licensing already knew AGPL, as it is, after all, a GNU license. GPL2 isn't suitable for any server side stuff, be it libraries or full blown OSS products, because of its hosting loophole — one can leech off of OSS when merely hosting it. While I'm not a fan of the database, I presume that's why MongoDB chose AGPL, too. However, for libraries, AGPL doesn't play well. Just like GPL needed its LGPL, AGPL needs its Lesser AGPL.
That's a bit of a side track, but I think AGPL is a seriously underrated license out there. It suits networked software libraries (that JS libs are) like a glove, guards against leechers, and with a lesser clause isn't "viral" like GPL/AGPL are.
Btw, as you bring up getting screwed — I'm instead wary of some of the licenses you brought up. With BSD/MIT, in fact, I as a contributor would get screwed because my work can then be taken "offline", improved upon and the improvements never returned to the public. That's leeching. I hate that and it's not exactly clear to me why it's so prevalent among projects. I can get leechers preferring that, but why would people succumb...
With BSD/MIT, in fact, I as a contributor would get screwed because my work can then be taken "offline", improved upon and the improvements never returned to the public. That's leeching. I hate that
Your license is better for you as a contributor, no question. But it is more restrictive, and from the adopter's standpoint that's inferior: if you had two identical codebases, one AGPL licensed and one BSD licensed, an adopter can do things with the latter they simply can't do with the former.
To be clear, I'm in no way trying to say that less restrictive licenses are > more restrictive ones in general, only from the perspective of the adopter. Bur since they are inferior to the adopter, you have to decide whether to tell the adopter that or not. If you do they still might use the library: if you say "I use AGPL because I detest leeches, and the only right you're losing is distribution" then adopters who don't care about redistribution rights will still use your library.
But if you assume that everyone knows every license and what the upsides/downsides of them are, people like me who don't know are going to see a library that is more restrictive than other libraries, doesn't explain how, and doesn't explain why. Would you pick that library?
Fair enough. How would you suggest I amend the current 4 bullet point summary of LAGPL I have on every README to make it more clear?
This?
Must.js is released under a Lesser GNU Affero General Public License, which in summary means:
You can use this program for no cost.
You can use this program for both personal and commercial reasons.
You do not have to share your own program's code which uses this program.
You have to share modifications (e.g bug-fixes) you've made to this program.
The problem (as I see it at least) is that you're listing a subset of the things the Affero license has that other licenses also have. But if you read all of the above, the entire problem for an adopter isn't knowing how your license is similar to a more common license, it's knowing how it's different. There's no mention of redistribution rights there, and there's no mention of why you're doing this "abnormal" thing in the first place.
I'd start with what you wrote above:
GPL2 isn't suitable for any server side stuff, be it libraries or full blown OSS products, because of its hosting loophole — one can leech off of OSS when merely hosting it. While I'm not a fan of the database, I presume that's why MongoDB chose AGPL, too. However, for libraries, AGPL doesn't play well. Just like GPL needed its LGPL, AGPL needs its Lesser AGPL.
I think AGPL is a seriously underrated license out there. It suits networked software libraries (that JS libs are) like a glove, guards against leechers, and with a lesser clause isn't "viral" like GPL/AGPL are.
It explains the why ("GPL2 isn't suitable ... because of its hosting loophole ... for libraries, AGPL doesn't play well... [it] needs its Lesser AGPL .. [it] guards against leechers, and ... isn't "viral" like GPL/AGPL are") and at least sort of explains the what ("guards against leechers, and with a lesser clause isn't "viral" like GPL/AGPL are").
You could improve it further by making both things clearer, but since I still don't have a good sense of the exact differences between LAGPL and GPL2/Apache/BSD/MIT I can't propose specific better text. Something about redistribution clearly, but I'm not sure the most accurate way to say that, or if there are other concerns worth mentioning ...
... but hopefully that at least helps give you an idea of my concerns (which I imagine are also the concerns of some other developers out there).
Thank you for the notes! I'll think up of something and perhaps you'd be willing to take a look at the draft once I do so to comment whether it clarifies the questions you nicely pointed out above.
Oh, and did our conversation here address your concerns and remove them with regards to (L)AGPL?
Oh, and did our conversation here address your concerns and remove them with regards to (L)AGPL?
For the project I'm working on (a personal side project) the redistribution thing is a total non-issue, so now that I understand that that is the license's main restriction I have no problem with it.
However, I've had to (twice now) do software audits at companies I've worked at. I had to go through every single package we used, list each one's license, and note any potential problems. Why? Because I tend to work for start-ups, and start-ups depend on VC funding. VCs don't want to invest a ton of money in a proprietary software company only to have that software stop being proprietary because the company used a single package with the wrong license.
That sort of thinking (legitimately or not; all it takes is a VC hearing one horror story for them to over-react) discourages start-ups from adopting libraries with non-standard-licenses, especially when there are (more) open alternatives. It's not that they hate OSS (in both cases the companies were big OSS users, and to a lesser extent contributors), it's just that they have to eliminate risk to get funded, and they need funding to survive.
And no matter how great the library is, for me it's no fun learning and getting addicted to it at home, only to not be able to use it at work. But just because I see things that way doesn't mean the license is a poison pill. Plenty of people only working on personal projects, people working at non-startups who know for certain they'll never have to worry about redistribution, etc. might all find this project valuable, By explaining the license's pros/cons and your reason for adopting it I truly believe you'll get more of those people to adopt it.
Thanks for elaborating! As a general comment, I'd perhaps just make sure we don't call AGPL itself non-standard. It's been around for 15 years now, has plenty of use and is the in the OSI approved list: https://opensource.org/licenses/alphabetical. My lesser clause addition, however, can surely be called non-standard. In fact, I'm rather disappointed that there wasn't one before that fulfills these not-so-unheard-of requirements that I described above.
Mind clarifying what you mean by "redistribution"? Using it in a webapp of sorts? That's the only unique addition of AGPL over GPL. As for personal and commercial users, I don't think the license makes much distinction there. I don't. It's only when licensed software is modified and used in a [public] webapp would the former's source have to be shared. I'd reckon "fear" of that would be independent of the company's maturity.
Companies as a whole are surely interesting beings. Like the regular consumer, I guess they're equally keen on getting things for free. I personally have gotten very little out of any of my OSS work and am perfectly fine losing "customers" that don't want to play fairly. Perhaps it's a sort of self-fulfilling prophecy, but then again, I don't have the time to do true marketing and figure out a way to convert OSS eyeballs into dollars. I don't even think that's possible for the long tail of OSS work.
All in all, I don't think the use of (L)AGPL as it stands will in any way interfere with the business as usual of software writing. I'd classify the VC worries as FUD, with emphasis on its original definition's uncertainty. I interpret this entire discussion as a suggestion to reduce that uncertainty and I intend to do. Being closer to the constituents of said startup people, I'd invite you to also spread the knowledge that non-BSD-like licenses are perfectly fine in their contexts.
Per https://github.com/blog/1964-open-source-license-usage-on-github-com the top three licenses are MIT (44.69%), GPL2 (12.96%), and Apache (11.9%), for a total of 68.84%. And that's across GitHub overall: based on what I've seen those licenses are even more common in JS libraries specifically. LGPLv3 and AGPLv3 together have 2.35%: that's all I meant by "non-standard".
As for the rest, it's not really FUD in the traditional sense. Microsoft used FUD to scare people away from OSS. but these VCs have no agenda against OSS, they just see a risk and want to avoid it. I'm certainly not saying all VCs (or even all Silicon Valley VCs) feel this way, I'm just saying after having to do the audit thing twice I now I prefer to use libraries I know won't cause waves.