Jujutsu: a new, Git-compatible version control system [LWN.net]

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 22:26 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: Jujutsu: a new, Git-compatible version control system by amacater
Parent article: Jujutsu: a new, Git-compatible version control system

I work at Google, but not on FOSS stuff, so I'm pretty ignorant of how the legal situation actually shakes out in practice.

Can somebody please explain the difference between Google's CLA, and a DCO? From other comments in this thread, it sounds like Google's CLA does *not* require you to transfer copyright to them (unlike some other CLAs), so I'm a bit confused about what exactly it does do, and how it differs from a DCO.

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 10:00 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

The DCO requires you to assert that you created this thing, and it's OK for you to share under the terms you're offering it under. The Google CLA requires you to grant Google "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works."

The distinction is that under the DCO system, if Linus decides to change the kernel licensing terms, he needs permission from all DCO contributors (some of whom may have already granted it, but still). Under the Google CLA, if Google decides that it wants to use my contribution in a fully proprietary system, it can, and it can even charge me for the privilege of licensing the latest version with my contribution included.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 11:30 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

> Under the Google CLA, if Google decides that it wants to use my contribution in a fully proprietary system, it can, and it can even charge me for the privilege of licensing the latest version with my contribution included.

Google doesn't need CLA for that, Apache License permits them to do that without any copyright assignment.

> The distinction is that under the DCO system, if Linus decides to change the kernel licensing terms, he needs permission from all DCO contributors (some of whom may have already granted it, but still).

That's precisely the only difference and it's more of theoretical one than practical one. If there would be some loophole in Apache License or law would be changed enough to warrant difference in license then Google wants to be able to change the terms.

All other practical and theoretical needs are handled by Apache License itself, not CLA.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 11:52 UTC (Wed) by adobriyan (subscriber, #30858) [Link] (1 responses)

> Google doesn't need CLA for that, Apache License permits them to do that without any copyright assignment.

Why are they asking for CLA then?

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 12:34 UTC (Wed) by khim (subscriber, #9252) [Link]

To shift the liability.

The important part that CLA includes (and which Apache License doesn't include) is your signature and assertion that you have the right to pass that code to Google.

If you also have agreement with your employer that prevents that then you couldn't just turn around and say that what you did was a mistake: you employer would have to sue you then get court decision and only then said license may be annulled.

You may say that it's unfair that trillion-dollar corporation shifts the responsibility on poor small guy, but Google may also say that your two-line contribution is not worth taking that responsibility either.

If your contribution is large and valuable, on the other hand, then you may always fork the project and then CLA, of course, doesn't apply.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 11:22 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Note that many of the people who apply "signed-off-by" lines to commits have little to 0 knowledge of this being related to some "DCO" text that lives somewhere on the Internet. All they know is "Everyone else sticks those lines of text in their commits, so I guess I need to too", or "I didn't put that line of text there and the maintainer shouted at me to, so I'd better from now on".

In most (all?) projects that use "signed-off-by" there no process to explicitely document that new developers certainly are aware that this tag indicates assents to the DCO; and the day-to-day interactions between patch submitters and integrators/maintainers often re-inforce cargo-culting.

Note: If you had that process to establish knowledge of and agreement with some DCO text, the per-commit tag becomes.... redundant!

I'd love to see a court case where a project with the (typical) cargo-culting SOB practices had to argue it showed agreement with DCO.

Remember: DCO and SOB came into life cause Linus just wanted to head off all kinds of calls for much worse bureaucracy in the wake of SCO. He invented this as a sop. IMO (given his previous opinions in those debates) a deliberate "we did something" to shutdown the "we must do something" types. It was designed to be the least intrusive thing that would shut those people up - being meaningful didn't matter (given the context of Linus' prior views).

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 11:50 UTC (Tue) by farnz (subscriber, #17727) [Link]

In that context, it's also worth noting that none of the bureaucracy being proposed would have helped with the SCO case; in the SCO case, the submitter of the code thought that they had the right to do so, and could have passed any bureaucratic hurdle, because the core of the SCO case was that SCO thought that IBM did not have rights that IBM thought it had.

But, because something bad had happened (the SCO case), people wanted to do something to stop it happening again. And Linus was fending off the "this is something, ergo we must do it, because we must do something to stop a repeat".

However, note that the Google CLA could, instead of giving Google an unrestricted patent and copyright licence, merely require you to assert that you have permission to grant those licences, and require that you license the code to Google under the same terms that the Google-owned project already uses; that it's one-way (and - for example - permits Google to sue you for infringing its patents, while allowing Google to lean on the CLA for permission to use yours) is something that often means that lawyers have to get involved if people outside Google are going to contribute (I'd have to get a lawyer involved with every contribution, for example, so that they're happy that Google can't argue that my contribution gives Google a licence to hardware patents not relevant to my contribution, which would be unnecessary if the grant was scoped down to the licence of the project I contributed to).