A lot of my response was already rendered further down the thread. So I’ll only comment on this part:

The objective is not to make the most community friendly licence, it is to pay the people who do the actual work.

If this is the singular or main objective that Futo has, then the basis of OP’s post is entirely dead. The title of the post is very clearly “FUTO License, an alternative to Open Sourd”. But if we take your submission as fact, then there is no comparison whatsoever.

Open Source – whether using OSI’s definition or including FSF’s – has almost never focused on the financial aspect, for better or worse. It’s why commercial entities like Canonical and Red Hat are so rare, because software engineers prefer spending their free time working on great things rather than doing admin.

Futo sounds like they want to be a commercial entity like Red Hat but without the limitations that Open Source or Free Software would impose on them. And they’re welcome to do that, but that endeavor cannot honestly be called comparable to the mostly community-driven projects like BSD, GNU, and Linux, or commercial ventures like RHEL and whatever cloud-thingy that Canonical is selling now.

If the goal is to pay for professional talent, with revenue from B2B sales, and only non-commercial users get a free-bee, then that’s just a shareware company with more steps. Futo trying to dress themselves up like Red Hat remains as disingenuous as when they tried to misinform open-source folks about what open-source is.

I’ll be frank: my interest in software licensing is about finding licenses that strike a sensible balance. It’s about distributing rights and obligations that are equitable and sustainable, while perpetuating software uptake and upkeep. It’s a tough cookie. But I think the Source First license alienates too many potential audiences and its financial model falls apart under any game theory analysis. So I’m not keen on looking down this avenue anymore.

I don’t think that’s the main objective of the FUTO license

That’s fair. I stated my assumption because perhaps they have different objectives. That said, history is quite clear: the greatest success of open-source software development is that it pools efforts from anyone – truly anyone – that is willing and able to put in the time, be it individuals or workers hired by a corporation.

When a license is heralded as an alternative to open-source – as the title of this post does – I think said license needs to be evaluated against the historical success story that open-source projects like Linux, BSD, Blender, etc have demonstrated. Not having the quality of attracting community contributions is a negative, but all licenses have some sort of tradeoff and ultimately that’s what people evaluate when picking a license.

I believe the main objective is to incentivize developers to create great software that respects individual users and fights back against the big tech oligarchy.

This is a laudable goal, though I think the ACSL is more direct at doing the same. It too is a non-open source license, but IMO, I give credit to them for being upfront about that, rather than pointless muddying of the term “open source” that Futo attempted (and ultimately failed at).

More dogmatically, I don’t see how elevating Futo Holdings Inc (or any other company that will manage software licensed under Source First v1.1) into a “benevolent dictator company for life” will fight against the tech oligarchy. It might act as a counter to FAANG specifically, but there’s no guarantee that Futo Holdings doesn’t end up joining their side anyway, or gets bought out by the oligopoly. Which would then put us all worse off in the end.

I don’t quite see the issue here. Can you explain a little more? A third-party would just get a license to sell the software, not to develop it.

Futo Holdings Inc, as the assigned owner of copyright over a software project, reserves the right to license their software however they choose. They can absolutely issue a license to allow a company to privately develop an in-house fork. In copyright speak, the Source First license being “non exclusive” means Futo Holdings can issue someone else a different license. History shows us examples, such as Microsoft’s non-exclusive license of DOS to IBM, which was quite handy since that allowed MS-DOS to be sold with non-IBM PC clones.

And for an example of licensing that allows in-house edits and recompiling, see the source code license offered by AT&T Labs to various universities, which included one UC Berkeley that eventually developed BSD Unix.

Isn’t this currently possible with Open Source™? Like the whole point of Open Source™ is that anyone can use the software for anything, right?

Use, yes. Distribute? Absolutely not with GPL. If ICE wants to create an OS designed to optimally coral unlawfully-detained people in barbaric conditions, then they – just like you, me, the DPRK, or Facebook – can fork Linux and do that. But if ICE then wanted to distribute that CruelOS to another country’s border patrol or secret intelligence or to a private defense firm, they would be obliged by the GPL terms to also offer whatever source code they modified in the Linux kernel to produce CruelOS.

GPL is about making sure the same rights perpetuate for all of time, for all future users, always. If Linus Torvalds turned evil today, the remaining kernel devs would just fork. Whereas Futo Holdings makes no guarantees, and they themselves can turn evil one day. This isn’t even a contrived example. See IBM/Hashicorp’s Terraform and the FOSS OpenTofu that spawned after they tried to change the license.

Google may contribute something to Linux, but my company will never contribute anything. Seems like Google is ok with my company benefiting from their work.

If Google contributed to Linux, it would be GPL licensed. Google knows that this means the playing field will always be level: no one can built and distribute that code in a way that Google couldn’t later benefit from.

Think of it like this: Google buys everyone in the tavern a beer. Everyone’s happy. But part of the deal is that if anyone else buys for themselves a beer, they have to buy for everyone as well. Google is fine with this, because it means that Microsoft wearing the dark suit will also have to pony up if he wants another drink. As will Netflix in the skinny jeans sitting at the booth. As would Ericsson, the Swede dancing jovially to a tune.

With the Source First license, Google has no guarantees that Microsoft won’t use his manly charisma to charm Futo Holdings into giving him a better deal than what Google got. Google is bitter at that prospect, and decides not to buy everyone a beer after all. You, me, and Bob who fell asleep in the corner now need to pay for our own beers, but the bartender won’t give us a group discount anymore. We are now all worse off.

In closing, I had this to say in an earlier post:

Using the tools of the capitalist (copyright and licenses) to wage a battle against a corporation is neither an even fight, nor is it even winnable. Instead, strong communities build up their skills and ties to one another to fight in meaningful ways.

If you’re not building (software) communities, the struggle will not succeed.

Community audits sound great on paper, but it’s something which the FOSS licenses (eg GPL, MIT) also provide. As a practical matter though, auditing has a two-fold objective: 1) identify risks so they can be quantified, and 2) mitigated. For non-commercial users in the community, an audit is high-effort with low return. And further, this license disincentives mitigation even if the audit does turn up something, because of having to sign the copyright away just to submit a bug fix.

For commercial users, auditing is more palatable, being part-and-parcel to risk management. And these commercial operations have the budget to do it, but then this license means the best way to keep improvements out of their nemesis’s hands is to maintain an internal fork that never returns code to the public repo. So commercial users will have to pay more to obtain that sort of license.

All this seems harder than just using MIT code (or even GPL), if such is available. And that’s exactly why I can’t see myself using source-available software in a personal or professional capacity, when there’s any other choice available. It seems worse off for everyone except the owner of the public repo. The license stinks of vendor lock-in, and even if I’m not the one who will pay the rent, I dogmatically will not support rent-seeking like this.

To be abundantly clear, “free software” (aka free as in speech) and “open source” are understood as two different categories, and when software falls into both, would be called Free and Open Source (FOSS).

Wikipedia has this to say:

FOSS stands for “Free and Open Source Software”. There is no one universally agreed-upon definition of FOSS software and various groups maintain approved lists of licenses. The Open Source Initiative (OSI) is one such organization keeping a list of open-source licenses.[1] The Free Software Foundation (FSF) maintains a list of what it considers free.[2] FSF’s free software and OSI’s open-source licenses together are called FOSS licenses. There are licenses accepted by the OSI which are not free as per the Free Software Definition. The Open Source Definition allows for further restrictions like price, type of contribution and origin of the contribution

I’m not sure how this license would foster community contributions to the codebase, assuming that was an objective. When I say “contributor” I mean both individuals as well as corporations, in the same way that both might currently contribute to the Linux kernel (GPL) today.

As written, this license grants the user a non-exclusive license for non-commercial use. But that implies that for commercial users – like a corporation – they’ll have to negotiate a separate license, since Futo Holdings Inc would retain the copyright. So if a corporation (or nation state entity) throws enough money at Futo Holdings Inc, they can buy their way into any sort of license terms they want, and the normie user can’t complain.

This is kinda like the principal-agent problem, where the userbase and individual developers now have to trust that Futo Holdings won’t do something reprehensible with the copyrights, be it licensing to certain hostile countries or whatever.

Whereas in the GPL space, individual developers still own their copyright but license their code out under a compatible license. So even Linus Torvalds cannot unilaterally relicense the Linux codebase, because he would need to seek out every copyright owner for every line of code that exists, and some of those people are already dead.

I’m personally not a fan at all of forcing individual contributors from the community into signing over copyright (or major rights thereto) or other stipulations as a condition for making the codebase better, with the exception of an indemnity that the code isn’t stolen or a work-product for hire. I used GPL in the comparison above, but the permissive licenses like MIT also have similar qualities.

EDIT

Thinking about it more, would corporations even want to contribute? Imagine CorpA decides to add code, having already paid for an existing commercial license from Futo Holdings. But then CorpB – who is CorpA’s arch nemesis – pays Futo Holdings an absurd amount of money and in return gets a commercial license that’s equivalent to the WTFPL. That means CorpA’s contributions are available for CorpB to use, but CorpB has zero obligation to ever contribute a line of code which CorpA could later benefit from. It becomes a battle of money, and Futo Holdings sits as the kingmaker. GPL abates this partially, if CorpA is both using and distributing code. But the Source First License v1.1 has zero mitigation for this, apart from “trust me bro”.

Am I to understand that “maxValue” could have been named “maxOffset” and “minValue” be named as “baseYear”? I am indeed horrified at their inability to name something properly.

stay in a license that still allows Hashicorp / IBM to benefit from community contributions?

I don’t see how this is the case. As Hashicorp explains, they switched from the open-source Mozilla Public License 2.0 (MPL) to the proprietary Business Source License (BSL) in order to apply restrictions upon users of Terraform:

Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license.

The terms of the MPL and BSL are incompatible, insofar that Hashicorp cannot unilaterally relicense MPL code from OpenTofu into BSL code in Terraform. But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL.

This is exactly the same situation as what Hashicorp was obliged to do before the licensing kerfuffle, so it cuts against Hashicorp’s objective: why continue developing legacy Terraform if OpenTofu is going to provide continuity? Perhaps they only intend to develop new, exclusive features that build upon the common legacy code, but users would now retain an option to reject those pricy add-ons and just stick with the free, open-source functionality from OpenTofu.

It seems to me less about giving the finger to Hashicorp and more about giving users a choice in the matter. Without OpenTofu, the userbase are forced into the BSL terms of Terraform, where Hashicorp could unilaterally prohibit any production use by yet another license change. That’s no way to live or work, with such a threat hanging overhead. OpenTofu lifts that threat by providing competition, and so maybe does kinda throw the finger at Hashicorp anyway.

On the flip side, precisely because MPL code cannot be unilaterally relicensed to BSL, if OpenTofu starts to gain new features that Terrarform doesn’t have, Hashicorp can incorporate those features but they won’t be unique. Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free? The ecosystem of features cuts both ways.

Finally, it gives Hashicorp an out: if they acquiesce in future, their BSL code can be unilaterally relicensed as MPL once more, thus allowing code sharing with OpenTofu. Had OpenTofu picked a different license, this could have been much harder. But as described in the OpenTofu manifesto, continuity was the goal.

[email protected] might appreciate this

Absolutely. An example of a malicious collision would be to request the file with the SHA-1 of 38762cf7f55934b34d179ae6a4c80cadccbb7f0a. But… there’s two of them here.

MD5 is so broken that its former status as a cryptographic hash function has been stripped. And efforts are underway to replace SHA-1 where it’s used, since although it takes some prerequisites to intentionally create a SHA-1 collision today, it’s worth remembering that “attacks always get better, they never get worse”.

provide the hash of an arbitrarily large file and retrieve it from the network

I sense an XY Problem scenario. Can you explain what you’re seeking to ultimately build and what requirements you have?

Does the solution need to be distributed? Does the retrieval need to complete ASAP or can wait until data becomes available? What sort of reliability/availability does this need? If only certain hash algorithms can be supported, which ones do you need and why?

I ask this because the answer will be drastically different if you’re building the content distribution system for a small video game versus building the successor to Kim Dotcom’s Mega file-sharing service.

That is some impressive joinery to make multiple cuts to one-tenth of a degree and have them all come together! Nicely done!

I am always deeply enthralled when math and comp-sci unite to yield an elegant result, where my definition of elegance is: efficient + minimal.

I read this, and thought it was kind of all over the place. Even the first “falsehood” about always immediately crashing is answered as “true for some languages but not some others”. Even the motion of superlatives in CS like “always” and “never” rarely hold, including this very sentence and almost certainly when talking about multiple programming languages.

And on that point, it’s a minor quibble, but while Go’s nil pointers are similar to C null pointers and Rust’s null raw pointers, it’s a strange thing to have the title be about falsehoods about null pointers.

But then much of the other supposed falsehoods are addressed only for the C language, such as null deference being UB or not.

9. On platforms where the null pointer has address 0, C objects may not be placed at address 0.

I would like to see a ©itation [pun intended] for this being a supposed falsehood, since my understanding is that if an implementation uses 0x0 as the null pointer, then the check for a null pointer is to check if it’s equal to 0x0, which would require that no “thing” in C use that address.

I think the other commenter comparing this to the Quebec/French system of land division has it right. From satellite view, you can see the distinct shape of narrow strip lots perpendicular to the flow of the Bayou Lafourche. In the distant past, waterway access then was the equivalent of truck access from the Interstate freeways today: paramount for getting goods to market.

Can’t Python be translated into machine code

Yes, and that’s basically what the CPython interpreter does when you call a Python script. It sometimes even leaves the result laying in your filesystem, with the extension .pyc . This is the byte code (aka machine code) for CPython’s implementation of the Python Virtual Machine (PVM).

and packaged into a binary?

Almost. The .pyc file is meant to run with the appropriate PVM, not for x86 or ARM64, for example. But if you did copy that .pyc to another computer that has a CPython PVM, then you can run that byte code and the Python code should work.

To create an actual x86 or ARM64 binary, you might use a Python compiler like cython, which compiles to x86 or ARM64 by first translating to C, and then compiling that. The result is a very inefficient and slow binary, but it is functional. You probably shouldn’t do this though.

While I get your point that Python is often not the most appropriate language to write certain parts of an OS, I have to object to the supposed necessity of C. In particular, the bolded claim that an OS not written in C is still going to have C involved.

Such an OS could instead have written its non-native parts using assembly. And while C was intentionally designed to be similar to assembly, it is not synonymous with assembly. OS authors can and do write assembly when even the C language cannot do what they need, and I gave an example of this in my comment.

The primacy of C is not universal, and has a strong dependency on the CPU architecture. Indeed, there’s a history of building machines which are intended for a specific high-level language, with Lisp Machines being one of the most complex – since Lisp still has to be compiled down to some sort of hardware instructions. A modern example would be Java, which defines the programming language as well as the ISA and byte code: embedded Java processors were built, and thus there would have been zero need for C apart from legacy convenience.

As it happens, this is strikingly similar to an interview question I sometimes ask: what parts of a multitasking OS cannot be written wholly in C. As one might expect, the question is intentionally open-ended so as to query a candidate’s understanding of the capabilities and limitations of the C language. Your question asks about Python, but I posit that some OS requirement which a low-level language like C cannot accomplish would be equally intractable for Python.

Cutting straight to the chase, C is insufficient for initializing the stack pointer. Sure, C itself might not technically require a working stack, but a multitasking operating system written in C must have a stack by the time it starts running user code. So most will do that initialization much earlier, so that the OS’s startup functions can utilize the stack.

Thjs is normay done by the bootloader code, which is typically written in assembly and runs when the CPU is taken out of reset, and then will jump into the OS’s C code. The C functions will allocate local variables on the stack, and everything will work just fine, even rewriting the stack pointer using intrinsics to cause a context switch (although this code is often – but not always – written in assembly too).

The crux of the issue is that the initial value of the stack pointer cannot be set using C code. Some hardware like the Cortex M0 family will initialize the stack pointer register by copying the value from 0x00 in program memory, but that doesn’t change the fact that C cannot set the stack pointer on its own, because invoking a C function may require a working stack in the first place.

In Python, I think it would be much the same: how could Python itself initialize the stack pointer necessary to start running Python code? You would need a hardware mechanism like with the Cortex M0 to overcome this same problem.

The reason the Cortex M0 added that feature is precisely to enable developers to never be forced to write assembly for that architecture. They can if they want to, but the architecture was designed to be developed with C exclusively, including interrupt handlers.

If you have hardware that natively executes Python bytecode, then your OS could work. But for x86 platforms or most other targets, I don’t think an all-Python, no-assembly OS is possible.

I also want to note that in the year 2025, GitHub still does not support IPv6. Folks behind CGNAT in IPv4-starved geos suffer, as does everyone developing for all-IPv6 networks. And it’s not like they can’t do it, seeing as their various subdomains like pages.github.com have working IPv6 already.

Very nice! How did you do your joinery? Glue? Screws? Pocket screws?

I suspect that PG&E’s smart meters might: 1) support an infrared pulse through an LED on the top of the meter, and 2) use a fairly-open protocol for uploading their meter data to the utility, which can be picked up using a Software Defined Radio (SDR).

Open Energy Monitor has a write-up about using the pulse output, where each pulse means a quantity of energy was delivered (eg 1 Watt-hour). So counting 1000 of such pulses would be 1 kWh, and that would be a way to track your energy consumption for any timescale.

What it won’t do is provide instantaneous power (ie kW drawn at this very moment) because the energy must accumulate to the threshold before sending a pulse. For example, a 9 Watt LED bulb that is powered on would only cause a new pulse every 6.7 minutes. But for larger loads, the indication would be very quick; a 5000 W dryer would emit a new pulse after no more than 0.72 seconds.

The other option is decoding the wireless protocol, which people have done using FOSS software. An RTL-SDR receiver is not very expensive, is very popular, and can also be used for other purposes besides monitoring the electric meter. Insofar as USA law is concerned, unencrypted transmissions are fair game to receive and decode. This method also has a wealth of other useful info in the data stream, such as instantaneous wattage in addition to the counter registers.