HashiCorp has just announced that they are switching from the MPL 2.0 license to the BUSL 1.1 license. While OSI does not recognize the BUSL license as open source, it does make the source available. The reason it is not considered an open source license is because it places restrictions on commercial use.
I am not sure if many of you are familiar with HashiCorp. They are the company that makes DevOps software tools. Several of them are either industry standards or at least really prominent in the industry for use by DevOps and Site Reliability Engineers. Terraform is the industry standard for infrastructure as code, and while I have not looked into them myself, I know Vault (secrets management) and Packer (build system and container images) are popular.
There was a time when open source software was largely written by individuals.
Does this mean we are going back to that demographic?.
It may not be a bad thing… software from cooporate activities is some of the most criticised software ever written.
Thank you for mentioning me!
I believe more and more companies are adopting this kinda of licenses. That is reasonable, but I don’t believe is the right way.
Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.
It slows down development of new technology. It really is a strategy to gain a stronger position in terms of concurrence with other companies.
However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.
This is the “reason” why they adopted it. But if it was really for that a GPL license would solve any problem.
Another License that kept my attention is the llama license provided by meta. It request legal accord to companies that use their technology with more than 700 million monthly users.
All of this is still better then having it closed source. At least we gain transparency. But it is just a way to take the most of the market and from the community without risking to have concurrence. Concurrence is the thing that push for the development of new technologies, and governments should try to keep it high avoiding monopolies.
I don’t have a solution. But I think that something between the needs of companies and the needs of the market must be found.
You identify the issue clearly.
Companies are eager to get a lift by using open source code, but when they develop it they are disinclined to share their improved code.
This is creeping into scientific computing too. Research funding bodies sometimes ask for non-disclosure of results. It defeats the purpose of research.
I agree its not a good look and I am not happy with it. I am sort of in a position to keep learning and using Terraform because knowledge of it is pretty important in DevOps. I might try out Pulumi sometime because apparently that IaC tool is staying FOSS software.
I think HashiCorp is in a bit of a tough spot. I understand their decision even as I disagree with it. Their software is important now, but who says it will be the case in 3-5 years? Trying to tell their investors “Well, we make our source code available because we believe in FOSS software” is not really an answer in those same investor’s minds. Some companies have either found a good enough answer to those investors’ concerns, or don’t have investors who are concerned about it.
That’s sad. Allowing access to software/research/results/papers has been a thing in Academia much longer than the concept of FOSS software has been around.
I agree - I think they had the wrong license to being with.
People are not always able to pay, especially students.
The Church model of ‘putting something on the plate’ should be considered
Indeed, as you say, too much money can be worse than not enough.
A lot of the Ukraine war funding is voluntary
What we have with free software is a bit like a barter system with pooling… you take something out for free, so there is a moral obligation to put something back.
Universities are holding out, insisting on right to publish, but other research bodies ( like CSIRO) have succumbed because they depend on research grants, and grant bodies have the upper hand to insist on things like patenting and secrecy. I even know of a case where
a funding body asked for results to be destroyed.
Hey Neville, I think you accidentally added this comment to the wrong thread. I will respond here, just because you posted it here.
There are ways to do this with a paid application. E.g. if the application is relevant for studying then maybe the Universities can get licenses (which could be give free) or maybe the use of a school email address could still allow free copies. Obviously it would be up to the people in charge of the applications to figure out when and how people pay (or don’t pay) - which is how it is now.
When this works well, it is the best. I think this way works most of the time - obviously the biggest projects have no problem attracting donations and people contributing code. Some applications require lost of resources though, in those cases is when it starts to make more sense to charge. It can also result in applications being a lot better tested, translated into more languages, ect.
What I mean when I say this is just - I am willing to pay for an app or an OS that is worth it. I am willing to donate to an app that is free because it is worth it. In the future, there will probably be some FOSS apps that cost money - maybe not many (like right now), but that doesn’t mean it is unreasonable.
Absolutely. I am not sure how it would be set up 100% (e.g. if you contribute to the code maybe you get the app for free?) but certainly you would get the source code if you payed. It wouldn’t be FOSS if you didn’t get the source code.
That is true. Although an app that might require significant money investment might not necessarily have a lot of dependencies, it might just be complicated to make. I do think you are correct though - a lot of the apps that are complicated are complicated because they have a lot of dependencies. In such a case, it might be wise to split them into smaller apps if possible.