Repercussions on Django Open Source after the death of Corporate Open Source?

I was reading Jeff Geerling’s Blog on “Corporate Open Source is Dead” yesterday on the situation after “HashiCorp rugpulled their entire development community” and IBM buying HashiCorp.

And I believe to know that the situation with Django is different. No company in the background focused on quarterly revenue reports and mainly pulling the strings.

But if you want to contribute to Django, you have to sign a CLA. Again I believe to know that there are good reasons for an Open Source project like Django to require that.

Maybe this could be a problem for Django to attract new contributors in the future? Because from now on a CLA could be considered a red flag for people that are not too familiar with who is or is not (commercially) involved in the Django project. And I’m not sure if doing video presentations with JetBrains could be supporting that uncertainty?

Or as Jeff writes more generally in his blog: “[…] don’t be a victim of the next rugpull. The warning signs are clear: Don’t sign a CLA. Stay away from projects that require them.”

Maybe in this situation Django could briefly explain again, why Django’s need for a CLA is different than other company backed Open Source projects? So without the need to read the entire CLA?

I’ve long queried the role of/need for the CLA.

We don’t really require it, but folks can sign it, and corporates can do so for all employees (if I recall correctly).

Last time I recall discussing this (in like 2018 or so) the consensus was roughly, “It doesn’t hurt, let’s keep it”.

On the basis of the older discussions we took various steps to deemphasis the CLA, like moving to the bottom of the list of jobs for new contributors, and adjusting the wording, so that it didn’t sound like a barrier to entry. Whether that’s enough is an open question.

If – beyond just a post – there’s reason to think the CLA is harmful, then yeah, we could review it again.

I’d need to ping someone like @jacobian to ask for the sufficiently long view here?

Django’s CLA FAQ explains that it mostly exists to protect the DSF from contributors (or, more likely, their employers) trying to claim code back as original IP. If we want to add any extra explanation that our CLA is different from a “Corporate CLA”, the kind that Jeff Geerling is warning about, I think that’s the page to do it. But IMO there’s enough text already, and anyone that could be dissuaded by a CLA is likely to care about the details and read that page.

1 Like

Short answer: when we were setting up the DSF and transfering copyright from the Journal-World, several open source lawyers who I respect told us we needed CLAs to protect us from potential copyright suits, and we took that advice. DCOs barely existed, I don’t think we knew of them as an option. I don’t agree that CLAs are “harmful” in the context of a NPO like the DSF, but also DCOs would be fine too. I don’t really think it’s totally worth the energy to switch, but neither would I block it.

Longer answer and with more feelings:

@adamchainz is right that the reasoning is about protecting the DSF from contributors later claiming that they own some piece of code. The nightmare scenario is: someone contributes some complex patch – like, let’s say a deep refactoring of some part of the ORM that touches a dozen places – and then years later their employer shows up and says “no they were on work time this code belongs to us”. We’d potentially have to face a copyright suit, paying license fees, or trying to somehow rip and and cleanroom reengineer that code.

The secondary benefit is that CLAs give the DSF the right to relicense Django at any point. That’s I think the crux of what Jeff (and others, Drew DeVault comes to mind) are criticizing about CLAs. That power is what Hashicorp wielded when relicensing Terraform, Redis Labs / Redis, etc. Without CLAs an organization would have to get individual permission from each individual contributor before making that kind of change.

So we used CLAs because (a) at the time there wasn’t another option and (b) that power to relicense seemed valuable. But it wasn’t like we made a choice not to use DCOs – they barely existed when the DSF was getting off the ground, I don’t think anyone was aware of them at the time (I certainly wasn’t). (They also are weirdly tied to Git itself, which we weren’t using, though that’s not a blocker more just a weirdness.)

I have complicated feelings here, I think it’s a lot more complex than “CLAs are harmful”, especially when you take into account the very different situations between a corporate owner like Hashicorp and a NPO like the DSF. (I also have much more complicated feelings about “source available” licenses but that’s a side-point). I don’t think it’s “bad” or “harmful” for the DSF to be using CLAs.

However, I think we’ve been a bit indifferent about collecting CLAs, I can’t say we track this as closely as a lawyer would want us to. Like, my read is that we’re doing a good enough job to make sure we’d probably prevail in a suit, eventually, but probably not so great that we’d be able to get a suit tossed quickly and easily.

And, are we ever really going to use this power to relicense? I mean, if it were 100% up to me I’d be seriously tempted by PolyForm Small Business but there’s not a universe in which any relicensing is actually happening. Sure, in theory all it would take would be a majority board vote, but in practice if we did that without overwhelming consensus from the community it would cause a fork. I can’t see even the DSF board ever reaching that kind of consensus on relicensing, let alone the global Django community. CLAs give us the power legally, but there’s no practical way we’d ever want or be able to use that power.

So bottom line, I think DCOs are probably a better fit for where we are now, but also I don’t see that CLAs are really that problematic, so I can’t muster much enthusiasm to switch. I certainly wouldn’t block it but it just seems like a lot of work with limited value.


Thanks to all of you for taking the time to explain the current situation with CLAs and Django in the light of the current events. And now there is an excellent thread about it here, that anybody can refer to should a question about Django and its CLA come up! :+1: