I agree with you the "source available" is overstretched. It's hard to come up with a good new label for the first group. Maybe "Open Use" or "Fair Source".
Most source-available licenses that I've encountered have no paid license requirements for users. They only require a paid license if you want to sell the product commercially. Normally, you're still allowed to use the software as a piece of a larger commercial product, as long as it does not compete with the original author, or "substantially reproduce the functionality" of the source-available bits, depending on the exact language.
"Open Source" can also become "Source Available" overnight. See Redis, Terraform, etc. In the same vein, "Open Source" can also become "Closed Source" overnight.
In neither case does the change apply retroactively. It only applies to new contributions after the license change.
Well technically Redis had a fork before it became source available known as valkey which is still in bsd license
Terraform was forked to create opentofu if I remember correctly
I think the most recent example is kind of minio for this type of thing no?
Also I am interested what are some open source projects which became closed source since it seems that you haven't named any and I am curious how they can do that. There must be some legal laws protecting it.
If a project switches from an open-source to a closed-source license, then from the outside, it just looks like the project was abandoned. The final commit that was published under the open-source license will always be open source. It's the future commits that are now closed source.
So no, I don't have any specific examples of that happening.
In the case of both Redis and Terraform, the forks were announced after the license change, not before. Indeed, the forks were motivated by the license change. The community didn't get a warning "hey, we're about to change the license, fork it while you still can!". It just changed.
That's what I mean when I say the license change does not apply retroactively. The commit of Terraform that existed before the license change is still open-source. I could create a fork branching off that commit today if I wanted to.
The BUSL license requires shifting to an open-source license no later than 4 years after publication. I'd be happy to contribute to a BUSL-licensed project knowing my contributions will shift to an MIT license within 4 years.
And the original authors don't have to worry as much about Amazon eating their lunch.
Good for you; you seem like a trusting person. I'd recommend against spending your time on that. Or at least try to get paid for it.
I tend walk away from anything with a shared source license. I don't invest my time in it. I don't finish reading the README. It's an instant red flag.
"Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License" ... "To specify as the Change License the GPL Version 2.0 or any later version, or a license that is compatible with GPL Version 2.0 or a later version, where “compatible” means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version"
I don't think this needs to be banned, particularly because it wouldn't be very effective (people would just get rid of the "AI said" part), and also because anybody who actually writes a comment like that would probably get downvoted out of the conversation anyway.
Why introduce an unnecessary and ineffective regulation.
Margins require a competitive edge. If productivity gains are spread throughout a competitive industry, margins will not get bigger; prices will go down.
Every rule has exceptions. Usually its because of some quirk of the market. The most obvious example is adtech, which is able to sustain massive margins because the consumers get the product for free so see no reason to switch and the advertisers are forced to follow the consumers. Tech in general has high margins but I expect them to fall as the offerings mature. Companies will always try to lock in their users like aws/oracle do but thats just a sign of an uncompetitive market imo.
"Building software" is a bit too general, though. I believe "Building little web apps for my son's school" has gotten at least 10x easier. But the needle has not moved much on building something like Notion, or Superhuman, or Vercel, or <insert name of any non-trivial project with more than 1000 man-hours of dev work>.
Even with perfect prompt engineering, context rot catches up to you eventually. Maybe a fundamental architecture breakthrough will change this, but I'm not holding my breath.
Yeah, that's not a comparison to the kinds of highly complex internal systems I worked with the Fortune 1xx companies, particularly the regulated ones (healthcare). The whole "my son's school" thing is very nice, and it's cool you can knock that out so fast, but it's nothing at all like the environments I worked in, particularly the politics.
While I hate defending GHA, the docs do include this:
- Using the commit SHA of a released action version is the safest for stability and security.
- If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author.
So you can basically implement your own lock file, although it doesn't work for transitive deps unless those are specified by SHA as well, which is out of your control. And there is an inherent trade-off in terms of having to keep abreast if critical security fixes and updating your hashes, which might count as a charitable explanation for why using hashes is less prevalent.
On the other hand, this issue has been known to GitHub since shortly after Actions’ release[0]. They added some cya verbiage to their docs, but they never followed up by making version pinning meaningful.
Sure you can implement it yourself for direct dependencies and decide to only use direct dependencies that also use commit sha pinning, but most users don’t even realize it’s a problem to begin with. The users who know often don’t bother to use shas anyway.
Or GitHub could spend a little engineer time on a feasible lock file solution.
I say this as somebody who actually likes GitHub Actions and maintains a couple of somewhat well-used actions in my free time. I use sha pinning in my composite actions and encourage users to do the same when using them, but when I look at public repos using my actions it’s probably 90% using @v1, 9% @v1.2 and 1% using commit shas.
[0] Actions was the first Microsoft-led project at GitHub — from before the acquisition was even announced. It was a sign of things to come that something as basic as this was either not understood or swept under the rug to hit a deadline.
There's a repository setting you can enable to prevent actions from running unless they have their version pinned to a SHA digest. This setting applies transitively, so while you can't force your dependencies to use SHA pinning for their dependencies, you can block any workflow from running if it doesn't.
- Using the commit SHA of a released action version is the safest for stability and security.
This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.
Depends what you mean by stability. The post is complaining about the lack of lockfiles, and the problem you describe would also be an issue with lockfiles.
Using an SHA is an anti-pattern for me. Because by using one, you kind of modeled "I am getting this fixed/static thing"; when in reality, it is very far from that. I got bitten by it twice that I learned that you either have a lock file or you don't.
Ya, I'm not a big fan of that use case, and I agree it's a problem. But I hold Bitcoin as a hedge against inflation. It tends to do better than gold, and is way easier to transact and store.
reply