Chris’ talk below at North Bay Python was, as his always are, well-delivered and worth consideration.

The conclusion that he draws towards the end is similar to something I was noodling last year:

At some point somebody, somewhere, is going to have to actually understand how things work.

Chris makes the point, as he typically does, much more thoughtfully and with a stronger philosophical base.

Had some discussions with the delta-kernel-rs developers after they mistakenly added a ton of new files to tests/ blowing up test cycle times. Another community member shared this great overview about not using Cargo integration tests.

Catching up on Daniel’s thoughts on Data Quality and reconsidering the domain. The generation of slop has resulted in renewed discussions of “but how do we ensure correctness?” which is a great question to be trying to answer, but I am still rather disappointed with the state of the art for data quality tooling.

I recommend this blog post which has some good citations for negative AI behaviors affecting free and open source communities.

This is going to be a difficult problem to solve, more difficult than the email spam problem we have been unable to solve after 30 years of working on it.

This is also a very important problem, we are currently in an age where we have access to information that most people couldn’t even dream of 30 years ago. We also have disinformation that combines some of the worst aspects of authoritarian regimes throughout history combined with the worst aspects of cult brainwashing. If we lose access to the information but the disinformation remains (or get worse) then the result will be terrible.

I really enjoy Planet Debian as an aggregator of an international set of voices from the Debian community. I get exposed to so many different view points from around the free software ecosystem, which I really value. This past week I read this blog post by a debian maintainer which I was so flummoxed by I wrote out my thoughts on the topic here

Streaming tar over SSH is one of the more novel Unix tricks I don’t get to use much anymore. Drew Devault shared some helpful tips for using it without needing to use incantations of rsync(1).

I am a big believer in the four opens:

The Four Opens are a set of principles guidelines that were created by the OpenStack community as a way to guarantee that the users get all the benefits associated with open source software, including the ability to engage with the community and influence future evolution of the software.

• Open Source
• Open Design
• Open Development
• Open Community

There is an implied “to the public” in each of the four opens, at least how I have understood it over the past many (many) years. I have repeatedly advocated for open (to the public) discourse and transparency when working with companies like CloudBees and Databricks as they have engaged with open source projects.

The mounting negative pressures and in some cases outright hostility towards free and open source projects has me reconsidering the implied “to the public” and how these communities may need to evolve in the future.

While I have never been a fan of invite-only Discord or Slack servers, both of which are used by the Apache Datafusion project for some odd reason. There are good reasons to put the project’s shared spaces in slightly more private and slightly less AI-accessible systems. A little bit of privacy can lead to more candid conversations and potentially a stronger feeling of community and safety.

My first line of thinking led me to the idea of “vouching” which I recall mitchellh posting about in the fediverse, but I couldn’t find a good linkable reference.

Vouching is what we did as kids when a new friend was suggested to join the mischief, somebody would vouch for the new kid and say “hey, they’re my neighbor, they’re cool” and then we would go start new trouble together. In the context of an open source community vouching can:

• Help build a web of trust without every person necessarily knowing each new person
• But also vouching means there is a higher tendency for a community to be homogeneous, since it will be less welcoming to random new-comers.

I think vouching could also exacerbate the likelihood of a Jia Tan where the web of trust within the community is compromised by a malicious actor. Getting one member to vouch for you may lower the guard of all of the other members of the community making these style of attacks easier to pull off.

Since I started writing this post a whole week has passed by, without any new ideas or patterns popping into mind. I’m curious how others are thinking about it, so please let me know on Mastodon or via email rtyler@~

One of the big arguments against generative AI-based coding tools is that they were trained on billions of lines of copyrighted and licensed works in the open source ecosystem, and they strip those works of all attribution and violate the terms of the licenses.

Yesterday there was some fervor about the Supreme Court allowing a lower court decision to stand in my timeline. I have been following this topic for a few weeks after reading this Congressional Research Service report: Generative Artificial Intelligence and Copyright Law (PDF) and considering how some of the guidance might affect the use of generative AI in open source projects.

kat nailed it with their toot

So uh

does this mean that there is now precedent that at least “agentic” dev systems, potentially any genAI dev system, now leaves companies open to their code no longer being considered copyrightable if they use these systems?

kat is right that this is huge.

In the Delta Lake project we rely on Developer Certificate of Origin (DCO) with guidance from the Linux Foundation. Yes, that Linux Foundation.

From the DCO:

The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

From the Apache License:

“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

[..]

“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

I am no lawyer but I do have at least a 12th grade reading comprehension level.

If AI-generated works are not copyrightable, then it is not possible for somebody to license under any open source license, much less assert via DCO that they are able to do so.

2026-03-04 update: Software Freedom Conservancy has a blog post on the topic which is worth a read. I understand the narrowness of the scope of judgement which is being referred to, but my opinion on the situation is taking into consideration the other guidance from the Congressional Research report and the US Copyright Office oplicies as they stand today.

Again, this is a big deal.

From the Congressional Research report

The AI Guidance states that authors may claim copyright protection only “for their own contributions” to such works, and they must identify and disclaim AI-generated parts of the works when applying to register their copyright.

The only viable solution I can imagine is that all AI-generated code contributions in open source projects is considered public domain and commented appropriately. Otherwise I don’t see a sensible path forward for AI-generated code in open source projects.

A brief aside I find that using LLM-based coding assistants is unethical and morally corrupt. These large language models were trained on open source code en masse, with their different licenses and copyrights. Large-language models are effectively laundering that code and re-selling it to other developers. Cursor can help you write Terraform because its models slurped up code from Anton Babenko (Putin khuylo!) and thousands of others. Copilot is able to help you vibe-code a new Django app because it copied Tim Graham’s and countless other contributors’ code without attribution.

Their outputs are a contemptible parallel construction of intellectual property theft.

All of my code for the Delta Lake project is licensed under the Apache License 2.0. This means if you want to copy this code you are welcome to, but you should include the license text in your project and include attribution.

I have observed some confusion around attribution.

DO:

• Include the copyright line from the license file where you’re copying code from, e.g. Copyright (2020) QP Hou and a number of other contributors. All rights reserved. for delta-rs
• or if you’re lifting a snippet of code rather than whole files/modules, add a comment block around the section of code with the above copyright and mention that it’s under the Apache License
• and include the copyright notice in built binaries from this code. The redistribution clause of the Apache License applies to source and object forms.

Also consider letting the upstream folks know! Most people open source code to contribute to the general commons. Sending an email “hey thanks for X” goes a long way to making friends!

Don’t:

• Just copy and paste the code you want, laundering copyrighted code like an LLM.
• Include nothing more than a comment in the source code with a link to code on GitHub.
• Pilfer code and then come back around and ask for credit for some derived work. I have lost count of the number of times “I made this” has happened.

Since the “Business-Source License” nonsense started happening with Hashicorp, Redis, MongoDB, and other open source presenting companies, I have taken to licensing more and more of my code as AGPL. That does complicate matters a bit more but generally whatever you make with the AGPL code has to also be made freely available.

I write free and open source code because I believe that produces the most positive benefit for our society. I hope you can build something cool with code that I wrote, but please follow the conditions of the license!

Sometimes I wonder if “the only way to win, is not to play.”

Corporate involvement in free and open source projects can and should be mutually beneficial.

My previous employer CloudBees is a good example of the possible symbiotic relationship between corporate actors and a community. Many people might not know what CloudBees originally was: it was EngineYard for Java applications. That is to say, it was a “platform as a service” where you threw your .war and .jar artifacts over the wall, and CloudBees would host and operate them. The reason nobody remembers, is that cloud providers stepped up from the “infrastructure as a service” domain into “platform” and gobbled all the market up from EngineYard, Heroku, CloudBees, and a number of other upstarts. If it weren’t for a savvy business move, recognizing that continuous integration and delivery was a key differentiator, CloudBees would have died long ago.

The company hired Kohsuke and a lot of people straight out of the Jenkins community, myself included. When I was there, we had a constant push and pull between what should be proprietary (CloudBees Jenkins Enterprise, or whatever it was called that quarter) and what should be upstreamed into Jenkins. CloudBees very successfully sold “enterprise-grade” Jenkins addons, support, and management tooling to companies around the world. Meanwhile in the Jenkins project we frequently discussed, and still do, how much control CloudBees could or should wield over the project.

What many users and other developers often overlooked was the literal millions of dollars that CloudBees invested in paid developer time, events, advocacy, documentation, and marketing. Did CloudBees benefit from this arrangement, absolutely. Did Jenkins also benefit from this arrangement, absolutely.

Recently in the Delta project’s Slack somebody came along, concerned with the level of involvement by contributors other than Databricks in the project. It’s not uncommon to see users come into the project and ask why Delta Lake doesn’t support their preferred compute or query engine, sometimes becoming upset that Delta Lake’s primary supported environment is Apache Spark, which also underpins the entire Databricks platform. Delta Lake was created by Databricks, who have invested tremendous resources in its development and stabilization. It should be no surprise that for most of the developers on Delta Lake, Apache Spark is their primary platform of concern, and everything else is in the “nice to have” bucket.

While I would love to see Databricks upstream more of their own in-house performance improvements and tools around Delta Lake, I must also recognize that Databricks is a business and they’re trying to ride that fine line between making money and not.

The Delta project is however licensed under the Apache Software License 2.0, easy to contribute to, and fairly well documented.

Those upset by “missing features” in Delta Lake seem more like somebody upset they cannot get a free lunch.

I think the Red Hat / CentOS relationship is severely underappreciated. The company is pouring millions of dollars worth of investment into hundreds of free and open source projects every year.

Linux admins across the internet got upset late last year with CentOS’ change in approach. I interpreted this “backlash” as admins angry that they were no longer getting Red Hat Enterprise for free.

For somebody who has never paid Red Hat a dime, to shake their fist over how they operate their business, which still funds significant development of free and open source software, is entitled to say the least.

There is this pattern of “my definition of open source” I see across the industry, typically aired on Hacker News, Reddit, Twitter, and anywhere else people shout and complain. The lamentations that Some Company or Some Individual is not adhering to the “spirit” or “ethos” of how the author defines free and open source software. The never-ending desire to have capitalistic corporations pass some purity test for each and every open source community they interact with, is not only unfair but unrealistic too.

Free and open source software has created enormous societal wealth and enabled entirely new industries since its inception in the 1980’s (roughly). I believe that is in no small part because there are very little strings attached. The terms of the licenses set the ground rules, but beyond that individuals and corporate actors can “vote with their feet.” For example, I will be drawn to projects which enrich my life or help me achieve my goals and ambitions. If I tire of a project, or it’s no longer useful, I leave. The same goes for corporate actors, participating or leaving projects as they deem necessary in order to fulfill their own goals and ambitions.

I don’t begrudge any company which lowers investment, shifts focus, or outright leaves an open source community. No more than I would begrudge an individual for doing the same. You don’t need to be here for the same reasons I am here, so long as we’re able to both work together while we are.

So long as developers have bills to pay, there will always be a need for corporate involvement in free and open source software. I believe the path to success for any project is for developers to have curiosity and empathy towards the motivations of prospective contributors, whether they are corporations or individuals. Opportunities to align businesses and individuals can provide an incredible boost, moving everything forward in the project by leaps and bounds.

Companies are not automatically “the enemy” of free and open source software, with effort they can be engaged in ways that are beneficial to the lives of developers, users, and maintainers. In my experience, it’s usually worth the effort.

In order to participate in my open source project, you must have at minimum:

• GitHub account
• Google account
• Slack account
• signed CLA faxed to legal

The results were overwhelmingly in favor of requiring, at minimum, a GitHub account. This was the result I expected and certainly matches the anecdotal experiences I have had in recent years.

Unfortunately Twitter polls doesn’t allow multiple selections, as the reality for most people is that they need all of those, as Felix Frank alluded to in his response. When I think of the Jenkins project in particular, the “registration” process for new contributors might typically include:

• A GitHub account.
• An LDAP account to access Jira, Confluence, and Jenkins-on-Jenkins.
• Connecting to IRC over Freenode, or a Gitter channel, depending on their focus area.
• Subscription to a mailing list operated by Google Groups.
• A Google account, if they want to participate in Hangouts or comment on Google Docs for various design documents.

As we have discussed newer services to incorporate into the community, I have grown weary over the number of logins we would expect each contributor to maintain.

I do not find myself reminiscing about the “good old days” of open source software, when things were more oriented around Bugzilla, CVS/Subversion, mailing lists, and IRC. There too we had account sprawl, it was perhaps a bit more non-obvious.

For the Jenkins project, the ideal world would mean that everything linked to our project’s LDAP infrastructure. With services like GitHub, That is obviously not possible, so the next best thing would be to use GitHub as the source of identity for all our other development services. Yes this couples us more closely with GitHub, but at least then we would stop pretending we’re not already intricately bound with GitHub as a service.

As many projects approach the summer, and Google Summer of Code kicks off, I encourage you to consider the number of accounts, repositories, groups, and other information a student or new-contributor must have in order to start adding to the community.

Our goal as stewards of such projects, should be to push that number towards zero.

Perhaps the most oft cited reason for this rule is that it creates what I would characterize as “people problems.” Concerns about reducing incentives for volunteer contributors, creating conflicts of interest, and a number of the other predictable but avoidable problems between people when money becomes involved. Another very understandable issue is one of budget, people-time is very expensive and foundations are not typically flush with cash. While I understand the concerns around directly funding development, I cannot shake the feeling that this attitude is simply wrong.

Leaving the coding to be done by volunteers doesn’t democratize anything in my opinion. Instead, I believe it ensures that external corporate actors in the ecosystem, which pay for development time, will have an outsized impact on the roadmap and progress of any project in a given foundation. If we can assume for the moment that the technical oversight committee, or governing board has the growth and success of the project in mind, wouldn’t they be much better suited to fund development in key areas of the project?

Looking at the Jenkins security team as an example, I am extremely grateful that CloudBees has been such a prominent supporter and investor in the development of new security fixes and research. Without CloudBees funding that development, Jenkins be severely behind in triaging and fixing outstanding security issues affecting the 200,000+ Jenkins installations in the world. But is that fair, is that appropriate? I don’t believe so. What would be much more reasonable to me, would be for the pooled resources of the many organizations who believe in Continuous Delivery and rely on Jenkins as a part of that story, to improve a crucial area of shared interest like Jenkins security.

Overly relying on volunteer efforts for code contributions also negatively affects the diversity of open source projects. Setting corporate-funded development aside, limiting the contributor base to only those who have significant amount of passion and a significant amount of surplus labor to donate, ensures that the project will only be made up of a certain subsection of the code-capable population. This is in part why I’m a strong believer in stipends and funding programs like Google Summer of Code and Outreachy, both of which I have supported as best I could within the Jenkins project.

As my opinions on the subject have evolved, were it strictly my call on how Jenkins’ annual budget should be spent, I would ensure we were paying for code. Once the infrastructure, key events, and advocacy materials had been covered, whatever was left over would be directed into funding development in Jenkins.

There is no purity of ideal that comes with free code.

aci-tunnel relies on the Azure CLI and will provision an ephemeral Azure Container Instance, to which an SSH reverse port forwarding tunnel is opened. The screencast below shows an example of using aci-tunnel to expose a locally running Jenkins environment:

The Details

There are two components to aci-tunnel, the first is the custom container which is deployed into Azure. The container is a fairly simple derivative of Alpine Linux with the openssh-server package installed. The daemon is also configured with GatewayPorts yes to enable binding a reverse port forward onto 0.0.0.0 in the container. For added security whenever aci-tunnel launches, it passes along the user’s ~/.ssh/id_rsa.pub along to the instance which is dropped into the container as an authorized_keys file. This ensures that only the user that launches aci-tunnel can access the container.

The container is launched with the ports 22, and whatever the user specifies, open to the public into Azure Container Instances.

On the local side, the aci-tunnel script creates the SSH tunnel with the right arguments to construct the reverse port forwarding enabled.

Once the highly sophisticated tunnel keep-alive command has been interrupted, terminating the SSH tunnel, aci-tunnel then destroys the container in Azure.

Wholly controlling my own tunnel infrastructure works quite well. In my early experimentation I was able to share a local service while sitting on public transit wifi, which was a bit slow but still allowed the HTTP and other TCP requests to transit the link properly.

When I first wrote about CDF in January, I highlighted some of the reasons that I am excited for the organization. The list has since gotten even longer! The Jenkins project’s meager budget is currently spent on our infrastructure, travel grants, and initiatives like Outreachy. Under the CDF, I am excited to scale up our investments in the Jenkins and broader continuous delivery community. Imagining the world in which we could fund not just one Outreachy intern, but two! Or funding more travel grants to ensure that members from our global community can join in events like FOSDEM, or DevOps World Jenkins World. I can hardly wait!

The excitement of a predictable budget is only half of the story however. As we have worked towards the CDF with our peers at Google, Netflix, and a number of other companies, we have already found really interesting points to further collaborate within the CD ecosystem. One really interesting idea that has come up has been the possibility of a shared model for a “cd pipeline.” A model which can be used between Jenkins, Jenkins X, Spinnaker, Tekton, and other tools involved in the process.

Over the past 10+ years in the Jenkins community, I have always been passionate about the project’s community, governance, and planning for the future. With Jenkins and the CDF, I’m looking forward to us building for the next 10+ years of Jenkins!

Today I stumbled into a ticket, wherein a user exclaimed, paraphrasing:

I love open source and I really like this tool, but the fact that this ticket is still open and not addressed makes it very hard for businesses to take open source software seriously.

This ticket isn’t asking for anything crazy, a number of proprietary tools already support this kind of functionality.

I must commend my colleague who handled this ticket very well and avoided what was my first gut reaction of “go fuck yourself.” The tone of the comment is one I frequently see from people who believe that they are entitled to something from the free and open source community. What makes this one particularly obnoxious to me is the passive aggressive tone, combined with the expectation that others should do some work for free.

For me, much of my free and open source work falls into one of two buckets:

1. Passion-driven, I’m doing this for me. It’s not that I don’t care about people who might use it, but I don’t care that much about what those people might want.
2. Work-driven, I’m contributing to this project because it directly relates to my professional work. This is usually the case when I’m making one-off pull requests to some upstream project.

At no point will I ever do what some random person on the internet asks me to, unless it fits into one of those two buckets. More generally speaking, if you want something done in a free and open source project you should either do it yourself, or pay somebody to implement what you want. Trying to shame others into doing your bidding is never appropriate.

We all have bills to pay,