Live data from Hacker News

HashiCorp adopts Business Source License

hashicorp.com

601–610 of 760 posts

Re: HashiCorp adopts Business Source License

#601
post #592
post #493

Earlier quoted context omitted.

> Does Amazon have any policies against offering AGPv3 software as a service? Each use of AGPLv3 licensed software has to be reviewed to ensure that the obligations of the license can be and will be met (and also screen for cases where it is known that the vendor of software does not prefer a company like Amazon import the software under a FOSS license). Today we use AGPLv3 licensed software internally, and include A…

>> Does Amazon contribute code changes back to the software projects they modified when offering them as a service? > Yes, but not all changes are appropriate for upstream. But the (modified) source is available to consumers of the service either way, under the AGPL?

> But the (modified) source is available to consumers of the service either way, under the AGPL?

If Amazon made an AGPLv3 licensed program available to others over a network, it would have an obligation to provide to anyone that has access to that program the complete corresponding source.

Today, there aren't any services from Amazon that offer AGPLv3 licensed programs as a service. An example that may come to someone's mind is Grafana, but there is a partnership there, and AGPLv3 is not the binding license in that case.

In my personal opinion, AGPLv3 compliance is not difficult, so long as the licensor of the software is committed to community-oriented copyleft enforcement principles [1].

[1] https://sfconservancy.org/copyleft-compliance/principles.htm...

Re: HashiCorp adopts Business Source License

#603
post #569

Earlier quoted context omitted.

> BPL/EPL/SSPL was always fully within the spirit of open source It literally is not, and they only exist in order to not be.

They exist so that you can continue to use hashicorp tools in your business for free and look at/change their source code like you would any other software. The one restriction is that you can't compete with their hosted services using their software. Which 99% of people who use their software have zero interest in. The "it's not fair! it's not real open source!" narrative is pumped up by companies like Amazon that f…

No, Open Source has always required that usage be unrestricted (Either Freedom 0 or OSD/DFSG points 5 and 6). Allowing any restrictions on usage tends to get political, as people use the license to push their specific issue, making it much harder to share and use code without issues.

Re: HashiCorp adopts Business Source License

#604
post #250

Earlier quoted context omitted.

I'm a huge fan of Pulumi. After HCP's license switch, I'm even more sure that Pulumi will be a clear winner over Terraform in the long term.

I really don’t think that was ever in doubt. You only need to use it for a very short time to find that the ergonomics are infinitely nicer than Terraform.

My biggest issue with terraform is concept of state file. It seems that Pulumi continues on this model. I wish someone came up with innovative idea of not needing state file.

Re: HashiCorp adopts Business Source License

#605

Earlier quoted context omitted.

Because they want it to be developed collaboratively, in the public eye, and for the good of all contributors. In other words, free as in freedom, but not free as in beer.

> In other words, free as in freedom, but not free as in beer. That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.) There's nothing in open source about friendliness or collaborative development. I'm not forced to take your advice or contributions just because I'm open source, so how could…

> That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.)

> There's nothing in open source about friendliness or collaborative development.

Your view of the meanings of "free" and "open source" software is very literal and narrow. I'm not trying to debate the technical definitions of those terms, because frankly, I don't care and I don't think they matter in this discussion.

The crux of what I am saying is this:

A company may choose to share their source code for others to benefit from, under the hope that large players will contribute back in some way rather than use the situation to the disadvantage of the upstream company.

In other words, they might hope to:

* Let hobbyists learn from and use their code for free.

* Let competing companies use their code, as long as they contribute something back (money, bugfixes, festures, community support, QA).

* Make their employees happy.

and they may not hope to:

* Empower other large companies to freeload--ie, profit without contributing back at all.

Yes, I understand that permissive open source licenses allow freeloading in a legal sense. That does not mean the upstream companies have to be happy about it, much in the same way that you're allowed to use your office's shared kitchen to microwave fish, but your colleagues do not have to be happy about it.

What about this is so hard to understand?

Re: HashiCorp adopts Business Source License

#606

Earlier quoted context omitted.

My perspective is more like the parent's. As someone who has grown up along with open source, I've found it surprising recently how up in arms people are about how critical the ability for anyone to commercialize a project is for the definition of open source. To me, I care a lot about whether I can see how software is implemented, and modify it for my own use, but it has never really occurred to me that I need to ha…

> why bother with this fight? Because companies keep bringing this fight.

No, companies keep making services with code I can read and modify for my own use, and people in the community keep bringing this fight to them because they're peeved that other companies can't commercialize that software that they didn't build.

Companies will naturally conclude they should just make proprietary software, which doesn't require a big fight. And I think that's a shame.

Re: HashiCorp adopts Business Source License

#607
post #503

Earlier quoted context omitted.

Yes, literally this, but without the smug. Have you ever set lenient guidelines, people took advantage of them in a way you didn't like, so you were forced to tighten your guidelines in a way you didn't originally want to? eg: a professor establishes a generous late homework policy, which most students use reasonably, except a few who decide to turn in everthing on the last day of the term and make the TA's lives hel…

For this analogy to work, it also needs to include the professor advertising their course and attracting good-will primarily on the basis of their generous policy, and then bait-and-switching involved participants when they later decided they didn't like it.

The professor could advertise their course this way for Term 1, realize their policy isn't working as intended, and then change their policy (and advertising) as of Term 2. That's not a bait and switch. There was no promise that their course would have the generous original policy in for all terms in perpetuity.

As far as I can tell, you are allowed to fork HashiCorp's code up until the point of license change, and continue to use it as you like, rebrand it as a new project, whatever. I could be wrong, but I don't think HashiCorp ever said "we will never ever change our license."

Re: HashiCorp adopts Business Source License

#608

Earlier quoted context omitted.

So here's my perspective on these two competing models: 1. I can read all of the code, modify it, and self-host it for my own purposes, but the license disallows me from re-selling it. 2. I can read, modify, self-host, and commercialize a subset of the code, and the rest is an opaque SaaS. To me, as a customer with no interest in re-selling this code, I don't see how #2 is better than #1 in any way. And I find it inc…

Convenience and reliability from a business perspective For #2 in good faith using the github model here, Sure there’s Git and Github. Also sourcehut, using google cloud source repository or any managed git service. Either 1) I need the software and I can have a team maintain it. Electing for the software-as-a-service vs self hosted model is in itself. 1. I can compute, resources, maintenance and time The proprietary…

Yeah I think you misunderstood my point a bit.

What I like best is to use a fully managed service that I can contribute changes or even self host a modified version if that's what I need to do to get what I need. But I don't want to self-host. But I highly value the option. And I highly value the ability to go read the code when I wonder "hmmm why is it doing that?" and maybe contribute a bug fix if it shouldn't be.

All of this works great with model #1 - with full "source available" with a license that limits re-sale - but is limited with model #2, where it only works for the "open core" portions of the product, but not the proprietary SaaS portion.

Re: HashiCorp adopts Business Source License

#609
post #496

Earlier quoted context omitted.

And this is why I think people who love Software Freedom should think twice about signing a CLA for their copyleft licensed contributions. [1] inbound=outbound license terms is a good norm for FOSS. Why should a software vendor play by different rules than everyone else when it comes to things like copyleft compliance? [1] https://meshedinsights.com/2021/06/14/legally-ignoring-the-l...

From a pragmatic perspective, it is much easier to enforce an open source license with a lawsuit if you own 100% of it.

This is true. The question to me is: does the party to whom you give the rights and authority subscribe to community-oriented FOSS license compliance principles? [1]

[1] https://sfconservancy.org/copyleft-compliance/principles.htm...

Re: HashiCorp adopts Business Source License

#610

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Focal_point_(game_theory) If we don't have a common definition, everyone has their own, and there's no common understanding of what rights you have for a piece of Open Source software. That commons has far far more value than any one or ten pieces of software.

> That commons has far far more value than any one or ten pieces of software. I don't think so. I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble ima…

What would you change then? Practically only the 4th criteria would be one I'd change (but presumably it's there for a reason): "Integrity of the author's source code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software."

As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point.

Post reply on HN