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

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 22:05 UTC (Fri) by josh (subscriber, #17465)
Parent article: Jujutsu: a new, Git-compatible version control system

jujutsu looks really impressive. The concept of:

> In Jujutsu, the working tree is represented directly by a real commit.

makes a lot of sense, and I like the idea that everything is "just" a commit. In particular, while it's a mental shift, the idea of "you're always working on a commit, and at some point you declare that commit finished and create a new one on top" is a really good one.

There are a couple of things that make me not consider it, one likely fixable and one that makes it dead in the water.

First, it seems like they dismiss some workflows as unimportant. For instance, in their table of equivalents, https://martinvonz.github.io/jj/v0.13.0/git-comparison/#c... , "git stash" is shown as "not needed". It very much *is* needed if you need to temporarily work on the last checked-in version. I'm *guessing* there's an equivalent by checking out the parent commit (the commit above the working-tree commit), but the fact that it's just dismissed as "not needed" does not give me hope that they empathize with people who *actually do use it* and want to know how to do the equivalent.

Second, I thought about contributing a fix to that table, and then I saw the contributing requirements:

> Contributor License Agreement

Nope, not happening. Nobody should adopt this until it's been freed from that requirement, either by getting the project to remove it or by establishing a version of the project that takes contributions without that requirement.

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 22:41 UTC (Fri) by madscientist (subscriber, #16861) [Link] (32 responses)

I know a lot of people consider the index useless, but I use git commit --interactive to stage "parts" of my changes as commits multiple times every single day. I don't actually run that command myself, of course: I use it through Emacs Magit, but I couldn't work without it (or some form of it). I haven't investigated how other, index-less tools propose to handle this workflow so maybe they have a different way to do it which is just as usable. In particular saying that every time I save a file it goes into the "latest" commit is not good for me at all, unless there are straightforward ways to chop up these single commits into multiple parts again.

I make edits all over the code and it's not until later after doing much more work that I understand the changes I am making sufficiently to decide how to construct a correct stepwise set of commits from them.

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 23:00 UTC (Fri) by arxanas (guest, #169225) [Link] (28 responses)

jj actually has many more ways of slicing and dicing commits than Git does. You can use jj commit -i to most straightforwardly replicate the common "interactive staging" workflow. There are also a lot of other variations on splitting commits in jj:

jj split -i: Split any commit into multiple commits interactively. (jj commit -i is more or less an alias for splitting the working-copy commit; I believe the difference is something about the default commit message population.)
jj move -i: Move changes from any one commit into any another commit (without creating any new commits).
jj amend -i: Move changes from the target commit (defaulting to the working-copy commit) into its immediate parent. (If I recall correctly, this is very similar to jj move -i with some arguments filled in, but there might be a difference I'm forgetting about.)
jj diffedit: Modify the diff for a given commit interactively. Changes can be selectively updated or discarded in this way.

I implemented the now-default TUI for jj's commit editing, but you can use any difftool. It has a similar interface to `hg commit -i`. The previous default was meld.

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 23:58 UTC (Fri) by roc (subscriber, #30627) [Link] (26 responses)

These sound really good.

In git, the staging area is OK for the simple case where the changes you want to split up across commits are the last thing you did. But when you have already-committed changes that you decide to split up further, git is not helpful... temporary branches, reset, etc.

And of course once you have nice tools for splitting and otherwise mutating commits, the staging area *is* worthless unnecessary complexity.

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 22:12 UTC (Sat) by madscientist (subscriber, #16861) [Link] (24 responses)

> But when you have already-committed changes that you decide to split up further, git is not helpful... temporary branches, reset, etc.

?? ITYM interactive rebase. Git definitely has help for this; I never use temporary branches or reset to chop commits.

But as I mentioned before I use Magit. Much of the workflow that is clunky through the Git CLI, including interactive rebase, is breezy using Magit.

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 22:21 UTC (Sat) by apoelstra (subscriber, #75205) [Link] (23 responses)

If I want to split a commit, I need to (a) interactive rebase to the commit in question, (b) `git reset HEAD^` to remove the existing commit, (c) `git add -p` (or whatever) to construct the new commits.

In complicated cases I can imagine using temporary branches in step (c) or before step (a) to avoid losing work.

Is there a way to do this without the reset step?

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 22:38 UTC (Sat) by madscientist (subscriber, #16861) [Link] (20 responses)

Well, I guess the complexity is hidden from me by Magit. In Magit's interactive rebase mode I say I want to edit a given commit and when I get there I can just tell it to convert all the changes in that commit to be unstaged. Then I can stage them in hunks and make as many new commits out of them as I want. I can also retrieve the original commit message when I commit them so I can re-use it with edits as needed.

I suppose under the covers Magit does need to use a reset operation (your step (b)) as part of "unstaging" all the changes in the commit-to-be-edited.

If I have a "complicated case", I usually just make more smaller commits in this interactive rebase, then after this interactive rebase is finished I start another one and move the smaller commits to where I want them and squash them. Magit makes interactive rebase so simple that it's easier to just run it multiple times than to get complicated and try to do it all in one go. I can't think of a situation where I'd need a temporary branch.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 5:01 UTC (Sun) by intelfx (subscriber, #130118) [Link]

> I can just tell it to convert all the changes in that commit to be unstaged

That's exactly the semantics of a git (mixed) reset.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 5:49 UTC (Sun) by roc (subscriber, #30627) [Link] (18 responses)

That still requires you to mentally juggle three different kinds of trees: a) some set of commits b) what's in the staging area and c) what's "unstaged", i.e. the working tree. You're used to it so it comes naturally, but it's still unnecessary complexity.

You don't need the staging area if you just move changes directly from the working tree to commits. Hg has that, and even git can do that with "git commit -p".

Jujutsu (which I haven't used, but sounds excellent) takes the next step and gets rid of the working tree as well as a distinct concept. It's just the "working commit", so you can use the same commands to move changes from that commit to other commits that you would use to move changes between any pair of commits. Great!

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 2:50 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> That still requires you to mentally juggle three different kinds of trees: a) some set of commits b) what's in the staging area and c) what's "unstaged", i.e. the working tree. You're used to it so it comes naturally, but it's still unnecessary complexity.

With all due respect, you sound like you're not a magit user :-)

Magit presents everything as diff hunks, so I don't really think in terms of "trees" when using it (every day). I just move hunks around freely. I totally understand how the staging area can confuse a lot of people; I frequently use the command line too. But Magit makes it incredibly natural to use. Ask a friend for a demo?

Jujutsu: a new, Git-compatible version control system

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

Having used Magit, a good description of the way it handles things is: "the presence of three types of tree - working copy, index, and commits - is confusing to users. Unify all three into one type of tree, and hide the difference so that as far as a Magit user is concerned, it's all just commits". They do this because commits are the fully featured type of tree, and it's trivial to convert any operation on any type of tree into "turn the tree into a commit, operate on the commit, turn the new commit back into a working copy or an index".

Jujutsu makes Magit's implementation a lot simpler, because instead of Magit having to balance all three types of tree internally, and work out the "correct" way to implement any operation for you, it can instead only implement operations on commits, and get the same advantage. It also doesn't cost any Magit features, since Magit already works this way from a user perspective.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 14:53 UTC (Mon) by madscientist (subscriber, #16861) [Link] (14 responses)

> That still requires you to mentally juggle three different kinds of trees: a) some set of commits b) what's in the staging area and c) what's "unstaged", i.e. the working tree.

It might just be a matter of how you look at things. I treat the index as a way to construct a commit. I expect this is how it was designed to work. So in my mind I have (a) work I'm doing that is not committed, (b) a staging area (usually empty) that I use to construct a new commit from either all or, very often, just selected parts of the work I'm doing, and (c) already committed code.

So yes it is three things but they are all on a continuum of work and it's pretty simple to understand. IMO of course.

I know that as CS folks we like to use a single model for everything, but the reality is that sometimes it's easier to understand things if they have distinct models. I haven't used Jujutsu so I can't say whether it really is simpler to treat everything as the same thing, or not.

I can say that based on the replies here showing command line operations, while Jujutsu may be simpler to use than the Git CLI (I mean... yeah) it seems to me that Magit is simpler than both of them :)

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 15:08 UTC (Mon) by farnz (subscriber, #17727) [Link] (8 responses)

Note, though, that Magit makes things work by saying that you're always dealing with hunks in a commit - it hides the differences between the working copy, the index, and your forest of commits from you. If Magit makes things simpler, then it does so by reducing the number of things you need to juggle in your head by two - get rid of "working copy" and "index" as separate entities.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 19:25 UTC (Mon) by madscientist (subscriber, #16861) [Link] (7 responses)

> it hides the differences between the working copy, the index, and your forest of commits from you

I don't agree with this.

Staging is visible and important in Magit. It's up-front and clearly distinct. The Magit status buffer shows different sections for the unstaged files, the content of the staging area, and a list of recent commits. And staging files vs. hunks is just a difference in granularity; it doesn't use a separate workflow.

Maybe you mean, it hides the differences in the way you work with the different parts? That might be true to some extent. But it definitely doesn't try to pretend that they are all the same thing; it's more you don't have to remember the various commands and options. For example, it's clear in Magit that neither unstaged or staged hunks are "the same as" a commit.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 21:45 UTC (Mon) by farnz (subscriber, #17727) [Link] (6 responses)

Behaviourally, having used Magit, the staging area behaves exactly the same way as a commit does - it's something you can stage hunks to, and aside from naming it differently, it's possible to make Magit treat the staging area exactly the same as a commit.

Aside from it being given a funny name, it's functionally a commit - you don't get different commands for it, or different options, or different behaviours, or indeed anything to justify treating it specially.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 22:07 UTC (Mon) by madscientist (subscriber, #16861) [Link] (5 responses)

That's not the case. There are many things you can do with staging that can't be done directly with commits (the way things work today).

In addition to staging hunks into the staging area, which could be considered equivalent to amending a commit, you can unstage them again, delete them completely, etc. That is not possible with commits: the only way to modify a commit in that way is to go through a rebase operation.

It's actually more accurate to say that the staging area behaves exactly the same way that the unstaged changes area, except that you can create a commit from the staging area and you can't create a commit directly from the unstaged changes. Other than that staged and unstaged work pretty much identically in Magit, and are treated very differently than commits.

I understand that there could be a different implementation that uses a real commit instead of staging and hides all the work to "unstage" hunks behind the scenes, but that's not how it works and it's not how the mental model is presented.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 10:14 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

Hmm. The version of Magit I've experimented with allowed me to unstage hunks and delete them from commits, and allows me to create a commit directly from the unstaged changes. Under the hood, it did a rebase operation in the process, but from my perspective it was completely transparent; Magit hid this from me.

From my perspective, Magit is completely hiding the staging area from existence - there's something that behaves just like any other commit, and is called the "staging area", and there's unstaged changes which also behave just like any other commit, but are also present in the working copy on disk, but otherwise Magit makes the differences go away, and just works in terms of moving hunks between the various places in the forest of VCS commits I could see. Perhaps you've configured Magit to be more explicit about the staging area? My configuration for Magit is quite large, and has built up over the last decade.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 15:48 UTC (Tue) by madscientist (subscriber, #16861) [Link] (3 responses)

I'm using the latest version (or at least within the last week or two: I haven't restarted my Emacs session in a while :))

It's true that you can ask to "unstage" a hunk in a commit, but what happens is that Magit will add a staged change that reverts that hunk, then an unstaged change that adds it back again. You can choose which one you want and if you want to keep the revert you can apply that change either by adding a new revert commit or by using Magit's fixup facility (which makes a commit then uses rebase to squash it into the original commit, but done for you).

It is pretty different from a UI perspective to unstaging a hunk from the staging area, which simply moves it back to unstaged as if you'd never staged it at all.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 15:51 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I've never seen that UI behaviour from Magit; you have it set up differently to me (I copied someone else's config ~10 years ago to get started, and stuck with that). I don't ask it to unstage a hunk; I ask it to move hunks between locations, and the staging area is just one of those locations. I can literally ask Magit to move a hunk straight from the commit to the unstaged work, or to the staging area, or to another commit, and it works out what sequence of operations makes that happen for me.

In this setup, there's no need for the staging area - it's just a commit with a funny name - as all the "move hunk" operations work just as well between two commits as they do between a commit and the staging area.

Jujutsu: a new, Git-compatible version control system

Posted Jan 26, 2024 16:44 UTC (Fri) by madscientist (subscriber, #16861) [Link] (1 responses)

This is probably too off-topic to continue much further.

I don't know what keys/commands you are using to get the behavior you see, but I'm using bog-standard Magit with all the basic settings and very little customization. The key I use to unstage a hunk is "u". If the cursor is on a hunk that's been staged, then the hunk is moved back to "unstaged changes" by pressing that key. If the cursor is on a hunk in a commit (I view the hunks in the commits by selecting a commit in my "Recent Commits" list then pressing ENTER to see its changes) then I get the behavior I described previously.

Perhaps you are entering some other "commit editing mode" in Magit, that I'm not using. It sounds cool! But in any case there is a clear difference in the UI behavior between staged hunks and hunks in commits.

Jujutsu: a new, Git-compatible version control system

Posted Jan 30, 2024 12:32 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I think it's that Magit can display them differently, but under the hood Magit tries to paper over the difference (internally) by making actual commits for the stage behind the scenes.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 16:49 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

> So yes it is three things but they are all on a continuum of work and it's pretty simple to understand. IMO of course.

Problem is, it's your *opinion*. Which you're welcome to.

But as someone who doesn't use git much, the index/staging to me is extremely confusing. And while I'm slowly trying to get into it, despite working with computers pretty much my entire career I've always avoided "software house" environments; with one exception spending it in "end user computer departments" or, as now, being the programming/computer guru in an end-user department.

I view things through end-user eyes. And as you'll know from my database rants, I simply cannot understand why main-stream computing is just so damn complicated! I quite get you don't see it that way, but probably that's all you've ever known. Just like end-user is pretty much all I've ever known...

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 18:14 UTC (Mon) by madscientist (subscriber, #16861) [Link] (3 responses)

This entire sub-thread is all opinion-based, so my opinion about Magit being simple to understand is no more or less valid than someone else's opinion that Jujutsu's model is simpler. If we hear from someone who BOTH (a) is an experienced user of Magit AND (b) is an experienced user of Jujutsu, and they say that one is simpler to understand, that would carry more weight. But even then, this is fairly subjective.

Also I'm not talking about Git. I'm talking about Magit. Whether you find the staging capability of Git confusing or not is irrelevant to my point, which is that Magit makes it clear why staging exists and what it's good for and how to use it, and makes it easy to use. And, Magit doesn't hide staging or pretend it's just a different way to talk about commits: it's a separate thing, which is integral to the workflow.

I don't really know what you mean by "software house environments"; Emacs is not exactly specialized or with limited availability.

Just to remind there's no such thing as a "programming/computer guru" who is not also an end-user. We are all end-users.

As for why it's complicated, well, some things are just complicated and the only way to simplify them is to remove functionality. Obviously it would be great to have a simple interface to support simple uses and save the complexity for more advanced users, and it would be great if the complex uses could also be made simpler, but to paraphrase Pascal "I am sorry for the complexity of the interface, I have not the time to make it simpler".

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 22:00 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> I don't really know what you mean by "software house environments"; Emacs is not exactly specialized or with limited availability.

"Limited availabity" does not mean "in widespread use". I don't think I've ever known a regular user of Emacs apart from my brother.

> Just to remind there's no such thing as a "programming/computer guru" who is not also an end-user. We are all end-users.

You miss my point. All programming/computing gurus are end users, true. But not all (indeed, VERY FEW) end users are programming/computing gurus. In this environment (LWN) I may not be anything special, but *both* in my work and home environment I am a goliath amongst midgets.

In that sort of environment, where do I learn the things, that to you are second nature?

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 23:47 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

"Limited availabity" does not mean "in widespread use".

Yes, but perhaps Emacs would be in more widespread use if more people knew about Magit (and org-mode, and all the other goodies that make Emacs so unique and incredibly powerful).

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 10:29 UTC (Tue) by Wol (subscriber, #4433) [Link]

And again, you are falling totally into the trap of assuming "everyone is like me".

I've already said I'm very much ALONE amongst my peer group of being a computer expert. MY peer group (which is far more representative of the general workforce than yours) wouldn't have a clue what a SCCS is if you hit them over the head with it! Even less a DVCS!

I don't have a problem with other peoples' opinions (we can all disagree quite friendlily?) UNTIL they assume their opinions apply to the majority. Guess what! We are a VERY SMALL minority!

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 20:02 UTC (Mon) by marcH (subscriber, #57642) [Link]

> You don't need the staging area if ...

BTW: https://lwn.net/Articles/949963/ (in "Evans: Confusing git terminology", Nov. 2023

> The staging area is unnecessary complexity. It's completely superfluous.

24 answers :-)

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 5:39 UTC (Sun) by roc (subscriber, #30627) [Link]

Yes, and that's all much more tedious than it needs to be.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 9:44 UTC (Mon) by geert (subscriber, #98403) [Link]

Yes you can!

(a) Interactive rebase to the commit in question (called "sha1" below),
(b) Revert the parts you don't want to be part of the first commit.
This can be as simple as "git show -- path/to/file/ | patch -p1 -R" if you just want to revert all changes to one file, or "git show > d", "vim d", "patch -p1 -R < d" for more complex cases.
(c) "git commit -a --amend", to edit the commit message for the first part,
(d) "git cherry-pick <sha1>" to pick up the remaining parts,
(e) "git commit --amend", to edit the commit message for the remaining parts.

To split in more parts, have more b/c/d steps in between a and e.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 9:15 UTC (Sun) by jengelh (subscriber, #33263) [Link]

>when you have already-committed changes that you decide to split up further, git is not helpful

Works for me, and complexity is reasonable enough to not warrant wrappers like stgit.

$ git log --oneline
777777 sample
666666 sample
555555 sample
$ git rebase -i 666666^ # and insert 'x bash' before 666666 or $ git rebase -i 666666^^ # and mark 555555 as 'edit'
$ git checkout -p 666666 # select hunks you want
$ vi blah.c; make; git add (-p); # fixup some more if needed
$ git commit -c 666666 # commit first part of 666666 -> 66666a
$ git rebase --continue # commit second part of 666666 -> 66666b, 777777, etc.

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 22:23 UTC (Sat) by madscientist (subscriber, #16861) [Link]

Seems like it will work with proper tooling around it.

FYI the way I usually work is edit edit edit ... oh, this hunk and that hunk and this other one over here are really part of a different commit: pop up a Magit buffer, select those various hunks into staging, make a commit from them. Edit edit edit, rinse repeat.

After a while you have 10-15 (or more) "partial commits" that you want to turn into 2 or 3 or 4 "real" commits. Pop up a Magit buffer and enter interactive rebase: move the partial commits around into the right order and next to each other and squash the parts together and make a real commit message. If you accidentally have too much stuff in a commit mark it for edit and split it.

Then you're done.

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 23:04 UTC (Fri) by thoughtpolice (subscriber, #87455) [Link] (1 responses)

Yes, there are various tools to move changes between commits and chop them up, including `jj move`, `jj amend`/`jj unamend`, and `jj split`, and they're quite easy and simple to use. For example, you can `jj move --from xyz --to abc README.md` to only move the changes in the file README from change xyz, to abc. `amend` and `unamend` are basically specializations of `move`, for the current working-copy-commit and the parent change. I use these probably dozens or hundreds of times a day, actually. They also can all be invoked in --interactive mode so you get a terminal TUI to select individual hunks or lines out of files, for a more granular experience. (And that TUI comes built-in; you don't need to install third party tools for it to work out of the box.)

The idea isn't really that the index is useless; quite the contrary. I chop commits up with far more power than I did before. Rather, it's just that you can represent these multiple concepts with a single design primitive. So, the index and the stash and those 'wip' commits we all put onto a quick temporary branch -- they're all the same thing now. They use the same vocabulary, the same verbs and nouns in the user interface, et cetera.

If you live in Emacs/Magit though, I suspect prying yourself away from it will be hard, even despite that. :)

Disclosure: I am a contributor to Jujutsu (not Google or otherwise work affiliated.)

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 22:13 UTC (Sat) by madscientist (subscriber, #16861) [Link]

Yes, Magit hides many sins.

I'm looking forward to Emacs Majutsu!

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 7:29 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

I agree that the index is probably the most difficult to grasp specificity of Git, yet one of its most powerful feature when you finally understand how it works. When I develop, I usually spot bugs in areas I visit, that are unrelated to what I'm doing and I'm quite happy to fix all of that at once, sometimes making a temporary commit for certain changes that I'll rechange later, sometimes deciding to do that manually at the end. I, too, use interactive add a lot, I even edit the patches on the fly to commit certain changes in multiple steps, since git's patch parser is extremely permissive. That's convenient for example to insert a preliminary change that only reindents an enum in preparation for larger names before adding the new feature, all of this done at once via the index, without ever having to have written a version of the temporary step. It's super convenient and even a little bit addictive, given how efficient it is. For this reason alone, I sometimes feel very sorry for some people developing in bloated IDEs or web interfaces (e.g. github) without all these facilities. In fact the result is visible in their commits, tons of unrelated stuff merged at once, they tend to use commits just as points in time like a snapshot system...

Jujutsu: a new, Git-compatible version control system

Posted Jan 19, 2024 22:48 UTC (Fri) by arxanas (guest, #169225) [Link] (50 responses)

The stashing explanation could certainly be improved. Regarding stashing itself, there's simply no further deliberate operations you need to do to save the work, as the working-copy commit is the stash. You would just switch to another commit as normal — which is the same workflow as for non-stashed work. My guess is that's the mindset under which "not needed" was written there.

When you want to return to your stashed work, you can do so by inspecting the log to find its ID and then switch to that. You would have to deliberately throw away your work with jj abandon if you didn't want it anymore. (This aligns with research on how novices use Git: they actually expect their working-copy changes to "stay" on the currently-checked-out branch rather than "coming with them" when they switch commits.)

We could update the table entry to jj new @- (check out the parent commit, as you ascertained), if you think that would be helpful?

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 0:16 UTC (Sat) by josh (subscriber, #17465) [Link] (49 responses)

Yes, I think showing jj new @- in the table would help people who have the use case that currently motivates git stash. And the model does seem reasonable; I do it already with git sometimes, by doing git commit -am WIP and then checking out something else.

Any way you can do something about the CLA? Either internally at Google, or by doing a bit of jujutsu :) by having an external contributor move the project to an external shared home that isn't owned by Google (e.g. https://github.com/jj-vcs/jj)?

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 0:33 UTC (Sat) by thoughtpolice (subscriber, #87455) [Link] (48 responses)

I don't think the CLA is negotiable; there are plans to move the repository to a separate organization at some point, but we haven't had a need for it. Martin originally started the project in his 20% time while working on the Google Source Control team, but the plan as of 2022 is for jj to replace the internal version control client Google currently uses (a forked version of hg, called "fig") and so it is his full-time job, now, with some commitment behind it. I don't think the location of the repo is really the issue; it's more where the project came from, and if it was forked and the repo run by someone else who didn't have the CLA; well, Google probably just wouldn't allow Martin to contribute to that version. But I suppose I cannot speak on Martin's behalf.

I feel it's important to note that Google's Open Source CLA doesn't actually transfer ownership of anyone's copyright or ownership of the changes; they remain under the Apache 2.0 license, and you still own them (unlike the CLAs used by HashiCorp or the FSF, which transfer ownership.) That's better than the alternative but I admit it's a thorn, in particular there is a separate corporate/organization CLA, so it can and does honestly get in the way of some places to a reasonable extent (smaller institutions like universities that may have to review it, but they probably aren't equipped to really care so it just doesn't happen). I'm not sure if the distinction matters to you but feel it's important to mention with stuff like HashiCorp in recent memory.

Disclosure: I'm a contributor to Jujutsu, but I don't work for Google or anything like that.

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 2:00 UTC (Sat) by josh (subscriber, #17465) [Link] (47 responses)

Google uses and contributes to non-Google projects that don't have CLAs all the time.

I hope that this issue can be fixed, so that jujutsu (rather than a future successor to it) can become a reasonable choice for Open Source usage.

> I'm not sure if the distinction matters to you but feel it's important to mention with stuff like HashiCorp in recent memory.

It does not, no.

Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 15:59 UTC (Sat) by khim (subscriber, #9252) [Link] (46 responses)

> Google uses and contributes to non-Google projects that don't have CLAs all the time.

Sure. If someone else pay the principal developer. Do you volunteer to hire Martin von Zweigbergk and pay for the development of Jujutsu?

> I hope that this issue can be fixed, so that jujutsu (rather than a future successor to it) can become a reasonable choice for Open Source usage.

Open Source folk are usually perfectly happy to use stuff made by Google. It's Free Software guys who think they are entitled to ask for help and then demand that help would be offered on their terms.

The big question is whether Jujutsu would be adopted inside of Google. If that would happen then it would be much harder to cancel it.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 2:45 UTC (Sun) by Conan_Kudo (subscriber, #103240) [Link] (45 responses)

Open Source folk are usually perfectly happy to use stuff made by Google. It's Free Software guys who think they are entitled to ask for help and then demand that help would be offered on their terms.

This is not only unfair, but wrong. Many "Open Source" folks are unhappy about how Google runs their projects, but like everyone else, we don't really have much choice sometimes on whether we can avoid it.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 4:03 UTC (Sun) by khim (subscriber, #9252) [Link] (44 responses)

People may dislike CLAs and thus may keep patches to themselves, but only free software zealots are postulating that others have to change how they are doing things or else they wouldn't even touch something.

Please read again: josh says that CLA have to go for merely for the Open Source usage (not development!).

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 4:11 UTC (Sun) by Conan_Kudo (subscriber, #103240) [Link] (4 responses)

I don't disagree with that statement either. Ideally usage begets contribution, so we shouldn't put people in a situation where they have to sign weird documents when they want to contribute a fix or improvement based on their usage of the tool.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 4:26 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

Well, FSF was asking contributors to sign weird documents when they want to contribute a fix or improvement for years. In fact it's worse with FSF: while Google only asks for license and patent grant, FSF demands that you pass over all rights to what you are creating to them!

Sure, they give you a license to use your own code, but still… that's passing all the rights compared to just grant of the license…

Yet, somehow, animosity is reserved specifically just for the Google?

Paint me unimpressed.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 8:38 UTC (Sun) by josh (subscriber, #17465) [Link] (2 responses)

I think *all* CLAs are a bad idea. Including the FSF's, to be clear. There's no Google-specific animosity here, nor is there animosity at all, just advocacy.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 15:05 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Could the problem here be a "certificate of authenticity" problem? Like the kernel's "signed-off-by tag" or whatever it's called?

I know I don't understand the kernel's setup, and I gather there's quite a bit of cargo-culting there, so it's quite a hard problem to solve, but it's trying to get a cast iron guarantee that the person contributing a fix actually has the right to contribute it.

I certainly get the impression that certain sub-system maintainers demand certificates (or they won't merge a patch) from people who clearly have no authority to grant them, so ...

The only way to securely fix the problem is to have something like a CLA where a lawyer quizzes you and says "you DO have the right to contribute this patch, don't you?".

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 21:29 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

The kernel's DCO (Developer's Certificate of Origin) is quite different to signing over rights AIUI. But that's as much as I'll speculate on differences, but at least I can contribute the name of the thing :) .

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 14:26 UTC (Sun) by apoelstra (subscriber, #75205) [Link] (37 responses)

>but only free software zealots are postulating that others have to change how they are doing things or else they wouldn't even touch something.

Maybe I'm misunderstanding you, but this seems wrong. People boycott stuff all the time. Sometimes to try to send a message, but often simply because they're trying to minimize the inconvenience in their lives.

For example sometimes I'll try to sign up for a service and they have weird password constraints on their signup page. If there's a similar competitor I'll just shrug and switch to that. As a security researcher I do have some moral feelings about how there shouldn't be such constraints, but life is short and I push those aside in favor of a simple practical "I'll use the site where I can signup in one step, vs the one where I need to edit the output of my password manager, probably only to find more hoops to jump through once I'm past this step".

A CLA is a similar thing. It's a pain in the butt so I won't do it. I would guess that most people who refuse to sign CLAs feel the same way. And this applies equally to the FSF or Google.

(Having said that, if Google had a CLA where you actually did transfer copyright to them, I can see people balking at the idea that they'd be "working for free" for a for-profit company. But it sounds like that's not what's happening here, and it's not what I see people complaining about here.)

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 20:25 UTC (Sun) by khim (subscriber, #9252) [Link] (36 responses)

> Maybe I'm misunderstanding you, but this seems wrong. People boycott stuff all the time.

Sorry, but no.

> Sometimes to try to send a message, but often simply because they're trying to minimize the inconvenience in their lives.

So when I'm skipping Kohlrabi in the supermarket because I don't like it that's called boycott?

Sorry, but I don't think so.

There's world of a difference between ignoring things you don't like and actively demanding from others certain things.

> I would guess that most people who refuse to sign CLAs feel the same way. And this applies equally to the FSF or Google.

Yes. But not everyone stops using things just because there's CLA which you need to sign to contribute. In fact I know of precisely zero people who are using neither gcc nor clang (and both projects required CLAs till very recently).

It's one thing to say that you wouldn't contribute to Jujutsu till CLA would be removed. It's weird that few clicks on the web site are that awful that you would refuse to contribute because of them, but whatever. There are legal consequences and you may want to avoid them

It's entirely different thing to demand that Google should stop using CLA or else your wouldn't even use that product.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 10:49 UTC (Mon) by spacefrogg (subscriber, #119608) [Link] (34 responses)

I think you are the one confusing things here.

Whining about free software programmers "demanding" things, when, in fact, Google is demanding something, a CLA in return for other people's mental output. And they have every right to. Now, those "demanders" of yours, they just won't contribute and it will deminish the input of bright ideas that jujutsu might have had.

How you put that moral dilemma on the shoulders of people wanting to contribute their efforts under their terms, is beyond me. What do you expect how the world should be run? Of course I negotiate the rules for my own contributions! What else should I do instead?

Nobody should contribute to code that is owned by a company for free. Under no circumstances. This is a) distorting the labour market of programmers and b) should constitute tax fraud on behalf of google. They should be obliged to pay and care for their employees. (For all(!) of them!)

Jujutsu: a new, Git-compatible version control system

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

> Now, those "demanders" of yours, they just won't contribute and it will deminish the input of bright ideas that jujutsu might have had.

Not only they wouldn't contribute, they would whine a lot about how they couldn't use things if there are JavaScript involved, about how they would fork the project if someone would do things differently from how they like (read the whole sentence, please, it's not long: I hope that this issue can be fixed, so that jujutsu (rather than a future successor to it) can become a reasonable choice for Open Source usage.

They automatically assume jujutsu would fail just because of CLA and there would be some king of successor, for crying out loud!

Sure, jujutsu may still easily fail, but that wouldn't happen because of CLA, that's for sure.

> What do you expect how the world should be run?

I know how the world is run, that's the issue. Free Software zealots don't know that (or, more precisely, refuse to accept that knowledge).

> What else should I do instead?

How about creating these oh-so-valuable contributions? Patches, fork, whatever.

Then you may decide whether they are valuable enough to demand something. Sometimes this even works (like happened with Go-oo), but most of the time your contributions would either be ignored or duplicated instead.

Don't throw around an empty threats if you don't actually plan to act on them. If you have no real desire or plan to create these oh-so-valuable contributions then don't whine about CLAs, once you'll have them you may create a fork or do something else.

> Nobody should contribute to code that is owned by a company for free. Under no circumstances.

And now you go again and decide about other people what they are supposed to do. If you don't like CLAs, or don't like corporate projects or don't like some other things then do something about that.

> They should be obliged to pay and care for their employees. (For all(!) of them!)

And they should stop giving Jujutsu away for free because then it's hard to make living from the Bitkeeper. Yawn. I heard that before.

Please, make something valuable and then discuss your plans about doing something with it.

Nobody is interested in hearing what you wouldn't do. And nobody would change anything till you would convincingly show that change benefits them (not just you).

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 12:24 UTC (Mon) by Wol (subscriber, #4433) [Link] (22 responses)

> And now you go again and decide about other people what they are supposed to do. If you don't like CLAs, or don't like corporate projects or don't like some other things then do something about that.

> > They should be obliged to pay and care for their employees. (For all(!) of them!)

I'm planning to write into my code for Scarlet, a royalty-free licence for Ladybridge software to use any and all of my Scarlet code. Doing exactly what you say I shouldn't - giving a company a free pass!

The reason is dead simple. They donated the original code base that became Scarlet. Why *shouldn't* I donate back, IN GRATITUDE, if I want to!

(There's another reason too - I'm learning the hard way why companies don't like Open Source software). If Scarlet does collapse - and I have no intention of letting it do so - all the users will have the CHOICE of moving to the commercial version if they want to. I'M PROTECTING MY USERS.

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 16:04 UTC (Tue) by spacefrogg (subscriber, #119608) [Link] (21 responses)

Companies are not people! Companies cannot be gracious or nice or happy or caring. Like, you really think that? Companies should not allowed to give anything substantial away for free as this has been proven to be a regular means of the primus to destroy competition early on. Usually, there are regulations against selling products under value. It is just that, for some reason unbeknownst to me, these laws never seem to be applied to software.

Let me repeat, it is bad for society if companies are allowed to give stuff away for free, because this creates a situation where people easily get dependent on the free stuff. At some point it is (wonders of the capitalism) not free anymore, but people still depend on it. We have already discovered this to be a worse situation than enforcing proper sales rules right from the beginning.

I don't understand how programmers really think they are inventing something radically new, here. No, "free stuff" has long been discovered before the first computer program was ever written. And there are rules for how to deal with that as a society, for a reason. All this is really not that hard to comprehend, once you replace MY_FAVORITE_SW with a physical product.

Creating a dependence on a company-owned product by giving it away for free is not okay.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 16:41 UTC (Tue) by Wol (subscriber, #4433) [Link] (18 responses)

Do me a favour! DON'T tell other people what to do!!!

> Companies are not people!

Who says? I know the guy pretty well (well, as well as you can know someone over the internet).

> Let me repeat, it is bad for society if companies are allowed to give stuff away for free,

Okay. Let's ban free stuff. Let's ban all Open Source software, let's ban all Free Software, let's ban Barn Raising, let's ban what we call American Suppers, let's make caring for your neighbour a criminal offence!

Scarlet is Free Software. And if I choose to express my gratitude to the PERSON who released it under the GPL, that's down to ME, not you.

And if I choose to protect my users by giving them the CHOICE to go back to him, if they so want, as their upstream then that's down to ME, not you. Are you REALLY saying it's for the best to expose my users to a bus factor of one, so if anything happens they're up shit creek without a paddle?

Free Software is all about CHOICE, and this is MY choice, not yours!

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 16:57 UTC (Tue) by paulj (subscriber, #341) [Link] (17 responses)

I don't think they were arguing to abolish Free Software or barn-raising.

I think they were arguing against large companies releasing free (as in beer) software as loss-leaders, to destroy value in markets and hurt any competition, and try gain (or hold) some monopoly position for themselves. Typically, where a company can succeed in this - i.e. the company with the deepest pockets, and the most ability to subsidise the loss-leader from revenue from other markets - it will later use that to gouge consumers in some way, be it by prices on the product directly or using control over the free product to force consumers into other paid products. Once monopoly has been created, investment tends to decrease, people working on it tend to become complacent - quality of the product also tends to suffer and/or innovation declines.

As an example, remember Microsoft and Netscape? MS bought a browser, bundled it for free into Windows - all paid for by their Windows and Office licensing revenue - and thus destroyed Netscape's ability to earn revenue.

MS eventually faced anti-trust actions, and lost.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 18:05 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> MS eventually faced anti-trust actions, and lost.

... did they really lose?

After all, the legal penalties they were eventually saddled with were even less than a slap on the wrist compared to the direct and indirect profits they made.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 18:41 UTC (Tue) by khim (subscriber, #9252) [Link]

They were important to make Chrome viable, although I'm not sure whether this should be considered success or not.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 10:33 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

They lost the ruling, so they lost for sure. They had to unbundle IE too and give other browser equal opportunity to be the default browser.

If not for that, Internet history could be quite different.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 14:30 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> They lost the ruling, so they lost for sure.

They lost _on paper_ but by that point they long since accomplished what they set out to do, and are _still_ reaping the benefits. The fines they faced were a pittance, and the "default browser ballot" BS was per formative nonsense, because by that point IE was intimately tied into the entire MS business software ecosystem and _completely_ owned the corporate desktop + backend.

(What eventually broke that wasn't the browser ballot, but the rise of the modern smartphone)

> They had to unbundle IE too and give other browser equal opportunity to be the default browser.

Um, IE _never_ ceased to be bundled with MS Windows. It is a core component of Windows. [1] At best, the only thing "removed" was the icon that launched the "browser wrapper" around that built-in component. (Sure, it's now called "Edge" and is built on the Chrome engine instead of Triton, but it's still just as proprietary and intrinsicly bundled as ever!)

[1] An embedded browser engine is a core component of every OS, commercial or otherwise. released since Windows 98, and it's _not_ replacable.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 15:02 UTC (Wed) by paulj (subscriber, #341) [Link]

Oops, I managed to put my reply to you in another subthread. See: https://lwn.net/Articles/959326/

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 22:47 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

> I don't think they were arguing to abolish Free Software or barn-raising.

The problem is "where do you draw the line?" I know I was being hyperbolic, intentionally, but seriously, do we want to ban giving things away?

And if giving stuff away is anti-competitive, then we should make anti-competitive behaviour illegal, not make giving stuff away illegal.

In this particular case, there are (or rather were) a couple of big contenders. There's Pick Systems (aka Raining Data, aka Tiger Logic, aka maybe a few other names too). Then there's INFORMATION, UniVerse, and Unidata, who merged into Ardent, aka Informix, aka IBM.

Then there were the minnows, jBase, QM, Reality, and Cache/MV. Ladybridge, aka a guy called Martin Phillips, was persuaded to release QM as the GPL OpenQM. (Incidentally, I didn't know that the "Open" has nothing to do with Open Source and everything to do with Open Systems aka commercial Unix! An earlier product, PI/Open, used the term Open in the same way, hence the inspiration for "QM on Linux" to be called OpenQM.)

Unfortunately, a company called Rocket has bought out pretty much all the commercial players, and the only real competitors left are Scarlet, Reality, and another minnow called OpenInsight. For example, I think the price of OpenQM has quadrupled since it was absorbed into Rocket a few years ago. UniData / UniVerse were always on the expensive side, but Rocket has raised the price of everything else to the same level.

I think that's why some of us want Scarlet as a viable competitor, but there's no way I want to leave potential Scarlet users up a gum tree if anything goes wrong, and given my experience trying to get Scarlet into my employer, I actually see the existence of a commercial version as a plus. I hope they come to see the existence of the Open Source version as a plus, too.

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 10:38 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

Well yes, it is the anti-competitive behaviour that is unlawful.

Anti-competitive behaviour can be 1 large monopoly player abusing that position. It can also be all the corporate players in a market behaving in a certain way, which then undermines the competitiveness and interests of the programmers supplying the labour - which was spacefrogg's point.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 12:54 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> It can also be all the corporate players in a market behaving in a certain way, which then undermines the competitiveness and interests of the programmers supplying the labour

But that's called a Cartel, which is just as illegal as anti-competitive dumping. You don't make giving things away illegal. If giving things away is part of wider misbehaviour, you tackle the misbehaviour, not the giving away.

And while I'm not going to say the company I'm talking about was a one-man-band (I really don't know), it was pretty much a one-pony show, even if there was a supporting cast.

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 13:40 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Who is arguing for banning giving things away? You've invented an argument that spacefrogg hasn't made!

AFAICT, spacefrogg was arguing against anti-competitive behaviours by corporates, including where the labour market is the victim of the anti-competitive behaviour. You are obviously aware of competition law. Not sure why you're arguing against positions no one here seems to have taken.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 15:36 UTC (Wed) by Wol (subscriber, #4433) [Link]

> Who is arguing for banning giving things away? You've invented an argument that spacefrogg hasn't made!

To quote spacefrog himself ...

> Companies are not people! Companies cannot be gracious or nice or happy or caring. Like, you really think that? Companies should not allowed to give anything substantial away for free

If that's not spacefrog arguing for banning giving things away, I don't understand English !!!

Okay, and I admitted it, I've gone a bit over the top and taken his argument to an extreme. But it was his argument first. And as soon as you start getting into "where do you draw the line" you're going to end up in a war between the anarchists and the dictators. I'm firmly on the side of "(VOLUNTARILY!) giving things away is a good thing". If it's done with malicious intent, then you target the malice, not the gift.

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 7:10 UTC (Wed) by rqosa (subscriber, #24136) [Link] (6 responses)

> MS bought a browser, bundled it for free into Windows

Bundling an application into an OS is not exactly the same thing as giving that application away for free, especially at a time when…

> MS eventually faced anti-trust actions, and lost.

…the OS in question held a de-facto monopoly position in the market for desktop-PC operating systems. (MS having that de-facto monopoly was the main reason why they were hit with an antitrust lawsuit, after all.)

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 13:44 UTC (Wed) by paulj (subscriber, #341) [Link] (5 responses)

The issue that led to the antitrust case in the USA was the web browser, and MS leveraging their Windows monopoly to bundle IE for free into Windows, destroying the market for Netscape and making it technically difficult for other browsers such as Netscape to fully work as default browser on Windows.

Are other cases, inc. ones that spacefrogg may be worried out, different in their details? Sure. Still potential anti-competitive behaviour if some large corporate uses free products undermine the market for other actors (inc. those supplying labour).

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 15:01 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

My memory is MS actually had to provide a version of OEM Windows with IE unbundled/removed to vendors who wanted it. The library might still have been there, but there wasn't an IE app.

One of the reasons for the suit being that Netscape had had deals with PC makers to ship PCs with Netscape installed, which then became awkward / suboptimal when MS bundled IE and made it hard to set other browsers as default (fully). The ruling provided some relief on that. I don't know if many vendors went for that unbundled OEM version though - 1 did I thought, but that's my vague recollection. Part of how they got away with so little punishment was the Clinton admin got replaced by Bush.

Did it address all the issues, did it right all wrongs MS did with anti-competitive behaviours? No. But it did damage their reputation, it did put some kind of check on them, and it was the catalyst for further competition law investigations and restrictions put on them. E.g., the EU required them to open up protocol specs, and stop stymying projects such as Samba. They also got a massive fine and had to unbundle WMP cause of EU actions.

Things would certainly be much much worse now if MS had been left completely unchecked.

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 1:58 UTC (Thu) by rqosa (subscriber, #24136) [Link] (2 responses)

> Things would certainly be much much worse now if MS had been left completely unchecked.

Case in point: this

> Every new PC sold with Windows 8 will be locked up tight with Microsoft's UEFI ... secure boot on

Not that I don't agree that there's a potentially dangerous precedent here, but this is omitting a key detail. For x86 computers, MS's certification requires that users can disable secure boot. (emphasis mine) Of course, this is not true for ARM computers, hence the dangerous precedent.

I don't remember the exact details, but for some reason I'd been under the impression that the final settlement with the DOJ in that 2001 antitrust lawsuit in the U.S. had the effect of imposing that requirement that PC owners must be allowed to disable Secure Boot. (Or if not specifically that one, then maybe the 2004-2007 antitrust action in Europe is the one that forced MS to not prohibit end-users from disabling Secure Boot instead?)

(see also this Q/A on superuser.com for some more technical details that might be relevant here)

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 13:34 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

The UEFI disableable-secure-boot thing was driven by the fact that Windows 7 had major issues with UEFI booting, and large PC makers (and their customers) wanted to keep using Windows 7 on new hardware at least until the initial teething problems with Win8 were handled.

As it turned out, Win8 was so bad that most folks downgraded it to Win 7 (via an officially-sanctioned-by-Microsoft mechanism), and the status quo didn't really change until Win 10.

This had nothing to do with any antitrust action, and everything to do with actual market forces.

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 14:12 UTC (Thu) by Wol (subscriber, #4433) [Link]

> This had nothing to do with any antitrust action, and everything to do with actual market forces.

Mess-up or not, I'm pretty certain it was rather more than market forces. The EU is keeping a close eye on Microsoft, and I'm pretty certain it got pushed through as "If MS is allowed to do that, then it's a pretty safe bet that consumer hardware will ONLY be able to run Windows". Hence the requirement that buyers MUST be able to disable Secure Boot, if they so wish.

Cheers,
Wol

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 0:17 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> The issue that led to the antitrust case in the USA was the web browser, […]

The real reason I posted that comment was to dispute spacefrogg's statement that "it is bad for society if companies are allowed to give stuff away for free, because this creates a situation where people easily get dependent on the free stuff", on the basis that a monopolistic company (e.g. Microsoft circa 2001) should not be considered equal to a smaller & less-powerful company (e.g. Netscape circa 2001), let alone to a non-wealthy individual person (e.g. some random hobbyist programmer who has some Git repos hosted on Codeberg today).

Antitrust law (both in the US and in the EU) certainly doesn't treat monopolists the same as non-monopolists, by design. And for good reason, IMO.

> […] and MS leveraging their Windows monopoly to bundle IE for free into Windows

Exactly my point: MS's Windows monopoly was a necessary condition which needed to be met in order for the government to sue MS (for violating antitrust law).

Jujutsu: a new, Git-compatible version control system

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

Usually, there are regulations against selling products under value. It is just that, for some reason unbeknownst to me, these laws never seem to be applied to software.

The usual regulations apply to selling products below the marginal cost of production - if mining 1 gram of unobtanium and shipping it to me costs you $1,500, then you cannot sell unobtainium to me for less than $1,500 per gram; if the mining is $500 of machine time, and shipping is $1,000, that sets your lower bound. However, the cost of finding unobtanium deposits, and of designing and building the mining machine, are ignored for this analysis; it may cost you billions of dollars in analysis to find each gram of unobtanium, or trillions of dollars to design and build a mining machine that works long enough to mine 10 grams before needing replacement, but that's ignored by the rules.

So, for example, you can't sell DRAM chips at less than the cost of making a DRAM chip; you can sell them cheaply, but it must be possible for someone who owns a semiconductor fabrication plant to make DRAM chips at or above the price you sell them for. Note, though, that semiconductor fabs are expensive, but that cost is not taken into account here; it's assumed that you already own one for the purposes of determining if you're selling DRAM chips at a loss, and so what's accounted for is the cost of silicon wafers, dopants, chemicals and electricity (over and above that consumed if the plant is idling waiting for an order) to run the plant for the duration of a batch of DRAM chips, etc.

Software escapes from this because virtually all the cost of software is in the analysis and design phases, which are outside the rules; the marginal cost of one more copy of a piece of software that already exists is tiny (what's the total cost of transferring 1 GiB from my server to yours, given that the cost of the server and the Internet connection are already paid, and it's only the additional electricity over and above idle that counts?), and the rules say that it's only those marginal costs that matter.

Also, importantly, this has only become a significant issue now that electronic distribution is cheap; in the days when software came on physical media (tapes, disks, CDs, DVDs etc), your bound on the price was set by the cost of the medium you were using; if getting a DVD pressed costs you $500 per thousand disks, your lower bound on price is $0.50. With Internet distribution of software (or music or video for that matter), your lower bound is some tiny fraction of a cent, and accounting rules let you write it off because it's so small; for example, if you use (chosen at random) Backblaze to store software for distribution, then your marginal cost is at most $0.01/GB plus $0.0000004 per copy. For a piece of software that's 10 MB in size, that's close enough to zero to be a permissible write-off.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 22:31 UTC (Tue) by kleptog (subscriber, #1183) [Link]

> Let me repeat, it is bad for society if companies are allowed to give stuff away for free, because this creates a situation where people easily get dependent on the free stuff. At some point it is (wonders of the capitalism) not free anymore, but people still depend on it.

I don't think that argument works here. Google is not delivering a product, they're delivering source under an open-source license. Publishing it doesn't make people dependant and if Google goes away you still have everything had before, so there's no downside. You can do anything with this source that you like, including selling it. If Google decided to start charging, you could just fork it and start a competing community without any loss of functionality.

The CLA isn't giving Google any special powers, since anything you grant to Google is also granted to everyone they distribute the source to which is basically everyone. It's mostly just making explicit which would otherwise be implied (ie. if you make a contribution, then Google may presume you have the rights to do so. In the normal course of business this is the default position, but having it spelt out explicitly is not a bad thing when dealing with international contributors.)

KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts

Posted Jan 24, 2024 1:25 UTC (Wed) by rqosa (subscriber, #24136) [Link] (6 responses)

Contrary to what you seem to be implying with all of this pro-"Open Source" / anti-"Free Software" us-versus-them rhetoric that you've been posting here recently: pretty much every so-called "Free Software zealot" who's risen to prominence in recent years (such as Rebecca Giblin and Cory Doctorow, maybe) are much more similar in terms of their general ethos, sensibilities, and worldview to both the original "Open-source software" advocate from 1998 and the main person to whom Firefox & Thunderbird users owe their gratitude for the fact that those two apps exist in the first place — neither of whom have ever been pro-FSF partisans or (in your preferred terminology) "Free Software zealots" — than they are to pro-FAANG partisans who want the general public to believe that the upper management at those megacorporations are good guys who usually act in the best interests of "Joe Average" (i.e. the general public), I'd say.

> I know how the world is run, that's the issue. Free Software zealots don't know that (or, more precisely, refuse to accept that knowledge).

From reading your comment above while keeping in mind the fact that, at roughly the point in time that ESR mentioned in this part of his book from 2003, a sea change took place in the way that "the world" (or, more precisely, the IT industry) was run:

By late 1993, […] the long-awaited dream of a cheap Unix system for everybody had snuck up on them from an unexpected direction. It didn't come from AT&T or Sun or any of the traditional vendors. Nor did it rise out of an organized effort in academia. It was a bricolage that bubbled up out of the Internet by what seemed like spontaneous generation, appropriating and recombining elements of the Unix tradition in surprising ways. (emphasis mine)

…and also keeping in mind what jwz wrote (in his anti-Instagram polemic from 2016) about another sea change in the IT industry that also occurred in the mid-1990s (and was at least partially caused by the exact same event that ESR referred to above):

All of the "social media" services want to lock you in. That's been the case for a while. They love their "walled gardens" and they think that so long as they tightly control their users and make it hard for them to escape, they will rule the world forever.

This was the business model of Compuserve. And AOL. And then a little thing called The Internet got popular for a minute in the mid 1990s, and that plan suddenly didn't work out so well for those captains of industry. (emphasis mine)

…I get a strong impression that what you actually WANT to happen sometime soon is for the IT industry to revert to being run in a very similar way to how it was a few years before those two sea-changes took place in the mid-'90s!

So then, in order to accomplish that goal, you've called for national governments to hold every last bricoleur/hobbyist programmer to the same level of legal liability that smartphone hardware companies (like Motorola/Lenovo, Asus, or even Google themselves with their Pixel product line) will be held to in the near future, thereby ensuring that never again will any such hobbyists be allowed to develop software that poses a threat to any present-day equivalent of the "traditional vendors" that ESR referred to there (such as SaaS vendors in general, and/or any of the current "Big Five" tech companies), as happened throughout the 1990s.

At least twice recently, you've almost explicitly said that you want EU legislators to enact laws that would have that effect on to hobbyist developers, for example here:

> if you are creating a GitHub page and write README there then now you are marketing something

…and also here:

> And you may bet pretty large sum on the desire of EU legislators to keep these small guys around. [with "these small guys" being some hypothetical hardware company "that produces DVR based in MythTV"]

> That, by necessity implies that large open source “forges”, if, maybe, not individual contributors, would have to deal with liabilities.

If a law like that were ever to be enacted, it would likely end up preventing any new bricolage (meaning a hobbyist-led project, like KDE) from bubbling up out of the Internet to eventually reach KDE's level of fame & popularity ever again! Do you really want that to happen?

(Remember: back in KDE's early years, approximately 100% of its developers — including Lars Knoll, David Faure, and Matthias Ettrich, among many others — fit the aforementioned "hobbyist programmer" description while at the same time not being pro-FSF partisans. Even today, most of the commits/contributions to Git repos hosted on invent.kde.org come from hobbyists, IIUC.)

But, fortunately for anyone who fits any of these descriptions:

someone who runs Plasma on their own "daily driver" desktop PC;
or, someone who is a currently-active KDE contributor;
or, someone who has any Git repos with README.md files hosted on invent.kde.org or anywhere else on the Web;
or, most importantly of all: someone who has (or wants to have) a publically-readable portfolio/showcase of their own programming work available on the Web, so that the HR departments of their own potential future employer(s) can take a look at it

…it looks like several other LWN commentors disagree with khim on the topic of what kind of law the EU legislators really want to enact, e.g. bluca here:

> A readme, or a website, are not equivalent to marketing a product.

…and also Wol here:

> The crucial words here are "and markets them". If you look up the definition of marketing, it does not include "making available for J Random Passerby to help themself".

And I strongly suspect that those two commentors are correct in what they said there.

In conclusion, here's the TL;DR version (written for a target audience of any LWN readers who've ever used their own self-written open source software as a showcase for their programming abilities while searching for a job):

Whichever corporation you might have believed was your ally (against Microsoft, or against AOL/CompuServe/Prodigy et al.) during any of the past 3 decades is probably your enemy right now. That's because there are various big-money interests out there who see hobbyist-developed FLOSS projects — along with the hobbyist-oriented forge sites that host them (such as invent.kde.org, SourceHut, Codeberg, etc.) — as things which in the future might become existential threats to their own business model(s). This even applies to some corporations which on the surface appear to be FOSS-friendly (case in point: this).

Consequently, right now there's a danger that some people with deep pockets might try to lobby national governments into strangling those hobbyist-led FOSS projects with red tape!

KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts

Posted Jan 24, 2024 11:27 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

It's true that when RMS wrote his essay there was no separate well-defined “open source camps” and “free software camps”. That happened later when free software zealots rejected the peace offering.

And yes, we have to admit that free software zealots even managed to convince some people to release some software for free (Netscape, StarOffice). Credit where credit i due.

It's absolutely not clear how much that helped, long term (most browsers these days tack their ancestry not to Netscape source release, but to work of KDE guys who were, very much, an open source group (as evidenced by the fact that free software zealots rejected their work and started an alternate project instead, which very much split the community and in general probably caused more harm than good (although it's very hard to say for sure because we couldn't just look on the alternate history where GNOME never happened).

And what code these people have created recently?

Before the introduction of Open Source software two worlds were intermixed and it wasn't as obvious. Especially because some of most active “free software” proponents were also prolific coders (starting from RMS himself, but also Tridgell and some others). But after “grand separation” (which, again, happened because the free software camp insisted on it) number of people who were producing anything notable in the “free software” camp was dwindling and today it includes almost entirely people who try to force other people to act against their wishes and don't themselves create much new code.

It's not about about what I want, but about what may happen and what may not happen. And no, IT industry is not reverting to how it was run in the mi-'90s. Government control would be much more strict and chances of anarchy developments taking over would be slim.

That's what happened to every other industry, after all.

I guess some governments would fail to apply a tight leash and these government would fail… but that wouldn't lead to free software nirvana but to the proliferation of failed states where development of the software (free or otherwise) just wouldn't happen.

So then, in order to accomplish that goal, you've called for national governments to hold every last bricoleur/hobbyist programmer to the same level of legal liability that smartphone hardware companies

If you seriously think that I have this level of influence then you need to have your head examined. That's not what I want governments to do, that's what they will do, whether I like that or not.

If a law like that were ever to be enacted

When, not if. The question is only how many steps would it take to reach there. The end position is more-or-less clear.

Do you really want that to happen?

If you are sitting on the bottom of the mountain and notice that avalanche danger is increasing… do you want your lawn to be destroyed or not? If not then you don't scream at the mountains and don't threaten them, but rather prepare for the time when avalanche would actually happen. Sometimes it's even prudent to trigger avalanche early to reduce it's power. But crying about the fact that winter have come is just simply stupid.

IT industry wasn't regulated for too long and have grown too big and too influential to be left alone. That means governments would react harshly and would enact laws that would be more damaging than if industry would have guided them.

But free software zealots are still in denial and still believe they may stop that process if they would yell loud enough. Not gonna happen. And you know it, or else you wouldn't have been so angry.

And I strongly suspect that those two commentors are correct in what they said there.

They may be correct in describing the law as it's drafted today. If that's true then it just means that there would be a different law later, which would bring control and responsibility into the IT industry.

Consequently, right now there's a danger that some people with deep pockets might try to lobby national governments into strangling those hobbyist-led FOSS projects with red tape!

Wow. So much cope.

No, there are no such danger. Or maybe there is, but that part is pretty much minor and insignificant. We have just arrived at the time where products made by hobbyists would stop being used by non-hobbyists.

Like people are no longer using cars designed and made by hobbyists or radios designed and made by hobbyists. Except if they are hobbyists, of course, and even then they have to pass strict checks to be allowed to drive on regular roads or use their radios (except in certain niches dictated by governments).

That's the tectonic shift that IT industry would pass soon. Like every major industry passed before.

And if you want to say that this wouldn't happen then you should explain what differs IT industry from any other industry where that have happened already. Not try to write long screaming texts.

I, for one, couldn't see why IT industry should be different from dozens of other industries that have passed that path before.

KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models

Posted Jan 26, 2024 11:00 UTC (Fri) by rqosa (subscriber, #24136) [Link] (3 responses)

> when RMS wrote his essay

(Note: that link goes to Eric Raymond's 'Goodbye, "free software"; hello, "open source"' essay from 1998, not to anything that RMS wrote. Did you mean to write "ESR" there instead of "RMS"?)

> That happened later when free software zealots rejected the peace offering.

As of right now, there are very few people anymore who still believe that "separate well-defined “open source camps” and “free software camps”" ever existed.

The hard-binary distinction to which you're referring was more-or-less an illusion, not a real state of affairs. And from 1999 onwards, there have been an ever-increasing amount of hobbyist developers posting their work on forge sites, and this trend accelerated rapidly in the next decade when GitHub and Gitorious appeared on the scene. Collectively, these hobbyist developers definitely do not fall into separate well-defined “open source camps” and “free software camps”, and that's the way it's been ever since SourceForge debuted.

Now I'll pose this question: what, exactly, motivates those hobbyist developers to post their work on forge sites? Here's one major reason why they do that (which I already mentioned once): in order to publicly showcase their own programming work, so that people from their own potential future employer(s) can read & evaluate said programming work as part of the job-application process.

If regulators were to regulate these forge sites (Codeberg, SourceHut, invent.kde.org, etc.) out of existence, then that would have the effect of economically harming tech workers, by making it next to impossible for tech workers to showcase any fully-functioning software they've written themselves on their CVs, and thereby benefitting the employers at the expense of the workers.

> most browsers these days tack their ancestry not to Netscape source release, but to work of KDE guys who were, very much, an open source group

The historical background of KDE isn't very important in the context of the upcoming Cyber Resilience Act. Here's what really matters currently: KDE e.V. and Codeberg e.V. are both nonprofit orgs, neither of which have anywhere near as much financial resources as a giant corporation like Google. If the CRA were to cause KDE or Codeberg (or individual developers hosting their own software there) to be fined the same large amount of money for a security vulnerability in some software hosted on their GitLab/ForgeJo instances (invent.kde.org and codeberg.org, respectively) as Google would be fined for shipping a security vulnerability on tens of millions of Google Pixel handsets, that likely would ultimately cause this to happen: no hobbyist-developed software will be allowed to be hosted anywhere on the Web anymore, because all of the "forge" sites would have either been fined/sued into oblivion.

And if the CRA (or other similar legislation) is being lobbied for by Google thmselves or other similar giant companies, then that's a textbook example of regulatory capture! (However, I don't believe that's actually what's going on now w.r.t. the CRA itself — more details about this below…)

Alternately: regulation might instead cause forge sites to end up being "locked down" to the point where they host nothing but Git repos belonging to big corporations rather than hobbyists, along with requiring the companies hosting their software on the forge sites to sign contracts in which the company agrees to accept all legal liability for bugs in their own software so that the forge site itself isn't held liable for any bugs on software hosted there. That would have the same effect, though, of forcing hobbyist-developed software off of forge sites.

As for the historical background of KDE, though: your own timeline of events contradicts the statement that they "were, very much, an open source group". KDE Beta 1 was released in October 1997. That was before the point in time when (according to what you said) "free software zealots rejected the peace offering" (note: RMS wrote that essay in 1998, according to the copyright notice at the end of that webpage), and consequently before the point in time when (again, according to what you said) "separate well-defined “open source camps” and “free software camps”" sprung into existence.

(Also note: the earliest version of KDE's HTML rendering engine was part of kfm (KDE File Manager). I'm not sure what its exact release date was… maybe July 1998 (KDE 1.0) or March 1999 (KDE 1.1)? Though, as far as I'm concerned, that makes no difference as to which one of your so-called "camps" was the one to which the original group of "KDE guys" belonged… because, once again, any such hard-binary distinction between "camps" was really just an illusion.)

> as evidenced by the fact that free software zealots rejected their work and started an alternate project instead

Now you're calling Miguel de Icaza a "free software zealot"? If you really believe he was a "zealot", then here's a little something about the GNOME's early-ish days that you might have overlooked:

In the early 2000s, Nicholas Petreley occasionally wrote about Miguel de Icaza in his weekly editorials in Infoworld (an influential IT trade-press magazine, where Petreley was basically "the Linux and Java advocate guy" on their editorial board), and had nothing nice to say about him. Why? Because de Icaza is a dyed-in-the-wool Microsoft fan who made his own clean-room reimplementation of .NET and C# — that is, the Mono project — who also wanted Mono to become the main platform API for GNOME app developers to target, despite the fact that other people (including Nicholas Petreley, plus some developers of GNOME itself, plus some GNOME app developers) raised concerns that Microsoft might sabotage Mono — and, by extension, also sabotage GNOME and Linux as a whole — by using their patent portfolio to sue users of Mono or of any other clean-room reimplementation of .NET.

(Those worries about Microsoft and their patents are probably among the various causes that led to the creation of Vala.)

According to his Wikipedia article: de Icaza would later go on to work for Microsoft, even winning a Microsoft MVP award in 2010. (It also says that he had a job interview at Microsoft as long ago as 1997, but they couldn't hire him at that time due to legal restrictions.) That sure doesn't sound like someone who, even if we're only considering the 1997-through-2001 timeframe (note: 2001 was when Mono began), qualified as being a "Free Software zealot".

(Side note: if it weren't for Nicholas Petreley's weekly editorials, along with his XOOPS-powered (and at other times WordPress-powered) news/forum website — VarLinux.org, which, sadly, no longer exists — I might not have ever found my way to LWN.net in the first place.)

Also, keep in mind the fact that GTK+ and GNOME's core API libraries were LGPL-ed from the very beginning. By contrast, the zero-cost/gratis variant of Qt went through a series of license-changes throughout the years: at first it was under the "Free Qt license" (non-FOSS), then the "QPL" (FOSS but GPL-incompatible), then the plain GPL, until at long last, in 2009 (version 4.5) changing to the LGPL. For that reason, prior to 2009, developers of proprietary-commercial Qt needed to pay Trolltech (or their successors-in-interest) fees for commercial Qt licenses. What's more: the native Windows variant of Qt wasn't for available for zero-cost at all until 2005 (version 4.0), and (similarly) the native Mac OS X variant of Qt wasn't available for zero-cost at all until 2003 (version 3.2). I suspect that the higher-ups at Red Hat took note of all those things, and decided to favor GTK+ and GNOME (over Qt and KDE) and even fund the development of GTK+/GNOME, so that 3rd-party proprietary app developers wouldn't be required to pay licensing fees to Trolltech.

So, no, I don't believe it's correct to characterize GNOME devs as being anti-corporate "Free Software zealots" in contrast to KDE devs who (supposedly) are a pro-corporate "open source group". That's not the way things were back in 1997/1998, and it's still not the way things are.

> And no, IT industry is not reverting to how it was run in the mi-'90s.

I said "a few years before" the mid-'90s, i.e. the era when Novell NetWare and (later) Windows NT ruled the roost in corporate America's datacenters (and in U.S. local/state-level governments's datacenters, too). To pick a specific point in time for this, I'll say 1990, i.e. the year when Windows 3.0 was released. Or, for a larger timespan, let's say approximately 1986 (when NetWare version 2 was released) up until 1995 (when Red Hat Linux version 1 was released).

> Government control would be much more strict […]

If the government in question were to put Codeberg — and/or programming work by individual developers being showcased there — equally strictly as it's going to treat the current "Big Five" tech companies, then that kind of government control would in practice amount to regulatory capture by the "Big Five"!

However, judging by LWN's recent article about the Cyber Resilience Act and especially the comments posted there by people who (judging purely by what they wrote in those comments) live in Europe/UK and consequently understand how current Euro/British vendor-liability law works, I'm not worried that the CRA is going to do any serious harm to hobbyist-oriented forge sites (like Codeberg) or to hobbyist-developed Git repos hosted on them. That's because the intended primary target of the CRA appears to be consumer-electronics manufacturers/vendors, particularly smartphone makers, and also IoT / home-automation gadget makers.

> […] and chances of anarchy developments taking over would be slim.

Well, since you mentioned "anarchy", I'll pose a question: out of either the U.S. (which is all of the current "Big Five" are headquartered) or Germany, which one of those two countries do you believe is the one that's closer to anarchy? With that question in mind, I'll re-post here a YouTube comment (originally posted on this video) that was written by someone who lives in Germany:

On the "German Model": In Germany, we in fact have 3 "levels" of Board participation: The one mentioned above, for most companies between 500 and 2000 employees, one for Heavy industries and some other cases with parity between employer and employee representatives, and one for Companies over 2000 employees with parity of employer and employee representation, with the President of the Board having double votes in case of a stalemate.

The companies that are exempt from employees on the board are those with under 500 Employees.

The real deal about the Employee participation in Germany is the workers council, which has a lot more power (They have co-decision or veto rights on things like including, but not limited to: work time, measues controlling workers, worker protection, (Paid) time off rates, firing of employees...)

As far as I'm concerned, this famous 1975 movie's depiction of an "anarcho-syndicalist commune" is a lot closer to the aforementioned "German system" of corporate governance than it is to the U.S. system of corporate governance (which is the way that all of the "Big Five" tech corporations are governed); that's because, in the U.S. system, major shareholders are the only people who choose people to serve as directors on the board. That "German system" of corporate governance has been the law of the land in (West) Germany since 1976, so as of now it appears to be a tested-in-practice system that's successful.

For that reason, I'm guessing that the EU regulators will act to reduce, not increase, the amount of political power held by those "Big Five" U.S. corporations… and probably also act to improve the negotiating position that European tech-workers hold relative to their bosses (e.g. by ensuring that those tech-workers are able to showcase their work to other potential employers).

(Side note: two of the Democratic Party's candidates running for U.S. President made Co-determination a.k.a. Workplace Democracy part of their campaigns in the 2020 primary election cycle. And if a political-activist organization such as Citizens Trade Campaign were to successfully get that kind of public policy enacted into law — via international trade treaties — throughout the entire USMCA trading bloc, and the entire EU, and all of the BRICS countries, then imagine what human society as a whole might end up being like from that point onwards. It'd be a damn sight better than what we've got right now, that's for sure! For example, if the Philippines had that kind of public policy in place, it might do away with the CONTENT-MODERATION SWEATSHOPS that Facebook et al. are using right now, thus preventing content moderation at scale from being even remotely feasible and forcing a return to pre-2005-style small-scale web forums like phpBB or its modern equivalents like public-inbox and Discourse, and likewise forcing Discord users to abandon it in favor of Matrix, and so on.)

> That's what happened to every other industry, after all.

Those kinds of grandiose sweeping statements about history tend to be massive oversimplifications of what really happened, and the people who make such statements often are motivated do so as a means of advancing their own present-day political agendas, or sometimes religious agendas, or other times financially-motivated agendas.

(Remember back in 2016 when you predicted that "Android for the desktop" or something similar would replace all current desktop Linux distros Real Soon Now™, or maybe only replace the ones made by nonprofit orgs like Debian, in the same way that Tim O'Reilly predicted Mac OS X would replace desktop Linux back in the early 2000s? That still hasn't happened… though, now, it's looking like the Steam Deck is making some inroads in that direction…)

Yes, things happened the way you described them in the three examples other industries that you gave: the car industry (which had a bunch of regulations put on it due to collision-unsafety in the '50s/'60s and Ralph Nader's exposé, and more recently had more regulations put on it due to ecological/air-quality concerns… though even in that industry the regulations were enacted surprisingly recently in Europe relative to the U.S., because Europe's transit system is less car-dependent than the U.S. one is), the food industry (again due to risks to human health), and bridge builders (ditto). One more industry regulated about as heavily as those three is terrestrial & satellite radio/TV broadcasting (due to inherent limitations of the EM spectrum & the laws of physics themselves — despite that, though, Wi-Fi hasn't been regulated out of existence by the FCC or anyone else).

But every other industry… really? What about the paper industry, or the textile industry, or the clothing industry, or the furniture industry, or the home-audio-equipment industry, or the professional-grade A/V equipment industry, etc etc…

There are certain smaller industries (which, generally speaking, are currently not regulated as much as the car industry is) — in particular, hobbyist-oriented SBC makers such as Raspberry Pi and their competitors… note, by now they have lots of competitors (if in doubt then just take a look as Christopher Barnatt's "Explaining Computers" YouTube channel), because RPis tend to be out of stock most places for the last few years (because there's so much demand for RPis from businesses, who want to use the RPis in scenarios such as electronic signage, that there aren't any RPis left over for hobbyists to buy) and so a bunch of RPi competitors have sprung up to sell to the hobbyist customer base the RPi Foundation has partially abandoned — which apparently qualify (by your standards) as being mere "cottage industries" that are unimportant in the grand scheme of things. And yet, when taken as a whole, those industries collectively make up a not-insignificant portion of the world economy. So, I'm not convinced that European regulators will disregard the economic impact that the CRA will have on those industries (or consider it to be unimportant), like you seem to believe they will… nor am I convinced that they'll disregard the impact those regulations will have on tech workers' negotiating position (relative to their bosses / managers / HR departments) in the labor market.

(Remember also that there's a historical throughline from a state-funded "Computer Literacy Project" (that was its official name) in the UK to Eben Upton and the RPi Foundation. This goes to show that the Thatcher-era British state considered it important for general-purpose computers to be available for use — including programming-education use — to the public at large. And if today's British & European governmental bodies see things the same way — note, in 2013, the European Commission did see things that way — then they might take action to resist American BigCorp-led efforts like this recent one on the basis that it's important for societal reasons that a non-negligible portion of the general public must be able to use and program general-purpose computers.)

Here's something else from recent history that goes to show just how unpredictable lobbyists & legislators can be — look at what happened in the U.S. as compared to Japan in the '80s/'90s with regard to the packaged-media rental industry:

Home video (VHS/LD/DVD) rentals: legal in both the U.S. and Japan
Music album (LP/CD/cassette) rentals: illegal in the U.S., legal in Japan
PC software (on floppy diskettes or any other physical media) rentals: illegal in both the U.S. and Japan
Console video game (cartridges / CDs or other optical discs) rentals: legal in the U.S., illegal in Japan

So, apparently, lobbyists from the Japanese equivalents of the RIAA and the MPAA failed in their attempts to get rental shops outlawed… whereas in the U.S., the RIAA's lobbyists prevailed over the rental shops (e.g. Blockbuster Video) but the MPAA's lobbyists lost their struggle against the rental shops. Just how predictable was the outcome of that lobbying battle?

(And here are two more examples of how difficult it is to make accurate long-term predictions about the IT industry and human society more generally: in France back in the 1980s, X.25 and Minitel looked set to become what TCP/IP + the Web + SMTP email would go on to become in the mid-1990s; and didn't Andrew Tanenbaum once say that "microkernels have won", citing Windows NT as an example of a microkernel OS, but later had to take back that statement in part because NT turned out to not really be a microkernel OS after all?)

> I guess some governments would fail to apply a tight leash and these government would fail… but that wouldn't lead to free software nirvana but to the proliferation of failed states where development of the software (free or otherwise) just wouldn't happen.

Regulatory capture is the American way of doing things, to a greater extent than it is in Germany, and right now the U.S. is already dangerously close to being a failed state (to a far greater extent than Germany is)! Or at least that's how things in the present-day U.S. seem to be going as seen by most "Joe Average"-type Americans, who (unlike ultrawealthy people such as Marc Andreessen or Jack Welch) neither have nor ever will earn a living by working in upper-management and/or enterpreneurship and/or professional investment.

Next, here's a personal story:

I've watched in despair as lots of my own coworkers in the private sector (note, working conditions for public-sector employees are a lot better than what I'm about to describe here, due to labor unions such as SEIU) have spent only somewhere around 4 to 6 years working in any given engineering/technical job role (as opposed to a managerial role) before leaving that role in one of these 4 ways: being promoted upwards into management, or moving "sideways" within the org chart (i.e. moving from one internal "team" to another), or moving to a separate project within the same company, or leaving the company altogether. Why do they do that? Because climbing the corporate ladder is a major life goal for them, isn't that why?!

And for those employees who care more about long-term maintainability of a codebase than (so-called) "career advancement", guess what happens: work turns into a never-ending barrage of "oops, it's 5:30 PM, but this problem we discovered at the last minute, and you must fix it TONIGHT, and stay up all night long working on it if necessary" demands from bosses!

Consequently, the developers with the most working knowledge of the codebase suffer from severe burnout, and long-term maintainability of codebases falls by the wayside. In other words: when the turnover rate of employees is that high, the company's institutional knowledge deteriorates, causing code rot to set in, until finally the entire codebase is so messy/incomprehensible that it must be thrown away in its entirety. Lack of long-term maintainability is what led to the downfall of dBASE, and also to the original Netscape Navigator codebase (that is, Navigator's codebase as it was before the changeover "from the old layout engine to the new layout engine (Gecko/Raptor) [which] constituted an almost-total rewrite of the browser").

That is how software development is actually done in the milieu of big business today. And if new government regulations were to strangle all hobbyist-oriented forge sites (like Codeberg and invent.kde.org) with red tape, then that would likely prevent any new software project that values long-term maintainability like this one:

No manager of a [Linux] kernel developper can say "I know it's half baked but merge it now beacuse marketing wants it" and Linux largely maintains the "it'll ship when it's ready" and "longterm maintability is important" mindsets that are missing in most commercial projects.

…from ever being created in the future. You've said that you want government regulations to "bring control and responsibility into the IT industry", but kicking all hobbyist-developed software off of forge sites, or fining all of the forge sites (or the individual hobbyists hosting their work there) into bankruptcy, will just have the effect of putting big business in charge of most or all software development, where they do everything not in a controlled-and-responsible way, and instead do everything this way: "damn the torpedoes, full speed ahead; we don't care if it's buggy, just get this thing done RIGHT NOW!"

> If you seriously think that I have this level of influence then you need to have your head examined.

Maybe books such as the aforementioned "Chokepoint Capitalism" (and its authors), along with activist organizations such as the FSFE (which, I'd say, is much more effective in getting their message out to the general public than the American FSF has been for a long time by now), might influence the actions of regulators/legislators in European countries that reject the U.S. style of so-called "laissez-faire capitalism" (especially Germany).

And, aside from that, it sure looks like you have a tendency towards pro-"mass market consumer electronics" / anti-"old-fashioned desktop Linux" partisanship, ever since that time in 2011 when you said (to someone who, apparently, was one of the HP webOS developers) "The standard phrase applies: you [referring to corbet] don't exist", and also when you said that "most users value "pretty pixels" way, way, WAY above network transparency".

(That's similar to the "user-friendliness to Joe Average User must be priority #1" kind of rhetoric that Apple fans were known for in the '80s and '90s, and despite that, the Macintosh got soundly trounced in the marketplace by the more bricoleur-friendly option — that being Wintel PCs — that gave rise to Linux during that same era… which in turn recently led to the Steam Deck, which for now at least appears to be a commercial success story.)

Having read those and also this, it gives an impression of motivated reasoning like this: "you can't make a business out of [supporting niche use-cases*] since there are no money in it**". When viewed in that light, a lot of your comments could plausibly be read as FUD and/or Stop Energy directed towards hobbyist-developed FOSS projects.

(*: in that instance, the use-case in question was reading email on a smartphone from a self-hosted IMAP server with a self-signed TLS certificate.)

(**: although, to be fair, you did acknowledge that "certain niche markets appeared where GPLv3 is not considered large enough liability to try such software" that time.)

> And you know it, or else you wouldn't have been so angry.

No, I don't know that the CRA will be bad for forge sites, and neither do you. And neither do several other LWNers who've posted comments about the CRA… but at least they seem to have first-hand knowledge of how European laws (about liability for selling defective products) work, so I suspect that they are correct about how the CRA will play out in practice, and that the Apache Software Foundation is incorrect.

(And as for the angry tone: I meant that to be directed toward the "Big Five" companies and big businesses in general, not towards EU legislators.)

> If that's true then it just means that there would be a different law later, which would bring control and responsibility into the IT industry.

"[Bringing] control and responsibility into the IT industry" shouldn't involve "making it possible for forge sites to be sued into oblivion", as far as I'm concerned… whereas it should involve cutting the Big Five down to size.

> Wow. So much cope.

If you're implying that I'm worried about the CRA in Europe, then you're mistaken (as I explained above).

OTOH, it does look like someone at Google is worried that FOSS might pose a threat to their business model, and if that worry spreads to the board-of-directors, then they might start lobbying the notoriously big-business-friendly U.S. federal government to allow them to (as jwz said) "rule the world forever"… but on the other other hand, some U.S. legislators want a 2020s-era version of this to be imposed on the "Big Five" tech corpos, and no one knows which side will get to have things their way…

> No, there are no such danger.

That contradicts your earlier claim that "there would be a different law later". It also contradicts this ("if you are creating a GitHub page and write README there then now you are marketing something [and therefore you will be held legally liable for bugs under the Cyber Resilience Act]") and this ("That, by necessity implies that large open source “forges”, if, maybe, not individual contributors, would have to deal with liabilities.").

> Or maybe there is, but that part is pretty much minor and insignificant. We have just arrived at the time where products made by hobbyists would stop being used by non-hobbyists.

That's (conditionally) OK with me, as long as it remains possible for these 2 kinds of events to continue happening in the future:

A large (though maybe not exactly huge) company like Valve can put on the market a consumer-electronics product whose pre-installed software includes a Linux distro derived from one that's written by hobbyists with a desktop environment that's also written by hobbyists; and,
someone like this developer can develop a FOSS-licensed microblog web-app that (6 years out from its initial release) gains enough users to make it famous enough for The Guardian to publish news stories about it & for its original developer to found a gGmbH non-profit organization dedicated to continuing its development… and then someone like this hobbyist developer can come along later and develop a forum/link-aggregator web app that's interoperable with the aforementioned microblogging app and which eventually has a bunch of non-profit orgs like this old one which began as a dialup BBS all the way back in 1987 running instances of it.

In conclusion, here's one more quotation from ESR, this time taken from the front page of his personal website:

I will not tolerate having general-purpose computing hardware, which should be an instrument of liberation and creativity, reduced to a locked-down delivery pipe for "content". By trying to cripple my tools, the big-media machine has made me its enemy. DRM delenda est!

You keep saying that, since 1998 up through the present, there exist "separate well-defined “open source camps” and “free software camps”", and (at least implicitly) that the "open source camp" is pro-corporate whereas the "free software camp" is anti-corporate. But that ESR quotation goes to show that the original "Open Source camp" was never 100% pro-corporate, and that their general ethos, sensibilities, and worldview are much different from the (in jwz's terminology) "captains of industry" who are in charge of Google, Facebook, etc.

It's a shame, though, that ESR is a capital-L Libertarian, because that minor U.S. political party's economic policy preference (i.e. "laissez-faire" capitalism) is basically the main reason why both "the big-media machine" and the current Big Five U.S. tech companies were able to gain so much political power in the first place. Anyone who wants to have a hobbyist-friendly national economy ought to look to the parts of the world from which Linux and KDE (which might qualify as being the "top two" most famous hobbyist-developed FOSS projects) as the model to follow, and push for this kind of corporate governance to be mandated by law worldwide.

KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models

Posted Jan 26, 2024 23:09 UTC (Fri) by kleptog (subscriber, #1183) [Link] (1 responses)

Just a small addition to your comprehensive response.

The real deal about the Employee participation in Germany is the workers council, which has a lot more power (They have co-decision or veto rights on things like including, but not limited to: work time, measues controlling workers, worker protection, (Paid) time off rates, firing of employees...)

They're actually called Works Councils in english and exist in many European countries, though they are the strongest in Germany. There's even a Works Council Directive. CxOs in English speaking countries have a hard time distinguishing them from unions but they have distinct roles. The Works Council represents the workers in the business and the goal is to improve the running of the business whereas unions are more focussed on the workers. From personal experience being on a Works Council having to decide whether to approve the firing of a significant number of colleagues to save the business is no fun at all. And that's just in the Netherlands where they're not as strong.

99% of the benefit of a Works Council is the mere fact that management actually has to motivate their decisions and it's surprising how many CxO-level decisions have no more motivation and analysis behind them than fits on a back of a postage stamp. Getting more than a slide-deck the first time round is rare. Once management can actually articulate what they want, the proposal is almost always a good idea.

As an aside, people seem to confuse the terms liability and responsibility with respect to the CRA. When it comes to fixing bugs in Apache, of course the Apache Core Team is responsible. No else has commit rights, so no-one else can fix them in the Apache source. That's different from the responsibility of a manufacturer to deploy any fixes. And completely different from liability which arises from the breaking of specific promises. The CRA is not about that your product in 100%-bug free. That's not possible, just like 100% error free hardware products don't exist. What matters is the process behind it: preventing, finding, reporting, fixing (security) bugs and deploying those fixes. All of which have had well known "best practices" for years, we just don't do them.

work turns into a never-ending barrage of "oops, it's 5:30 PM, but this problem we discovered at the last minute, and you must fix it TONIGHT, and stay up all night long working on it if necessary" demands from bosses!

I'm so glad I've never worked in a place like that. I can't be held to deadlines that I did not agree to. If I gave a deadline and got it wrong, that's on me. But more often it's: that sound you're hearing? That's the sound of your deadline flying past. I honestly don't understand what motivates managers to give deadlines without asking the people who have to do the work if they're even feasible.

KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models

Posted Jan 27, 2024 8:59 UTC (Sat) by Wol (subscriber, #4433) [Link]

I sort of had one of those (it's very rare) last night.

"Something has messed up in our team, and tomorrow will break if we don't put it right".

Don't get me wrong, it's a great place to work, and there is a STRONG management recognition that our practices are broken. As far as I can tell, this particular incident was a bugfix that seemed to work, but then made matters worse. So we just reverted it.

But when a large amount of your work is "we just need tomorrow to happen!", then the odd thing like this does come along :-) I'm desperately trying to reduce technical debt, but when we have a huge database implemented in Excel VBA, there are limits ...

Chers,
Wol

KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models

Posted Jan 29, 2024 14:09 UTC (Mon) by geert (subscriber, #98403) [Link]

> (Also note: the earliest version of KDE's HTML rendering engine was part of kfm (KDE File Manager). I'm not sure what its exact release date was… maybe July 1998 (KDE 1.0) or March 1999 (KDE 1.1)?

Probably the former, as it was present in the first version of KDE I tried, which must have been just before or at the 1.0 release.
Typing a full URL in the file manager's path dialog box and seeing the rendered web page was very cool, and impressed quite a few of my friends!

KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts

Posted Jan 24, 2024 14:28 UTC (Wed) by kleptog (subscriber, #1183) [Link]

> Whichever corporation you might have believed was your ally (against Microsoft, or against AOL/CompuServe/Prodigy et al.) during any of the past 3 decades is probably your enemy right now.

Businesses do not have feelings. They have always acted in what they think are their best interests. I think all open-source developers develop because they think it's in their best interests in some way. Open-source is where it is because sufficiently many people and businesses think it's better than the alternatives.

If FAANG are contributing to open-source, it's because they believe its the best thing for their bottom line.

> Consequently, right now there's a danger that some people with deep pockets might try to lobby national governments into strangling those hobbyist-led FOSS projects with red tape!

Hobbyist developers are basically on the same level as hobby model train builders, or you paying the neighbours kid to clear your gutters: in theory it would be great if they followed regulations, but there's no public policy reason to spend any effort on it. And no legal avenue to enforce it either.

Jujutsu: a new, Git-compatible version control system

Posted Jan 25, 2024 22:11 UTC (Thu) by philh (subscriber, #14797) [Link] (2 responses)

> They automatically assume jujutsu would fail just because of CLA and there would be some king of successor, for crying out loud!

> Sure, jujutsu may still easily fail, but that wouldn't happen because of CLA, that's for sure.

All other things being equal, having paid attention to the success or otherwise of projects for about 30 years, I'd say that there is a high enough correlation between failure and the presence of a corporate CLA for me to assume that any new project encumbered by such a thing is not even worth looking at, because it'll very likely be superseded, and any time I spend on getting familiar with it will have been wasted.

That's without taking into account the real problem with corporate-backed CLAs, which is that I don't have a pet lawyer who will explain for free to me what the implications of signing it might be, whereas the other party did use expensive lawyers to ensure that their interests are protected. That being the case, I'm not going to sign one of those.

That means that I'm looking at a thing that is labeled Open Source, Free Software, or whatever name doesn't make you foam at the mouth, but really isn't in any practical sense, because only people that are careless of their own interests are going to contribute to it, so it might as well be labeled "Look but don't touch!"

I'm not demanding that they change that.

I am however disappointed that nobody at Google seems to have noticed that CLAs are the kiss of death.

Jujutsu: a new, Git-compatible version control system

Posted Jan 27, 2024 20:32 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

> All other things being equal, having paid attention to the success or otherwise of projects for about 30 years

Wow. Where may I find your study? How have you picked the projects, where is the list, what was the outcomes you recorded?

> I'd say that there is a high enough correlation between failure and the presence of a corporate CLA for me to assume that any new project encumbered by such a thing is not even worth looking at

So you are not using C or C++, docker or kubernetes, don't use smartphones and so on?

I suspect that you apply your avoidance of CLAs very selectively to reach that conclusion.

> I am however disappointed that nobody at Google seems to have noticed that CLAs are the kiss of death.

Because from Google side it's most definitely not “kiss of death” at all. Many projects that require CLAs are leaders in the appropriate areas and even if you count some projects which currently don't require CLAs (like gcc or LibreOffice) they asked for CLAs for years.

All Google-initiated projects require CLAs (be it Angular, Go or TensorFlow, whatever) and the same is true for the projects initiated in most other corporations, too. And they lose that requirement (if that ever happens) only when corporations involved ditch them or fork is happening.

It would be interesting to see truly unbiased study which picks projects without looking on CLA and then looks on their fate over the years, but since both you and Google are looking for vindication of their stance (Google would definitely consider CLAs of Android an important part of its success while you would probably show us how Upstart was replaced with SystemD)… and given the fact that there are so very few which failed or succeeded because of CLA… extending your conclusions on the whole set of software available is just silly.

Especially because “correlation does not imply causation”: you may say that Angular is no longer the most popular framework because CLA, but then why is it replaced with CLA-encumbered React, instead?

Jujutsu: a new, Git-compatible version control system

Posted Jan 28, 2024 15:02 UTC (Sun) by gioele (subscriber, #61675) [Link]

> > All other things being equal, having paid attention to the success or otherwise of projects for about 30 years
>
> Wow. Where may I find your study? How have you picked the projects, where is the list, what was the outcomes you recorded?

There are some numbers in:

Jonas Gamalielsson and Björn Lundell. 2017. On licensing and other conditions for contributing to widely used open source projects: an exploratory analysis. In Proceedings of the 13th International Symposium on Open Collaboration (OpenSym '17). ACM.

https://dl.acm.org/doi/pdf/10.1145/3125433.3125456

Table 8 seems to hint at the fact that projects with CLAs and similar contributor agreements tend to be more successful (according to BlackDuck's metric =~ being used) than projects without CLA. Correlation is not causation. This success could be due to having an entity (business, foundation) paying the programmers in charge of the project, rather than due to the CLA itself.

That study did not investigate the effect of CLAs on the number and variety of contributors to a project. So perhaps projects with CLAs are widely used, but not frequently contributed to (and the minute the sponsor goes away the project is dead, regardless of its widespread usage). But asserting that would require another study.

Jujutsu: a new, Git-compatible version control system

Posted Jul 7, 2024 22:17 UTC (Sun) by marcH (subscriber, #57642) [Link]

> It's one thing to say that you wouldn't contribute to Jujutsu till CLA would be removed. It's weird that few clicks on the web site are that awful that you would refuse to contribute because of them, but whatever. There are legal consequences and you may want to avoid them

> It's entirely different thing to demand that Google should stop using CLA or else you wouldn't even use that product.

No, for many people it is not "an entirely different thing". For many people, using free software and sending patches upstream is the same thing. Dropping that boundary is basically the main point of free software.

Even if they don't happen to actually send patches upstream (because the software is good enough for them), they want to make sure anyone else can easily for obvious "good maintenance" reasons.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 13:53 UTC (Tue) by danielthompson (subscriber, #97243) [Link]

There are many factors that encourage the adoption or non-adoption of a project. One factor is an assessment of the long term health of the project.

A project where the development is primarily undertaken by a single corporate sponsor has, at best, significant risk regarding it's long term health since the sponsor may change their priorities. When that corporate sponsor *also* requires a CLA that confers them with rights that other contributors do not have then then the risk is higher because, by inhibiting contributions, they inhibit the formation of community around the project. They do not kill the community entirely but they do inhibit them. Isn't it therefore entirely reasonable to regard a CLA as a negative indicator of project health?

Thus in the case of a project with a vibrant competitor, such as git, then it's hardly zealotry to factor the CLA into a decision to not "even touch something".

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 12:10 UTC (Sun) by fw (subscriber, #26023) [Link] (10 responses)

The use of the Contributor License Agreement is annoying, but to most people it does not matter because a contribution under the Apache License 2.0 seems to give Google very similar rights. This is not the typical asymmetric licensing situation, where you get the project code under a copyleft (or even non-free) license, but you have to grant very permissive terms to the project for your contributions.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 16:27 UTC (Sun) by amacater (subscriber, #790) [Link] (9 responses)

If you have to use a CLA, quite often people would prefer to sign a Developer's Certificate of Origin which just says that your wrote / have full permissions to distribute the code you contribute.

_Requiring_ a CLA can be off-putting.

Jujutsu: a new, Git-compatible version control system

Posted Jan 21, 2024 22:26 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (6 responses)

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.

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).

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 11:49 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

I concur that CLAs are off-putting. On the topic of Git clients, Meta has their own called Sapling (https://lwn.net/Articles/915104/). It requires CLA. Did we hear about Sapling often? Not really.

Jujutsu may fall into obscurity because of CLA. Just like Sapling.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 14:52 UTC (Mon) by khim (subscriber, #9252) [Link]

> Jujutsu may fall into obscurity because of CLA. Just like Sapling.

You are deluded if you think CLA caused Sapling or, e.g., Google's repo to fail.

One simple counterexample: React from the same company as Sapling was adopted by people, and it requires CLA, too.

Sapling just wasn't interesting to anyone who doesn't work with terabyte-sized repos (and most people who have such repos have specialized tools to use with them).

Same with Jujutsu: if it would fail it would fail not because of CLA but because people would see nothing interesting to adopt it for.