Colloidal

~~functional~~ programmers when they look at their code 2 years later

FTFY

Seems like it it isn’t related to Silverlight at all.

First of all thank you for your thoughtful response. I do disagree on a few key points though:

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.

When you can still use code from a license and distribute the end result under a different license, that means they are compatible. Just like the MIT is compatible with any other license.

if OpenTofu starts to gain new features that Terrarform doesn’t have, Hashicorp can incorporate those features but they won’t be unique.

So they are benefiting from improvements made in OpenTofu.

Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free?

To access the features that are exclusive to Terraform. Companies spend unglodly amounts of money to pay for MS Sharepoint (completely different product, just giving an example of an expensive product with competitive groupware options in the market). Why wouldn't they pay for Terraform, especially if it included a support contract? I think you are severely underestimating the willingness of customers to pay for service if you don't think that would happen.

And all features henceforth developed for Terraform would be exclusive to it, while all features developed for OpenTofu would be available to Terraform because the MPL is such a pushover license that doing so is trivial. OpenTofu will always stay behind in this scheme. In other words, any developer contributing to OpenTofu is donating work to IBM. I bet they are more than okay with that.

Had they moved new OpenTofu contributions to a strong copyleft license, OpenTofu would lose nothing, while Hashicorp/IBM would lose the freeloading of FOSS developer's contributions. IBM still has an out in this scenario, which is offering services to paying customers, just like Hashicorp did before the licensing fiasco. It's a lucrative business model, and one they are good at.

Like an .ini file.

I don’t get it. Why go through the trouble and stay in a license that still allows Hashicorp / IBM to benefit from community contributions?

What about it makes it 2D?

Do we have a c/keming?

Who knows? Maybe it just needs a big, big push, like Wayland.

I’m happy to help! Good luck!

Put it this way: when you use GIMP to create a picture, your picture doesn’t have to be GPL. The image you created is your creation, you decide what license, if any, it’ll have. What the GPL demand is that if you make a change to the GIMP code and share that improved version, you have to do so as GPL.

Likewise, people using your language to create their stuff are free to license whatever they create how they please. They do need to share their improvements to your tools as GPL though.

So perhaps the best option for you is to license the runtime for your language (and some basic libraries) as LGPL so people can link to them with their creations. And everything else that isn’t meant to be linked with the user program at runtime can be licensed as GPL.

If you plan on making money off of your software, dual license AGPL and commercial. True open source developers can benefit from your work for free and contribute, while clients that would rather not have GPL can pay you.

The reason for AGPL is to prevent people taking your GPL code, changing it, hosting it as SaaS, and never disclosing their changes as technically they’re not distributing the software.

Also, your non core business libraries are the most prime candidates for GPL/AGPL. You want to benefit from community contributions to those, not bear the full cost of development and give it away for free without getting anything in return.