5 ms·
One is best not to make any decisions on how something will be in the future. This goes for pre ordering games, to buying software licenses, to opensource contr
by pacifika 3y ago
One is best not to make any decisions on how something will be in the future. This goes for pre ordering games, to buying software licenses, to opensource contributions.
People contributed to the software as it was licensed then, and this software is still available under the open source license and can’t be taken away. Unfortunately that gives no guarantees about future versions or versions that never got made.
- galenmarchetti 3y ago100% agreed with you...would be safest for everyone to take this stance going forward. I do think, and I could be wrong, that not everyone realized that the licensing worked this way. Or had their guard up when contributing. I think that's the issue...perhaps their fault, perhaps not, but I see the issue. I wonder if this will be an example moving forward that people keep in mind when contributing to any OSS project
- elashri 3y agoDoesn't this mean that people will be more cautious and less likely to contribute on the long run? I mean that feels like it is against the spirit of open source movement. And yes I realize that this is idealistic position and the legal aspects gets the upper hand at the end. I just wish things didn't go this way.
- galenmarchetti 3y agoI imagine so...I wonder if its possible to draft an open-source license that commits future versions of the project to be drafted under the same license. Maybe AGPL does this (?) I know AGPL applies to all "modifications", I wonder if that applies to modifications done by the maintainers themselves in the future. If so, maybe we'll see AGPL-like provisions becoming more popular in order to help folks feel more confident
- yjftsjthsd-h 3y agoAny copyleft license should so that so long as there's no CLA / transfer of copyright.
- wbl 3y agoWell it does if your contributions are made under the GPL and not transfered via a CLA.
- quickthrower2 3y agoWith terraform “keeping up with the latest” is way more important than say regular libraries and tools like ReactJS. A 5 year old react would mostly work fine (patch the odd bug if need be). Indeed look at Elm. But terraform is coupled to the moving target of cloud services.
- networkchad 3y agoI think I get the point of your comment but can you expand? For instance, I’ve resorted to pinning a specific terraform version and plug-in version in a custom docker container. I can use the same TF scripts I wrote 4 years ago against the AWS API which has not changed since.
- quickthrower2 3y agoYes I think your case is OK. The question is more say your team decides to use a new feature, let's say it is GPT5 via Azure for example, with TF. Then you need to keep up to date. I am not heavily into TF so I don't know if that is possible with the pinned terraform and using later providers versions or how that works. But it seems more hassle than just using the latest of everything. Note I am talking about "keeping up" as a general need for IaC - but it might turn out that the TF fork is a better place to do that in the long term. Time will tell.
- networkchad 3y agoGotcha. I misunderstood the keeping up context. I chased TF version updates for a while before being annoyed at having to retool significant parts of my long existing scripts. I gave up and just stuck to a version for what I needed. My only concerns is I may neglect a security update, but this is for personal stuff and not for anything that others use/consume.