181–190 of 191 posts
Earlier quoted context omitted.
Especially ironic, given that Oracle is one of the nastiest and most aggressive companies at enforcing license terms.
There is no contradiction here. It's exceedingly simple: companies will take as much as they can and give as little as they can. That's why it's important to raise the bar on what they have to give and reject all permissive (non-copyleft) free software licences.
Earlier quoted context omitted.
I don't understand your comment. Oracle is hypocritical because like every company they take everything they can and give the minimum they have to? which part is hypocritical?
I'm incredulous that you don't understand, but I'll humour you. Let's see; If I giving away a product because I think it's for the betterment of mankind, and definitely not an attempt to rug-pull or anything like that: no, just for developer good will. Then I am offered a free service, and I do not use it for fear that there could potentially be some rugpulling, despite having a reputation for that myself: and the pr…
It's great to see more companies adopting OpenTofu, and especially larger ones! As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0]. If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated! [0]: https://github.com/opentofu/opentofu/re…
I'm really excited to see the end-to-end state encryption. I've always thought it was bizarre that Hashicorp didn't prioritize this.
Earlier quoted context omitted.
Would you classify k8s in this bucket?
I'm still debating that. Certainly on the one hand it seems like there's already dozens of different incompatible variants/tools/setups/workflows to learn [most of which will be zombies in 5 years]. If I had to pick -- my gut instinct is kubernetes will be around for 5 more years but won't be common in 20 years.
Earlier quoted context omitted.
Are there any plans for a conditional way to enable/disable modules that doesn't use "count"? For example: # current method module "foo" { count = var.enable_foo ? 1 : 0 } # better? module "bar" { enabled = var.enable_bar } Preconditions and postconditions fail the apply run if their condition doesn't validate, so those can't be used. I'd also really like to be able to say in an output block, "this value doesn't have…
Use CDKTF. All of these "how can I do X in HCL" just go away.
This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations.
[1]: https://developer.hashicorp.com/terraform/cdktf/concepts/fun...
Earlier quoted context omitted.
Use CDKTF. All of these "how can I do X in HCL" just go away.
I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1]. This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations. [1]: https://developer.hashicorp.com/terraform/cdktf/concepts/fun...
But I'll take that annoyance anyday over the absolute pain of HCL.
I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)
Earlier quoted context omitted.
I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1]. This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations. [1]: https://developer.hashicorp.com/terraform/cdktf/concepts/fun...
Once in a while, I forget to use Fn when I should. But I'll take that annoyance anyday over the absolute pain of HCL. I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)
We're seeing an uptick in open source projects getting relicenced to non-open licenses. Some projects are successfully forked and the userbase shifts, other times not. One theory of mine is that we can measure the risk that a project will be relicensed by looking at things like diversity of contributors, trademark ownership, contributor agreements, and license terms. Low risk projects include the Linux kernel (GPL, D…
Dual licensing also makes it IMHO less likely that a project "continues as proprietary". Example: Qt. I think "contributor agreements" are the biggest red flag. Though I like them for potentially upgrading a license (say from GPLv2 to v3), not that this always is a good thing.
Earlier quoted context omitted.
No, it's not inevitable. There are many technologies that will outlast my whole career: java, sql, tcp/ip, linux, to name a few. S3 will also certainly be around in 20 years.
That’s true. But when I was first learning Java, Java beans and Java Server Pages were the hotness. The last time I did production code in Java was writing Android apps that required knowing the Android SDK. Programming in Java in 2024 is nothing like it was in the 1990s when it was first embedded in Netscape Navigator - yeah I played around with it back then. When I was first using C and C++, I was writing Windows a…
Earlier quoted context omitted.
I'm not sure how Kubernetes is high risk, given the CLA is to CNCF. Similarly, CLAs to the Apache Foundation, the FSF or similar are probably pretty safe (in that they have a long term interest to be good custodians for the IP), and could be safer than projects that lack a CLA but don't have (or only a few) outside contributors. To me, the obvious questions are who owns the IP, and what are their incentives to mainta…
This is a good critique. Measuring intent of an organization may be difficult to do methodically and impartially, so it's not currently covered. Personally I was surprised to see Redis change license after Redis Labs promised not to change the license. I think that promise was made with good intent but overwhelming financial pressure that emerged later on swayed them.
I think there are a bunch of questions you can ask:
* Why is the software open source (if licensing/contractual requirements make it so, that's more likely to keep the status quo vs. corporate claims of "we open source")?
* Who owns the copyright/IP (and what's their reputation)?
* What would happen if the the license changes (is there an ecosystem that relies on it being open source, or is it a black box)?
* Who cares what the license is (e.g. BerkeleyDB was relicensed, which got old versions frozen in linux distributions, so no-one upgraded to newer versions, and replacements were written)?