Well, it looks like they did it. Perforce has all but closed the Puppet source. To be fair, they didn’t actually change the license itself, but they’ve gone as far as they could and still remain compliant. They’re forking projects internally where all their development will happen and pinkie-swear promise that ….. eventually ….. that work will make it to the public repositories.

But we’ve seen how they keep promises. Heck, they never did get around to paying out the survey compensation that y’all donated to Vox Pupuli a few years ago.

And as far as not changing the license goes, I have a little backstory to share there too. See, when Perforce leadership first started flirting with the idea of changing the license, I talked them out of it by explaining how the Contributor License Agreement had been managed.

First, let’s explain what a CLA is, if you haven’t run into one before. We’ll start with just a commit. When you contribute to an OSS project with a given license, your contribution is implicitly and hand-wavily licensed similarly. But here’s the sticky point–you still own the code you contributed. So that 2 lines of code that I contributed to the Linux kernel a thousand years ago is still mine and if they ever decide to do something wonky like ahem, close the source, they would need to get my permission or reimplement the patch.

The CLA is designed to get around that. They’re all a little different and generally they don’t take your ownership away, but they do grant perpetual license to use and to re-license any code you contribute. If you’ve contributed to Puppet and you had to go sign the thing to make the CLA Bot quit yelling at you, that’s what you signed away.

But here’s the problem. It was inconsistently maintained over the history of the project. It didn’t even exist for the first years of Puppet and then later on it would regularly crash or corrupt itself and months would go by without CLA enforcement. If Perforce actually tried to change the license, it would require a long and costly audit and then months or years of tracking down long-gone contributors and somehow convincing them to agree to the license change.

I honestly think that’s the real reason they didn’t change the license. Apache 2 allows them to close the source away and only requires that they tell you what they changed. A changelog might be enough to stay technically compliant. This lets them pretend to be open source without actually participating.

But we know what this sequestered source will mean. In short, from whenever they implement this on, you’ll never again have assurance that the source code you’re looking at in the repo is the same as what’s running on your servers. You won’t know if they’re running intrusive trackers or exfiltrating private information about your infrastructure. And you certainly won’t get access to any new features. The Debian packages that anarcat builds and the FreeBSD packages that smortex maintains will never again be anything remotely resembling current.

Which I imagine is how they want it.

But that honestly only touches the surface of what’s wrong with this approach. What happens when community tooling, like Vox’s test pipelines for example, break unexpectedly because they don’t know about internal EULA-only changes that haven’t made it public yet? You might think that’s hyperbole, but it’s something that regularly happened even with the source being open! Many of you remember the debacle of Puppet 6 demoting core resource types to installable modules. With sequestered source, this is only going to get more common and worse. Even paying customers are going to feel the pain. The community is really good at catching all the small things before they snowball into big problems and before they ship to customers. With this OSP-as-an-afterthought approach, that last bit of QA is going to land firmly in paying customers’ laps.

In any case, last week I told y’all that I was fiddling with a build pipeline to get packages built from the repositories I’d mirrored. Several people reached out to help and it looks like we can have the build pipeline cranking and geographically distributed hosting for community-built packages next week.

I’ve still got a lot of things to work out, but if you’re interested in helping just give me a shout and let’s get the ball rolling. And you’re always welcome to show up to the Vox Pupuli sync call next Tuesday at an ungodly time of the morning for me using the current Zoom URL. We have a lot of details to work out; whether we simply build packages or deviate from the published source and become a community uptream fork; how we intend to stay ahead of CVEs and get timely security patches out; what sort of community governance structure we’d like; and so on. But these are the early days. We’ve got some time to work out the kinks.

Cheers and stay well. This week has been a rollercoaster for a lot of us.