Htmx changes license to Zero-Clause BSD
github.com
github.com
- over the weekend I started making the @htmx_org twitter account increasingly corporate looking
- started talking a lot about MSFT, implying they were interested in htmx
- someone asked if MSFT was going to buy htmx: https://fxtwitter.com/htmx_org/status/1746656784088228204
- i then put up a post about changing the htmx license, implying i was going to restrict it due to MSFT interest: https://fxtwitter.com/htmx_org/status/1746736273728094323
- I then made is 0BSD instead of 2BSD: https://fxtwitter.com/htmx_org/status/1746880860723544211
- I then posted the "offer" i got from MSFT (some credit card thing) https://fxtwitter.com/htmx_org/status/1746895016256328079
- And explained how there were no lies involved in the ruse: https://fxtwitter.com/htmx_org/status/1746924827641102719
the reason i did all this is for the lols
Know your worth; don't sell out for anything under 20% cash back at Bed, Bath & Beyond!
Having said that, I don't think they actually take coupons any more. It stopped when all the physical stores closed. The offer here is a cash back offer, where you pay the full price then another company (like TopCashback, Rakuten, apparently Microsoft too) gives you 10% cash back.
Just kidding... Foreign exchange....
Kidding again... I don't actually know.
Should have gone for the "do whatever the fuck you want" license though
Lawyers don't like things they don't recognize.
One of the primary reasons we've gone with React/NextJS coupled with MongoDB and Kubernetes over HTMX
But when it comes to databases, which are often the single most important part of an architecture, you'll find that many people are less forgiving of old sins, especially when Postgres now has native JSON support.
Much like I won't trust Uber with my location, or Google with my email, I won't trust Mongo with my data.
FYI using mongo is more than simply wanting a json interface.
"Fool me once, shame on you; fool me twice, shame on me."
Maybe MongoDB is great now. That doesn't change the fact that many people have been burned by MongoDB.
But, perhaps we can let maybe we can let bygones be bygones if we can determine that MongoDB is solid and dependable now. How do we make that determination?
If we decide that MongoDB is now robust based on present popularity and general satisfaction, that's fallacious reasoning:
https://yourlogicalfallacyis.com/bandwagon
After all, there was tons of stoke about MongoDB early on, only for people to realize later that their data was being silently nuked, which is why there is such a grudge against MongoDB in the first place. If an appeal to popular belief is proof, then we have a paradox.
Not everyone has the time and skill to thoroughly analyze MongoDB like Kyle Kingsbury / Jepsen:
https://jepsen.io/analyses/mongodb-4.2.6
And even then, there are so many other databases that have a better track record, so it would be hard to argue that the effort would be worthwhile.
I don't see how you're struggling with the notion of reputation here.
Maybe bias in favor of MongoDB is too strong? If that's the case, one last ditch effort:
If your friend's dog has gruesomely bit you 10 out of the last 10 times you've visited him, but he swears the dog is now rehabilitated, do you just shrug off being bit over and over again, and visit your friend without even the slightest apprehension? Or do you, at the very least, remain hypervigilant, given you're history with the dog?
Now replace "dog" with "MongoDB", and replace "bite" with "invaluable production data being absolutely eviscerated, resulting in your customer's lost trust and also immeasurable financial harm being done to you and your family".
And everything mongodb brought us, was either implemented by someone else better or already existed.
If you use mongodb today, just go with postgres and forget about mongo
He has no such obligation to do these things, this is all his choice. I'm not sure why the contention? If you read my comment, it was strictly about production scenarios, not about all credibility for all scenarios. If this project is meant to be treated as fun CRAPL, Matthew Might made a great license for that: https://matt.might.net/articles/crapl/ .
I still hold the position that the social media presence of the project should be inconsequential for considering it's production usage. But I can see your point now, even if I disagree.
2. The joke made by the maintainer gives absolutely no insight into how they will behave if there were a contract. If anything, that might mean the maintainer actually is a human that is agreeable to talk and work with, because they don't take it so seriously as to forbid any jokes.
Professionalism doesn't mean "no jokes allowed", it means "do your best".
I understand where you are coming from, the @htmx_org twitter account is very silly. This can be a big turn off to some developers and companies. On the other hand, I do have a fair number of serious essays on the htmx website (https://htmx.org/essays) and a free book that is also serious (https://hypermedia.systems).
I view twitter as a tool for getting the word out about htmx and, therefore, use it in that manner. I don't think that medium supports super-nuanced discussions (although I've had some.) I try to not be negative on it, and frequently link to my essays for more in-depth discussions. I also enjoy being funny and making people laugh.
And, while I can understand and sympathize with people who dislike the general vibe of my account, you can't argue with the success of this approach.
It has recently passed 27k stars on github:
https://star-history.com/#bigskysoftware/htmx&Date
And finished 2nd (!!!) in the js rising stars frameworks for 2023:
https://risingstars.js.org/2023/en#section-framework
Plus #10 overall. This is a library created by a one-person company that is trying to compete with the likes of Facebook, Google and Vercel when it comes to developer mindshare. While I would love to think it is the insightful essays, excellent coding ability and the quality of my book, there is no doubt that the twitter account has been a huge contributor to htmx's success.
Do the lols while you still can, the Trust and Safety departments at major social media companies want to extinguish funny.
Everyone who does even a smidgen of memeing on the internet knows what happens when you post images of large spiders. People start talking about burning things down, like the entire building its inside of, etc. Someone posted a video where a little girl had one crawling on her hand, it was bigger than her face. I said "Girl get away from that spider, we have to set the house on fire" and the AI anti-funny overlords at Facebook deleted my comment, and gave me some sort of "strike" and then I appealed, and was auto denied.
Our favorite Sci-Fi dystopias coming soon, to a Trust and Safety social media site nightmare near you.
The sooner you accept that, the sooner you'll be able to function as a shiposter is supposed to function: without mercy, without anxiety, without remorse.
All shiposting depends upon it.
All reports denied. It was glaringly obvious she was a paid misinfo troll.
I figured it was just like any other boss, takes all the credit if it works. desperately tries to shift blame if it does not.
[0] the process was pretty much the same speed for non-participants in non-participant countries, but okay: his administration made it a priority. Gold star for you!
But then again, twenty years ago you had all sorts of political positions you could take, now everything is simply binary. You have no agency.
It was fun to watch people disagree about things, that's mostly gone in the political world (and that world eats all discussion boards eventually, in my experience).
> <Copyright Information>
>
> Usage of the works is permitted provided that this instrument is retained with the works, so that any entity that uses the works is notified of this instrument.
>
> DISCLAIMER: THE WORKS ARE WITHOUT WARRANTY.
EDIT: I would not use this license. I'm not sure how this got approved by the OSI, but I'm not a lawyer. Some of the email threads think the disclaimer is insufficient, and I'm not entirely sure that it confers all the expected rights since it only says "Usage" (copying, modification, distribution).
0: https://github.com/ErikMcClure/bad-licenses/blob/master/dont...
The works can be used as long as this instrument is kept alongside them to notify users. The works are provided without warranty.
Zavras, Alexios. Twenty-five years of school? Analysis of Free and Open Source software license texts. Journal of Open Law, Technology & Society, [S.l.], v. 8, n. 1, p. 29-44, nov. 2016. ISSN 2666-8106. Available at: <https://www.jolts.world/index.php/jolts/article/view/111>.
> Note: Despite its name, Zero-Clause BSD is an alteration of the ISC license, and is not textually derived from licenses in the BSD family. Zero-Clause BSD was originally approved under the name “Free Public License 1.0.0”.
Anyone seen a good write-up of the tradeoffs for this license? I like how short and simple it is.
For example, all the code snippets in the Intel Software Developer Manuals (https://www.intel.com/content/www/us/en/developer/articles/t...) are licensed under 0BSD, so that people can easily re-use them (with or without adapting them).
I think (please correct my understanding) zero clause BSD can be embedded in a GPL project too, it just becomes one-way included, subsumed into the GPL project and then under the GPL licence. (Relicenced)
Could the author of HTMX explain their reasoning for changing the licence? I am curious?
Since there's no requirement to credit a zero clause licenced BSD code, someone who receives the BSD code compiled might not know it's included but that's the risk I'm taking.
It lifts a significant burden for people/projects/organizations who want to release software while complying with all license obligations.
Both of which are hard and/or expensive. So most rely on public shame. Out them on social media and foment outrage.
MSFT might want it because it's gotten a lot of attention lately (finished #2 in https://risingstars.js.org/2023/en#section-framework for 2023) and would give them a front-end library in the game w/ React, Vue, Svelte, etc. On the other hand, i've made the social media account pretty toxic/funny (same thing) for a big tech company and now the library is 0BSD, and htmx's agnosticism towards back end tech doesn't really dovetail w/ the Microsoft ethos.
[1]: https://techcrunch.com/2023/02/16/sequoia-backs-open-source-...
[2]: https://www.sequoiacap.com/article/sequoia-open-source-fello...
Ultimately, I think this stems from the fact that Open Source licenses were explicitly created by people who wanted to be friendly to corporations, and the GPL licenses were created by the FSF, who are essentially the vegans of software. So I think in the long run what we need is a free software movement that is detached from both the dogmatism and absolutism of the Free Software Foundation and the desire to suck up with corporations. A movement that perhaps sees itself as being a check on the balance of corporations in the software world, but in a more pragmatic way.
I think the sort of license a movement like that might produce might end up looking something like the MPL 2.0: it allows combined works that use the existing code in any way they want, while requiring changes or improvements to the existing code to be shared back to the community, so that there is a clear requirement to give back to the things you benefited from, without trying to also take away the things you or your team wrote themselves.
This is similar to the LGPL, but unlike that license the basic unit of separation is clearer: files. Original source code files and any files containing substantial portions of code copied from the original source code are considered part of the original work, and therefore something to which changes must be contributed back to the community, but anything outside those files can stay proprietary. This is a lot clearer and more flexible than the LGPL, meaning developers from FOSS and from corporations can use code under the without headaches, while still not allowing companies to just completely free ride on the things the software community makes, and we get to have both because unlike the LGPL the MPL is willing to sacrifice some stringency and control in return for those benefits.
Additionally, and perhaps more importantly, it doesn't have particularly onerous source distribution requirements or requirements to distribute your own application as object code or provide some other way for users to swap out the version of the free software code that's being used, which likewise does sacrifice some FSF purity, but in return for a massive decrease in the complexity, onerousness, and annoyingness of the license requirements as a whole. So yeah, the MPL isn't perfect — maybe the ideal free software license would be the LGPL with just clearer specification of where the boundaries are between the LGPL code and the proprietary code, and no annoying object code or dynamic linking requirements — but it's a lot closer to where I think we need to move with licenses. I don't think zero clause open source licenses are the way.
However, I also think it's fairly easy to circumvent for a hypothetical leech that just wants to use my code without contributing back any improvements. Namely just put the improvements into a separate proprietary file, and insert stubs in the MPL licensed file calling the proprietary code. Taking this argument to the extreme, one should use either something extremely permissive like 0BSD or then go full AGPLv3, as everything inbetween is to an extent possible to circumvent without too much trouble (GPL "condoms" and all that).
Yeah this is the work around that came to mind when I first read the MPL, and it's what I had in mind when I said it isn't perfect. I'm using it for a current game engine project I'm working on, and will probably use it for any of my other work moving forward, but I definitely think it isn't the end of license history — there is still a lot more improvement that could be made. I was just giving it as an example of what I think the correct direction is, in contrast to the current extremes. I think it's where more work on licenses should go.
Certainly they make it hard/impossible to build a business from Open Source code. Unfortunately in an economic system designed to maximise the reward for value capture at the cost of value creators this is a common problem. But I believe the answer to that is more communism, not more licenses with more convoluted requirements creating jobs for legal departments for shared code.
You are technically correct in this, and technically speaking perhaps I should have put what I said in terms of the free rider problem, not necessarily enclosure of the commons, but two things: first, I do think what corporations do with open source software is to some degree more analogous to such an enclosure, since in a free rider problem we typically imagine a few or even very large number of lazy individuals just not paying for something, whereas in the enclosure of the commons it is the rich and large corporations benefiting from the work of more common folk, and the power dynamics of what happens in software look more like the latter than the former. Second, you're forgetting embrace, extend, extinguish, which very much does have the effect of destroying things by commercial cooption and absorbtion.
> Certainly they make it hard/impossible to build a business from Open Source code. Unfortunately in an economic system designed to maximise the reward for value capture at the cost of value creators this is a common problem. But I believe the answer to that is more communism, not more licenses with more convoluted requirements creating jobs for legal departments for shared code.
I sort of view licenses that require contributing any improvements you've made to something back to the collective pool from which you got it as a form of communism, even if in this case it is embedded in and enforced by a capitalist system.
Does this effectively make htmx public domain?