devopsy.kinsta.cloud

Category: News

GitLab Adds AI Chat Interface to Increase DevOps Productivity

GitLab this week announced the general availability of GitLab Duo Chat, a natural language interface through which DevOps teams can invoke generative artificial intelligence (AI) to generate code, create tests and access summarizations of code. It is available as an add-on to the GitLab Duo Pro AI framework, which the company is embedding across its DevOps platforms. GitLab Duo Chat can be invoked via the GitLab user interface or GitLab’s web integrated development environment (IDE) in addition to third-party IDEs, including VS Code and the IDE provided by JetBrains.

Over the last few years, GitLab has been working with Google to embed a range of AI capabilities into its core platform. With the addition of GitLab Duo Chat, these are now more accessible.

As part of that effort, GitLab is also now adding privacy controls for GitLab Premium and Ultimate customers. These enable organizations to control sensitive data at the project, group, and subgroup levels to address security and compliance concerns.

David DeSanto, chief product officer for GitLab, said as AI capabilities become more accessible, the pace at which applications can be built and deployed is about to significantly accelerate. The most immediate impact should be a reduction in the number of instances where builds fail to deploy because the quality of the code used to construct them has improved, he added.

AI should make it easier for subject matter experts who have little software engineering expertise to participate in the application development process, noted DeSanto.

The immediate challenge DevOps teams will encounter is to determine how best to employ the prompts to generate code and tests within the context of their existing DevOps workflows. Over time, however, as the reasoning engines embedded within the large language models (LLMs) that are at the core genAI platforms improve, it will become feasible to automate a series of actions involving multiple tasks, DeSanto noted.

In the meantime, DevOps teams should start determining which manual tasks might be automated using a generative AI platform. In many organizations, there are still numerous bottlenecks in DevOps workflows that conspire to slow down the pace of application development.

AI platforms are unlikely to eliminate the need for application developers and software engineers any time soon. However, many scripts that DevOps teams have historically written themselves will soon be written and tested by machines. DevOps teams will soon find themselves supervising the development of more applications that, in addition to being constructed faster than ever, are less troublesome to update and maintain without having to add a small army of software engineers. The tradeoff is the overall size of the codebases that DevOps teams will be expected to manage is about to substantially increase, noted DeSanto.

In an era where organizations are more dependent than ever on software, the demand for applications already exceeds the ability of DevOps teams to address. AI should enable DevOps team to build and deploy applications at a level of scale that only a couple of years ago would have seemed unimaginable.

Photo credit: Ondrej Supitar on Unsplash

April 19, 2024
Datadog DevSecOps Report Shines Spotlight on Java Security Issues

Datadog today published a State of DevSecOps report that finds 90% of Java services running in a production environment are vulnerable to one or more critical or high severity vulnerabilities introduced by a third-party library, versus an average of 47% for alternative programming languages.

Based on an analysis of IT environments being monitored using the Datadog platform, the report also notes 63% of high and critical vulnerabilities in Java applications derive from indirect dependencies that are traced back to third-party libraries that have been indirectly packaged with an application.

The report also notes that Java applications are disproportionately affected by the Known Exploited Vulnerabilities (KEV) catalog of vulnerabilities compiled by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Java applications can be impacted by 55% of these vulnerabilities, compared to 7% for other programming languages.

Just under a quarter of Java services (23%) are vulnerable to remote code execution (RCE), impacting 42% of organizations, according to the report.

It’s not clear to what degree organizations might be willing to abandon Java to improve application security, but there are already millions of Java services running in enterprise IT environments that DevSecOps teams need to secure.

Andrew Krug, team lead for security evangelism at Datadog, said it’s not likely organizations will resolve application security issues overnight. Instead, they should be focusing on continuous improvement over time that relies more on automation to ensure best DevSecOps practices are implemented and maintained. The report notes that 38% of organizations running applications in Amazon Web Services (AWS) were still manually deploying applications using “ClickOps” processes versus relying on a continuous integration/continuous delivery (CI/CD) platform.

The biggest challenge with DevSecOps is that not every vulnerability is always present in every application. The Datadog report, for example, noted that while the average service is vulnerable to 19 vulnerabilities, only 5% of vulnerabilities are being actively exploited.

DevSecOps teams should also assume every vulnerability rating is accurate. Datadog applied the Exploit Prediction Scoring System (EPSS) to rank the criticality of vulnerabilities. After applying an adjusted score, 63% of organizations that had vulnerabilities with a critical CVE severity no longer have any critical vulnerabilities. Just under a third (30%) of organizations saw their number of critical vulnerabilities reduced by half or more.

The report also noted that the smaller a container image is, the fewer vulnerabilities it is likely to have. On average, container images smaller than 100 MB have 4.4 high or critical vulnerabilities, versus 42.2 for images between 250 and 500 MB, and almost 80 for larger images.

In general, DevSecOps teams need to carefully evaluate not just how serious a vulnerability is, but also whether the vulnerability can be reached and is running, whether there is a known exploit and whether the software containing the vulnerability is running in a production environment. That’s critical because in 2023 there were more than 4,000 high and 1,000 critical Common Vulnerabilities and Exposures (CVEs) identified, but not every one of them represents the same level of actual risk to a business.

The Datadog report also noted automated security scanners employed by cybercriminals are more of a nuisance than an actual threat. Out of tens of millions of malicious requests that we identified coming from such scanners, only 0.0065% successfully triggered a vulnerability. It’s more important to have a framework to prioritize better prioritize alerts by monitoring raw web server logs or perimeter web application firewall (WAF) alerts. Failing to triage those alerts ultimately leads to a higher level of fatigue that, when vulnerabilities are missed, leads to higher levels of security nihilism, resulting in IT teams being blamed for breaches that are not really their fault, noted Krug.

It’ll be a while before software supply chains become more secure, but the one thing that is certain is that determining which vulnerabilities require immediate attention is critical to ensure developers still have enough time to build and deploy additional applications.

April 17, 2024
From CEO Alan Shimel: Futurum Group Acquires Techstrong Group

I am happy and proud to announce with Daniel Newman, CEO of Futurum Group, an agreement under which Futurum has agreed to acquire Techstrong Group. The combination of these organizations will create a new, powerful force in the world of tech analysis and media that will scale great heights and do tremendous things.

Even though I will continue to man the helm at Techstrong, today’s announcement is a marking stone to a new era. It was a little over 10 years ago I decided to start a tech media company dedicated to DevOps, on the advice of my friends Brad Feld and Rajat Bhargava.

After spending almost 20 years in the world of software, infrastructure and security startups, I was done being a vendor. After leaving StillSecure, I performed consulting for several security vendors and end users and spoke at many events. But I was so sure that DevOps was going to change the landscape that I decided to try my hand as a publisher to build a “big tent” to the myriad voices in DevOps.

I believed DevOps was going to be the best thing to happen to security (or cyber, as it is called now) for a long time. I had already decided that if the DevOps site went well, we would follow up with a cybersecurity site using the Security Creators Network. One day, perhaps, I will write a book about the actual goings on behind all of this and how we accomplished it without raising any money and were profitable from day one.

These past 10 years have been possibly the best of my life. My children grew up and went away to college and beyond. My wife Bonnie and I have seen our horizons expanded beyond what we had only dared to dream. I have traversed the globe (probably several times) and seen much of what this world has to offer.

My greatest pleasure, though, has been growing Techstrong to what it is today. Not just the company, but the people. I have been blessed to be able to help so many people realize their dreams, grow their careers and live their lives in ways they couldn’t have before—in ways great and small, to help them be their best. This is what I am most proud of and grateful for.

I’ll tell you what else I am proud of and grateful for: You! Allowing us to be your source of technical information and getting to know so many of you over the years has enriched my life beyond description. No matter where I travel in the world, I know I have friends and acquaintances to make my visit even better. I could never thank you enough for that. Building our friendship has been an extraordinary experience, along with building our relationship with clients.

“As a longstanding client, we have collaborated with the Techstrong team to consistently create high-value and engaging research studies, webinars, and events. Alan Shimel successfully established a media organization squarely focused on the software development and security industry,” says Sacha Labourey, co-founder and chief strategy officer, CloudBees. “We are eager to experience the enhanced opportunities that the merger of Techstrong and The Futurum Group will offer CloudBees, particularly in terms of technology-focused research and access to its executive-level audience.”

Now to the next chapter. The winds of change are blowing and have been for more than a year. I have always believed that with change comes opportunity. In even less time than I built Techstrong, Daniel and the Futurum team have built a very successful business. Over the last months and weeks, it’s become crystal clear that our businesses are complementary in so many ways. As we said in our joint announcement, the synergies here are ballistic.

Media—especially tech media—and the analyst world are undergoing profound change. New technology, new consumption habits and new requirements for influence and growth are creating seismic shocks. Yesterday’s leaders are grasping for handholds to steady and support them through the turbulence. Every time these cycles play out, great successes emerge. We are on the cusp of such greatness again. Adding Techstrong to the Futurum Group’s existing business has positioned Futurum to dominate our space.

I am excited for this new chapter. Our mission is to build the leader in tech analysis and media, delivering next-generation results and content to market. We will need your help and support. Please join me, Daniel Newman and the rest of the team as we set sail to go where no tech analyst/media firm has gone before (cue the Star Trek theme)!

April 17, 2024
CDF Survey Surfaces DevOps Progress and Challenges

A global survey of more than 10,000 developers conducted by the Continuous Delivery Foundation (CDF) finds 83% of developers are involved in DevOps-related activities, with a third (33%) actively using continuous integrations tools, monitoring tools to track infrastructure performance and testing applications for security vulnerabilities.

Revealed today at the cdcon event, another 29% of respondents said they were actively involved in continuous delivery/deployment. The most widely used DevOps tools and platforms are source control management (29%) and issue tracking (28%), but only (21%) said they build continuous integration/continuous delivery (CI/CD) pipelines.

According to Mark Waite, community manager for CloudBees, the survey results said that while DevOps practices are widespread there is a clear need for organizations to achieve higher levels of maturity given the uneven adoption of best practices. For example, only a quarter (25%) of respondents said they programmatically manage infrastructure.

Overall, the survey suggests that organizations are on a DevOps journey that results in specific DevOps practices being adopted to meet unique requirements versus adopting a set of standards that are universally applied, Waite noted.

For example, the survey finds only 14% of respondents implement code changes daily, while another 17% require less than a week. More than two-thirds (68%) require a week or more, the survey finds. Similarly, only 9% deploy code multiple times a day, while another 20% are somewhere from once per hour to once per week. Only 11% said they could restore a service in less than an hour.

Those percentages have remained relatively consistent for the three years the CDF has been conducting this survey. However, the survey indicates that organizations that use managed CI/CD platforms are slightly more productive than organizations managing these platforms themselves. However, the report also notes that organizations using multiple CI/CD platforms tend to be less productive than those that have standardized on a single platform.

It’s not clear to what degree organizations are coping with the rise of platform engineering. The methodology, meant to manage DevOps workflows at scale, is standardizing DevOps tools and platforms. Historically, each DevOps team has tended to prefer whichever tools and platforms it selects, but over time multiple platforms can result in both higher levels of friction and increased costs.

Ultimately, no one-size approach to DevOps fits every organization. The one thing organizations that are committed to DevOps share is a commitment to higher levels of automation. In fact, with the rise of artificial intelligence (AI) the next era of DevOps is dawning.

In the meantime, finding and retaining software engineers remains an issue. There has been an ongoing effort to shift more responsibility for IT operations toward developers. However, as the cognitive load placed on developers increases, the amount of time they have to write code decreases. Not every developer writes code 100% of the time, but the less time developers spend focused on code the less productive they will be in terms of the amount of code that make it into a production environment. The challenge, as always, is striking the right DevOps balance.

Photo credit: Marc A on Unsplash

April 16, 2024
The Commonhaus Way to Manage Open Source Projects

Long-time Java developers may recall Codehaus, which combined a Java open source project hosting service and community. Now, inspired by its legacy, a new group of developers has established the Commonhaus Foundation.

At its core, Commonhaus embodies a vision of providing a neutral harbor for established open source libraries and frameworks seeking a home. The foundation’s mission is to ensure a nurturing environment where projects can flourish unabated, transcending generations of technology evolution.

Now, you may say that we already have this scenario with such organizations as the Apache Software Foundation, the Linux Foundation, and the OpenInfra Foundation. That’s all true, but they have clearly defined patterns for their child foundations.

What sets Commonhaus apart is its emphasis on offering guidance and support instead of imposing mandates. Instead of setting rules for how an organization must be set up and run, it empowers projects to navigate in their own way.

Its key principles include succession planning, which addresses the always tricky question of the “bus factor.” That is, it addresses how an open source project can keep going if one or more of its leaders die in a bus accident. The foundation addresses this by providing an intricate web of leadership transitions and contributor changes with grace, thereby safeguarding their influence and functionality over time.

Erin Schnabel, a founding member and chairperson of the Commonhaus Foundation, articulated the rationale behind this initiative. “The open source ecosystem has undergone profound transformations in recent years,” Schnabel remarked. “While existing foundations have laid the groundwork for numerous successful projects, the advent of fiscal hosting platforms and self-governance models has unveiled a clear need for a fresh approach.”

“Traditional governance structures may not align with the unique needs of projects that have cultivated their own practices and infrastructure,” Schnabel continued. “These projects often face hurdles when considering merging into existing foundations, leaving crucial needs unaddressed. Commonhaus seeks to bridge this gap, ensuring that projects of all stripes receive the support they need to thrive.”

Trisha Gee, a distinguished software engineer and Java Champion, echoed Schnabel’s sentiments. “Commonhaus fills a crucial void in the support ecosystem for open source projects,” Gee asserted. “Its focus on community and continuity is paramount for ensuring sustainability and mitigating maintainer burnout. Successful projects shouldn’t have to compromise their autonomy to access foundation support.”

The roster of projects joining Commonhaus at its inception reads like a Who’s Who of the open source world, including Hibernate, Jackson, OpenRewrite, JBang, JReleaser and Morphia. What these projects have in common is a desire for a stable, nurturing home without having to shift existing governance structures.

Gavin King, Red Hat distinguished engineer and parent of Hibernate, offered another reason to join Commonhaus. “We’ve never really overcame the perception that this is a project dominated by one company,” King said. “That’s something we want to finally change. Red Hat’s leadership and sponsorship have been a source of stability, continuity, and user confidence, and we don’t wish to undermine that. But what we would like to do now is open up space for other groups and companies also to feel included in the project.”

The Foundation extends an open invitation to developers, contributors, projects and sponsors to join its cause. Through sponsorship on platforms like GitHub, individuals, and organizations can not only provide financial support but also shape the strategic direction of open source development.

As the Commonhaus Foundation sets sail on its maiden voyage, it aims to chart a course toward a future in which open source projects can continue to thrive unfettered by the specter of obsolescence.

Photo credit: Luke Southern on Unsplash

April 15, 2024
OpenTofu Denies Hashicorp’s Code-Stealing Accusations

It’s been ages since copyright conflicts have been an issue in open source circles, but they emerged when HashiCorp accused OpenTofu of “not respecting the terms of its BSL license governing its Terraform codebase.” OpenTofu denied Hashicorp’s accusation that it had stolen any of the Terraform Business Source License (BSL) code. Now, OpenTofu‘s law firm, Gesmer Updegrove, has formally denied Hashicorp‘s accusation.

Hashicorp did more than claim OpenTofu had misappropriated some of its code. Its law firm, Wilson Sonsini, issued a cease-and-desist order against OpenTofu. This read in part, “This is a cease and desist demand to the supporters of the OpenTofu project. Specifically, OpenTofu has repeatedly taken code HashiCorp provided only under the Business Software License (BSL) and used it in a manner that violates those license terms and HashiCorp’s intellectual property rights. In at least some instances, OpenTofu has incorrectly re-labeled HashiCorp’s code to make it appear as if it was made available by HashiCorp originally under a different license.”

The order continued, “Therefore, we demand that OpenTofu … cease and desist from further violations of HashiCorp’s BSL license and infringement of HashiCorp’s copyrights. If OpenTofu does not comply, we reserve all rights, including the right to send DMCA takedown notices to Github or any other third-party hosting or source code repository provider, and the right to initiate litigation to stop further violations.”

OpenTofu replied, “The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code. All such statements have zero basis in facts.” In addition, it said, HashiCorp’s claims of copyright infringement are completely unsubstantiated.

Where’d the Code Come From?

As for the code in question, OpenTofu claims it can clearly be shown to have been copied from older code under the Mozilla Public License (MPL) 2.0. “HashiCorp seems to have copied the same code itself when they implemented their version of this feature. All of this is easily visible in our detailed SCO analysis, as well as their own comments.”

In a detailed source code origination (SCO) examination of the problematic source code, OpenTofu stated that HashiCorp was mistaken. “We believe that this is just a case of a misunderstanding where the code came from.” OpenTofu maintains the code was originally licensed under the MPL, not the BSL. If so, then OpenTofu was perfectly within its right to use the code in its codebase.

OpenTofu’s attorney said, “Both the OpenTofu files to which you refer and HashiCorp’s Terraform files to which you compare them are both derived (at least to some degree) from the pre-fork MPL-2.0 files – code that was made publicly available under the MPL.” Therefore, “To my client’s knowledge, none of the Terraform code subject to the BUSL has been improperly copied, incorrectly sourced, or used for any purpose.”

The attorney went on to say that HashiCorp should have known this. “[W]hile you complain that a comparison of HashiCorp Terraform code to OpenTofu files show ‘substantial similarity’ between the two, the diff files you attach to your Letter actually show the compared files to be quite dissimilar.”

The OpenTofu lawyer continued, “Going forward, we would be open to establishing developer liaison contacts between OpenTofu and Terraform, who would be available to review and address any intellectual property concerns with submitted contributions to OpenTofu or Terraform.”

Laferra concluded, “In the future, if you should have any concerns or questions about how source code in OpenTofu is developed, we would ask that you contact us first. Immediately issuing DMCA takedown notices and igniting salacious negative press articles is not the most helpful path to resolving concerns like this.”

So, what’s next? Having covered more than my fair share of intellectual property legal conflicts, I don’t expect HashiCorp to back down. I fear that this issue will be resolved in the courts, not in Git repositories.

Photo credit: Maarten van den Heuvel on Unsplash

April 11, 2024
Google Adds GenAI Tool to Automate DevOps Workflows

Google this week added a generative artificial intelligence (AI) tool dubbed Gemini Cloud Assist to automate a wider range of tasks across the software development lifecycle, including troubleshooting applications running on the Google Cloud Platform (GCP) to surface recommendations to improve performance and enhance security.

Announced at the Google Cloud Next ’24 conference, Gemini Cloud Assist is integrated with an existing publish and subscribe capability to enable DevOps teams to launch generative AI prompts to automate tasks that previously would have required them to develop a script. Gemini Cloud Assist can also generate architecture configurations based on the code being deployed.

At the same time, Google is making available via a private preview an update to Gemini Code Assist tool to generate code that has been trained on a large language model based on one million tokens.

Brad Calder, vice president and general manager for GCP and technical infrastructure told conference attendees that version 1.5 of Gemini Code Assist will now generate code based on the largest LLM trained using code vetted by Google to generate more reliable outputs.

The challenge going forward will be determining where the line between generative AI tools provided by a cloud service provider such as Google leaves off and where the generative AI tools provided by Google partners such as GitLab begins.

GitLab has been working closely with Google to develop its Duo AI capabilities using core services that Google makes available via its Vertex platform for managing machine learning operations (MLOps).

David DeSanto, chief product officer for GitLab, said as AI continues to be applied to DevSecOps workflows the routing capabilities developed by GitLab will make it simpler to orchestrate prompts that can be applied to multiple LLMs. That approach provides a layer of abstraction from the underlying LLMs that makes it simpler to swap out as new capabilities are added, he noted. Most DevOps teams are not going to need to access an LLM directly because the natural language prompts they create will be executed by the underlying platform, DeSanto added.

It’s not clear to what degree AI is capable of automating DevSecOps workflows, but as the reasoning engines embedded in LLMs become more advanced, the ability of these platforms to automate manual tasks is only going to increase. As those manual tasks are eliminated, developer productivity should substantially increase because much less time will, for example, be needed to spin up a remote development environment.

Rather than tracking outdated metrics such as the amount of code generated, however, IT leaders should be focused on the rate at which test failures are declining as the quality of code being written steadily improves, said DeSanto. Too many developers are spending the bulk of their time trying to get code that runs on their laptop to execute in production environments, he noted.
In addition, it will become a lot easier to onboard new members to a software engineering team as, for example, summarizations of how existing code works become readily available, said DeSanto.

Ultimately, the number of applications any DevOps team can build, deploy and manage is about to substantially increase in a way that doesn’t require IT organizations to add a small army of software engineers to build, deploy, manage and secure.

April 10, 2024
Rocket Software Makes Testing iSeries Apps More Secure

Rocket Software this week extended its DevOps platform for iSeries platforms from IBM to make it simpler to test applications in a way that ensures sensitive data isn’t inadvertently exposed to application developers.

Julianna Cammarano, vice president of product for applications at Rocket Software, said the update makes it possible for DevOps teams to apply policies that prevent developers from being able to view sensitive data, such as credit card or social security numbers that might result in a compliance violation.

The masking capability makes it possible for DevOps teams to continue to provide access to data that is needed to test applications without risking potential fines that might be levied if they fail an audit, she added. In the absence of that capability, organizations that must comply with any number of regulations are not able to give developers access to data sets running in production environments to test their applications, said Cammarano.

As is the case with most legacy IBM platforms, adoption of best DevOps practices is uneven. Many organizations are now using a mix of waterfall and DevOps methodologies to build and deploy applications. In some cases, an application that is rarely updated lends itself more to a waterfall methodology than a DevOps workflow that is designed to enable organizations to frequently update software.

The challenge that organizations with iSeries applications have is attracting developers and software engineers to work on a legacy platform, noted Cammarano. The only way to entice them to work on a legacy platform is to make sure they have access to modern DevOps tools that can be easily accessed via a centralized portal, she added.

It’s not clear how many new applications are being built for the iSeries platform but there are still a substantial number of legacy applications running in production environments that organizations may opt to modernize rather than replace, especially if the cost of replacing those applications is prohibitive, said Cammarano.

IBM, for its part, appears committed to providing support for the iSeries platform till 2032, and beyond, now that IBM is using the same server architecture developed for its P-Series Unix platforms to build next generation iSeries servers. That approach ensures iSeries application performance will continue to improve as IBM makes additional investments in the RISC processors used now in both platforms.

There are, of course, few organizations that are not also building and deploying applications on other platforms. Those that do have iSeries platforms are typically looking to adopt a consistent set of DevOps workflows that can be applied to multiple platforms that continue to run in on-premises IT environments, mainly because migrating iSeries applications to another platform requires a significant amount of time and effort.

Ultimately, each organization needs to determine what level of DevOps adoption best fits their needs, depending on how dependent they might be on a specific platform. The one thing that is certain is many organizations, as more application development and deployment processes become automated, will discover DevOps is a journey that never ends.

April 10, 2024
Securing Open Source Software, the Cyber Resilience Act Way

The Eclipse Foundation and other open source organizations are working towards implementing the European Union’s Cyber Resilience Act’s software development security requirements.

If anyone still doubted that we need to do a better job of securing open source software, the recent XZ backdoor security backdoor incident was a loud alarm. The European Union (EU) figured this out a while back. In its Cyber Resilience Act (CRA), it asked the open source community to establish common specifications for secure software development. The Eclipse Foundation and a host of other leading open source organizations, including the Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation and the Rust Foundation, are up for the challenge.

The Eclipse Foundation is spearheading the effort to create a unified framework for secure software development. The foundations and allies are doing this via a new working group, established under the Eclipse Foundation Specification Process.

The collaboration is spurred by more than regulatory compliance. In an era where open source software is pivotal to modern society, the imperative for safety, reliability and security in software has never been more critical. As Arpit Joshipura, the Linux Foundation‘s senior VP of networking, said at the Open Source Summit Europe in Bilbao, Spain, last year, “We must look at the end goal. The end goal for all of us is the same. We want to secure software, and we want to secure open source software.”

This process won’t be easy. It will be a highly technical standardization journey. The project will start with the current security policies and procedures of the open source foundations involved. The final result will be process specifications, which will be made freely available under a liberal specification copyright license and a royalty-free patent license.

The Eclipse Foundation and friends aren’t the only ones working on such security efforts. For example, the Open Source Security Foundation (OpenSSF) working group and the Open Source Consumption Manifesto (OSCM) are also working on building best security practices into open source software supply chains.

Under the CRA, the legal person—which is not the same as a flesh-and-blood person reading this story—responsible for these new policies and their implementation will be known as the “Open Source Software Steward.” This will be a heck of a job.

Leaving aside the code and technical issues, the open source groups must work with traditional standards organizations. Historically, neither kind of group has worked well with one other. To make matters worse, standard organization governance models don’t even have a way of dealing with open source groups. Indeed, for the fruits of this effort to make it into regulation, it will require going through the formal standardization processes of at least one of the European Standards Organizations.

This is going to be so much fun!

Adding insult to injury, setting technology standards usually takes years, and the CRA requires developers to have something in place by 2027. Good luck with that!

“There is an enormous amount of work that will need to be done over the next three years to implement the CRA,” Eclipse Foundation executive director Mike Milinkovich said. “It’s the first law anywhere regulating the software industry as a whole. The implications of this go far beyond the open source community and will impact startups and small enterprises as well as global industry players.”

Despite the challenges, the initiative represents a crucial step forward. The working group is optimistic about laying the groundwork for cybersecurity standards that can serve both the open source and proprietary software realms.

I wish them luck. They’ll need it.

April 10, 2024
Hashicorp Versus OpenTofu Gets Ugly

When HashiCorp dumped its open-source Mozilla license for the Business Source License (BSL 1.1) for its flagship program, infrastructure as code (IaC) tool Terraform, many Terraform developers and partners were ticked off. As open source developers are wont to do in such situations, they created a Terraform fork, called OpenTofu.

So far, that’s business as usual when a company shifts a project away from open source. Things heated up, though, when the Linux Foundation announced it would support the new fork. Now, the conflict between HashiCorp and OpenTofu is starting to boil, as HashiCorp accused OpenTofu of “not respecting the terms of its BSL license governing its Terraform codebase.”

Them’s fighting words!

OpenTofu replied, “OpenTofu vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code.” The organization added, “HashiCorp may be conflating code that it had previously been open-sourced under the MPL and more recently developed code it published under the BSL.” And, OpenTofu says, it will “issue a written response providing a more detailed explanation of its position.”

So, what is this code in question? Neither Hashicorp nor Terraform is saying, quite yet. However, it appears to be a “removed block” automation process that enables Terraform to manage resource deletion.

Matt Asay, MongoDB‘s VP of Developer Relations, revealed this accusation. He accused OpenTofu of lifting the “removed block” code, which was released under the BSL a few months after the OpenTofu fork was created. “The tell? OpenTofu took this BUSL-licensed HashiCorp code, removed the headers, and tried to instead relicense it under the Mozilla Public License (MPL 2.0),” Asay wrote.

Oh, it’s on now.

Even before news of the legally threatening message emerged, prominent open source leaders attacked Asay’s claim. Bryan Cantrill, the hyper-cloud Oxide Computer co-founder and CTO, claimed, “This is an extraordinarily serious accusation – and the cited files frankly don’t substantiate it.”

Cantrill is far from alone in thinking that there is insufficient evidence to justify the accusation that OpenTofu has stolen any code. Until we have harder evidence, the issue will remain a case of “He said, she said.”

Chris Aniszczyk, the CTO of the Cloud Native Computing Foundation (CNCF), a Linux Foundation-related organization, doesn’t think it’s a good look for HashiCorp. He said it’s “embarrassing to see a company light all of its hard-earned developer reputation on fire, on top of attacking open source.”

Dan Lorenc, CEO and co-founder of Chainguard, a software supply chain security company, warns this could be the start of something big and ugly in software development circles. “I don’t have any philosophical or ethical issues with source-available licenses, but their proponents are going to have to address these cease-and-desist threats,” he wrote. “Developers working in OSS (OSI/FSF approved licenses) are going to be prevented from engaging with or even looking at source-available projects completely to prevent the risk of lawsuits. It’s just too risky to pretend otherwise.”

Lorenc adds, “There’s no gradual transition here, it’s going to be a hard fork in communities if these lawsuit threats keep continuing. And I know which community I’d bet on sticking around.”

I lived through the SCO-Linux copyright wars. I think I know who will win, too.

Photo credit: Quino Al on Unsplash

April 9, 2024