That site exists in my country but under a different name (the UI is exactly the same so I imagine it's the same company). It's OK, but their search engine is mediocre. You look for Smartphone deals and they show you bananas... this is the very thing that shouldn't happen on a site like that. It means that whatever algorithm they use isn't very sophisticated.
Git had a very small initial implementation, while jj is under development for years and is large. If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now? Is it the Google CLA, or are too few people using jj, or is jj too complex, or some mixture of all of the above?
> 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.
> why have new implementations not sprung up by now?
Nobody wants to yet?
FWIW, while there aren't multiple reimplementations of the core yet, there ARE multiple GUI and wrapper projects that fulfill various needs, if you're just looking for outside contribution as a health measure.
Jujutsu also started out very small, just like Git did. The core concepts aren't too complex. But this is 2026, not 2005 or 2019. Most of the modern Git implementations are extremely large, highly optimized and featureful codebases that are difficult to replicate. Many of Git's performance and structural improvements over the last few years have nontrivial implementations and designs. Jujutsu is also a large, featureful codebase. You can't build a modern Git implementation with all of the highly optimized goodies (multipack indicies, partial clones, etc) and a good UX without a lot of code and work. Or any version control system, frankly. It's just how it is.
- Gitoxide is 80,000+ lines of code.
- Git itself is over 170,000 lines of code.
- Even "Game of Trees" or "got" by the OpenBSD developers, which is a wholly separate project that has its own porcelain, is +120,000 LOC.
- Jujutsu itself is about 100,000 LOC.
- JGit for Java is around 200,000 LOC.
These are all roughly approximate and include things like testing code (but I think that's fair because tests are part of the project). All of these projects started small years ago, and are now large.
> If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now?
"Make multiple implementations" is not, in and of itself, particularly valuable without some underlying justification to do so. It also is not how (AFAIK) any other version control system has ever worked; Git's "identity" as an on disk format is a particular design choice (with pros and cons), so yes you can get multiple tools with varying levels of features that agree on the basic disk format and poke at it. But most projects just don't work this way, much less other VCSs; there also aren't really many "Linux re-implementations" beyond toys because it is easier to just collectively contribute with each other, because Linux is not a "standard" written in stone, but a living and breathing thing.
> There is a mandatory CLA you must agree to. Importantly, it does not transfer copyright ownership to Google or anyone else; it simply gives us the right to safely redistribute and use your changes.
[Emphasis from the source]
Does this make it possible for the jj organization to make the implementation closed-source and proprietary, and abandon the open source version, taking all the contributed changes from volunteers and other organizations with them?
It gives Google the ability to use the source code under whatever terms they want. It does not change the Apache licensed code at all, which can still always be used under that license.
The CLA is Google's in this case. It gives them the right to distribute your copyrighted work. It also has some terms that say Google could sublicense and redistribute the jj codebase under another license -- which means they could for example release a copy of the jj code that was under MIT, or GPL2, MIT-Apache, etc. Or proprietary, even.
But the thing is, Jujutsu is under the Apache 2.0 license right now. You are within your rights to use Apache 2.0 in proprietary products. Literally anyone, at this exact moment, could clone the repo and integrate it into a proprietary product, or share proprietary binaries built on the code (rename it Gugutsu VCS) without giving up the source, as long as they obey the ASL 2.0 terms. The CLA really has nothing to do with this fact.
If you are personally worried about your personal copyrighted patches going into proprietary products -- or if that's your only worry -- you basically need to avoid contributing to all projects that are not using a copyleft license; just avoiding CLAs or whatever isn't enough. This has been true for a while.
If you are worried about a "rug pull" the next question is whether the developers can actually do that. That is a matter of social configuration of the project, not licenses. The thing with "rug pull OSS projects" is mostly about ownership and labor. Licenses and CLAs really don't matter much if 99.8% of development comes from one group of unified engineers. Such a setup is risky even with a 0% chance of any license changes. Their company might fail or they might all get fired. You didn't get rug pulled, but the project might die, which is basically just as bad.
But for Jujutsu, there is no majority of developers from any one company, and significant amount of code comes from the community, so the answer is more or less "no, we can't do that even if we wanted." The best we could do is start a whole fork and lose a significant chunk of the community and contributors. There isn't any one group of people with enough of an iron grip to do that without sustaining massive losses.
I think people sort of get "Can this become proprietary", with "Is some <bad outcome> possible" -- in this case Jujutsu's code can absolutely "become" proprietary already in a real way. You can just go do that now. But a lot of "rug pull" things are prevented, I think, simply due to the fact we have a robust and strong community outside the (paid) developers
Ultimately, for a non-copyleft project, non-assigning CLAs like the one Jujutsu has are basically just annoying, legal ass covering mechanisms for Google's sake. I also do not like the CLA, it's just basically an irrelevant piece of paper as far as my principles on the matter are concerned. The Linux kernel DCO is basically just a CLA with fewer words, motivated by similar concerns to not get backstabbed due to the business logic of suing people.
If we got rid of the CLA for Jujutsu, I personally think it would probably still be nice to ask people to respect the DCO.
I don't suspect there is a uniform spectrum between those two. I think this is something that's going to be clinal, which we see in a lot of other comparable social contexts. The number of people actually willing to cross a moral threshold into outright crime is relatively small, but those are precisely the people who cause the most damage when they get away with their behavior.
Bur I don't even really think that's really relevant anyway, because whatever the density of "malicious" motivations is, the point here is that the fact that it only is an effort/motivation threshold that allows this technique to "block" malicious uses, and the motivation to overcome that threshold correlates directly with the stakes involved in the malicious use.
In other words, the more malicious the abuse is, the less effective this solution will be: the boundary of its usefulness will be wherever the line between pranksters and actual criminals happens to lie.
Your idea of a criminal seems to be hypercompetent and think of everything. These do exist, but most criminals are not very smart. Smart, dedicated, technical people can typically make more money legally.
Your argument applies to any imperfect security technology -- aka practically all of them.
> Your idea of a criminal seems to be hypercompetent and think of everything.
No, my idea of a criminal is someone who is motivated to commit crime, and I feel that we've already established in this thread that the approaches we're discussing are motivation gates far more than competence gates.
> Smart, dedicated, technical people can typically make more money legally.
Then who's been running all the botnets, writing cryptolocker malware, and running phishing scams for the past couple of decades?
We've always had script kiddies, and now we have people using AI itself to do malicious things. Technical skill has never been an obstacle for sufficiently motivated scammers.
> Your argument applies to any imperfect security technology -- aka practically all of them.
Ultimately, everything has weaknesses, and with enough effort, most measures can be circumvented. But how much effort is enough varies wildly between solutions.
There's a huge gulf between a "no trespassing" sign, on the one hand, and a concrete wall topped with barbed wire, on the other. The "no trespassing" sign only keeps out people willing to obey it; the concrete wall keeps out anyone who isn't willing and able to accept the time, effort, and risk necessary to climb over it or knock it down.
And the point is that using digital signatures to distinguish AI-generated media from hand-made media is much closer to the "no trespassing" side of things than it is to the wall. Maybe it's analogous to a gate with a latch you can open from the other side if you reach over in just the right spot.
I'm afraid it doesn't. To the contrary, treating effective security in terms of how it influences the attacker's cost-benefit tradeoffs, and evaluating proposed measures on whether the effort threshold they create is enough, is quite literally the opposite of black-and-white thinking.
And in this case we can clearly see that a solution that (a) does not substantially increase their costs -- and in fact, as I've pointed out above, only really filters by motivation, not by time, money or effort, and (b) doesn't target their potential benefits at all, is one that isn't likely to be effective.
Because nowadays Linux ABI is more relevant than pure POSIX compliance.
BSDs and all surviving mainframes and micros also have either Linux VM support or syscall compatibility.
Microsoft saw those geeks that were buying Apple as shinny Linux, and then complaining about lack of compatibility, or that they only cared about POSIX toys but not really Linux proper, and saw a business case in shipping Linux in the box to counter that.
Which had they kept and improved POSIX support since Windows NT 3.51, that would never been a matter to discuss about.
Well, the brainchild of YC Founder Robert Morris, the Morris Worm, exploited a zero-day in fingerd, so yes, after 1988, fingerd was extremely important for network security.
reply