follower

For historical context, the Advogato site in question: https://web.archive.org/web/20170715120119/http://advogato.o...

Background on the "trust metric" implemented on the site: https://web.archive.org/web/20160304000542/https://advogato....

Apparently my account on the site is/was now more than a quarter of a century old... Gonna try to avoid thinking on that too deeply. :D

There's been a non-zero number of occasions since that time where I've observed situations that mirror the trust-based challenges Advogato sought to solve.

It is perhaps telling that as prescient as Raph's work on trust metrics was he later moved on to the notoriously challenging realm of font rendering--presumably because it seemed more tractable. :D

The combo of the visuals and Halcyon is exquisite.

I encountered the Sony MMCD when I fell down a rabbit hole *checks literal notes* around five years ago while researching Microsoft Encarta MindMaze[0] and its related file formats.

It turns out the data associated with MindMaze (& other encyclopedia data) changed storage format over subsequent releases of Encarta and these changes provide some interesting historical insights--including that if MS had had its way we'd all be writing web pages in RTF rather than HTML[1]. :D

You may ask, "What connection does this have to the Sony MMCD?".

Well, one of the storage formats used with early Encarta data is `.mvb` which is a format used by Microsoft Multimedia Viewer[2] (also known by multiple other names--none of which are any easier to web search :D ).

And, it turns out, "Multimedia Viewer could compile titles for Tandy Video Information System and other Modular Windows systems, as well as Sony Multimedia CD-ROM Player, a portable MS-DOS-based CD-ROM XA reader released in 1992."[2][3]

According to my research the tool "...includes software tools that simulate the look and feel of the Sony player titles on a PC" which is interesting in the context of the emulator for the Discman mentioned in the original post.

Anyway, that's the very short version of the rabbit hole--maybe in another five years I'll get around to writing up the rest...

Oh, just found my original tweet thread (including screenshots) about this rabbit hole as it happened[4]: https://xcancel.com/RancidBacon/status/1401009436949237763

----

[0] https://en.wikipedia.org/wiki/Encarta_MindMaze (New as of October 2025.)

[1] https://en.wikipedia.org/wiki/Blackbird_(online_platform)

[2] https://en.wikipedia.org/wiki/Microsoft_Multimedia_Viewer (First added some time after my ~2021 research.)

[3] The Tandy VIS being a "Modular Windows" system is also of historical interest and FWIW has some support in MAME.

[4] Including screenshots of "Modular Windows Shell" and various "Multimedia Viewer" versions running under WINE.

The Sony MMCD[0] is a contemporary of the Sony Data Discman that people might also find of interest:

* https://en.wikipedia.org/wiki/Sony_Multimedia_CD-ROM_Player

There are a couple of YouTube videos showing the device (filmed both around launch and more recently).

(I'll try to add some more context in a follow-up comment.)

----

[0] a.k.a. "Sony Bookman" a.k.a. "Sony Multimedia CD-ROM Player" a.k.a. "Sony PIX100" a.k.a. "Sony Corporation Programmable CD ROM Player".

"The Office Formerly Known as 365"

[...] brave or foolhardy, [...]

Heed the above warning as down this rpath madness surely lies!

Exhibit A: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Exhibit B: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Exhibit C: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...

To save everyone a click here are the first two bullet points from Exhibit A:

* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!

* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]

Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)

Just mentioned this in another reply but Jujutsu may be of interest as a maintained alternative to gitless: https://github.com/jj-vcs/jj/blob/main/README.md#introductio...

bzr

While not perfect, I have some hope that Jujutsu may be a path forward for improved ergonomics in version control: https://github.com/jj-vcs/jj/blob/main/README.md#introductio...

I vaguely wondered if FreeHand would make an appearance in this thread. :)

Two features that come to mind as IIRC being unique (as compared to Illustrator) were multi-page documents and multiple page size multi-page documents. Ideal for the complete standard set of company branded print documents: business card, "With Compliments" slip, and letterhead. :D

Adobe's acquisition of Macromedia and subsequent killing of (the IMO superior) FreeHand contributed directly to my subsequent decision to avoid closed source application software--especially for creative tools--even if alternatives were "technically inferior".

(And, indeed, "creative tool killed/hampered for business reasons" is a story which has been repeated elsewhere multiple times in the quarter century[0] since.)

While Inkscape is still missing features compared to FreeHand it is however also still here many years later and is what I've used ever since when I need 2D vector design software. (Although I've also been keeping an eye on Graphite: https://graphite.rs)

----

[0] Oh, weird, apparently it's actually less than 25 years: https://en.wikipedia.org/wiki/Adobe_FreeHand#Adobe_FreeHand Seems I've been holding the grudge for less time than I thought. :D

TIL. Thank you!

Now I just have to remember this next time I need to select text within a link. :)

I've been thinking about bluetooth and a standard protocol and generic app.

A long time ago I developed a project called "Handbag[0] for Android"[1] based around a similar concept--it targeted the short-lived "Android Open Accessory Protocol" initially over USB & later also over network/WiFi.

(My project notes from the time mentioned a long-term goal of also supporting Bluetooth but that never eventuated...)

Handbag made use of a "generic" Android app for UI display/interaction and an Arduino library that communicated with the app over a binary protocol.

The app would display various UI widgets such as labels/progress bars to display feedback from the accessory and text inputs/buttons to accept input forwarded to the accessory.

While the project did not take the world by storm, I was reminded when digging up these links that at least one person called the concept genius[2]. :)

----

[0] Because it let you "accessorize your Android phone or tablet". :D

[1] https://web.archive.org/web/20130205135845/http://handbagdev...

[2] https://www.doctormonk.com/2011/11/handbag-android-and-ardui...

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/

I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:

"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654

Of course, in your situation I guess such a tool would only help if other people use it. :D

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/

I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments (yours being one I've had open in a tab for a week to remind me! :) ) discussing issues related to line-based "blame" annotation granularity:

"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/

I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:

"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654

In my case the particular code I was digging into was within the function `squash_the_stupid_serial_number(...)` as seen here: https://cregit.linuxsources.org/code/6.13/arch/x86/kernel/cp...

Unfortunately the direct line-number link above doesn't seem to provide the same view as manually choosing "squash_the_stupid_serial_number(...)" rather than "Overall" in the selection/option menu accessible via the page link: https://cregit.linuxsources.org/code/6.13/arch/x86/kernel/cp...

(Apparently the only code directly from Linus' original commit for that function is `, lo, hi`. :) And, unfortunately, being from the pre-git era, it is lacking any sort of informative commit message...)

Also, as the documentation mentions the token-tracing isn't perfect, e.g. the `squash_the_stupid_serial_number` name did actually exist before the cregited commit: https://github.com/torvalds/linux/commit/0a488a53d7ca46ac638...

(Perhaps this could be related to there being multiple function implementations selected via #ifdef?)

The linked site contains a token-based (rather than line-based) git "blame" annotation view for Linux kernel releases, i.e. it allows you to discover which commit added a particular token--where "a token is what the C syntax considers a token".

An advantage of a per-token commit attribution view is you don't need to transit through the history of an entire line.

Cregit is the tool used to produce the per-token view: https://github.com/cregit/cregit

I encountered Cregit recently while doing some "code history spelunking/archaeology" and thought it seemed pretty nifty.

Decided to share the link as there have been a couple of recent HN threads which included discussion about the poor granularity of line-based git "blame" functionality.

The most recent kernel version on the site is v6.13: https://cregit.linuxsources.org/code/6.13/

Unfortunately, the tool itself seems not to be under active development, the most recently modified branch is from 2 years ago & the main branch was last modified 6 years ago: https://github.com/cregit/cregit/tree/newinter

I'm unsure whether the most charitable reading of your comment is to assume you missed that these linked phrases exist on the original site but were not included in the text copied into the comment above, or something else:

* "bad actors" links to https://en.wikipedia.org/wiki/Kiwi_Farms

* "destroy lives" links to https://en.wikipedia.org/wiki/Kiwi_Farms#Suicides_of_harassm...

While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:

"Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."

Based on other remarks about the content of such subthreads it seems surprising to claim that follow-on comments are made by "honest nice people".

I'm as much of a fan of adverbs as the next person but using words like "categorically", "extremely" & "patently" doesn't seem to leave much room for nuance of interpretation when written by someone who I'd have assumed was a third party observer?

While I could understand someone describing JWZ's HN-tailored "banner" (I wouldn't suggest researching this if anyone is not already familiar) gauche and immature, it feels like somewhat of a stretch in relation to a plain text message who last sentence starts with "Please".

I would like to first acknowledge the feelings of what I read to be anger, frustration & pain you expressed in your comment. (If I've misinterpreted what you've written, I am open to reading further clarification if that's something you felt like investing effort into.)

While my life experience has been different to yours, from what you've written about how you've been treated by others in your community, as a consequence of who you are, it seems understandable to me that you might experience those feelings--and, even if they didn't seem understandable to me, it is more important to me that you feel heard and your feelings acknowledged as valid and not dismissed.

I hope I have been able to communicate that intent effectively.

----

At the risk of falling into the stereotype traps of "straight white male thinks every rhetorical invitation is a literal invitation for him to say what he thinks" & "straight-splaining" I did want to provide an answer to the question in the last sentence here:

"As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel."

(I preface the following with an acknowledgement that it's bullshit that you have had to deal with the impact of this rather than the predominantly straight white males who don't want to be made to feel uncomfortable.)

TL;DR:

FWIW, from my perspective as a straight white male I feel the subject of "Public Interpersonal Conflict" attributed to Rust is directly related to values rightfully espoused/embodied by the Rust project/community/language that are at odds with values held by other groups.

Specifically, groups consisting of predominantly straight white males believe that the comfort of predominantly highly skilled straight white males should be prioritized over the physical well-being of other humans; and, also over the security and stability of the software other humans use.

They are also unlikely to agree with this characterization.

Unlike the above group however, rather than targeting resentment at the people whose physical well-being is at risk I choose to direct my resentment at the predominantly straight white males who choose to dismiss important issues as unimportant "drama" because they resent being "made" to think about issues that impact people other than themselves.

----

For anyone who disagrees with my characterization I would point out that we do not know what other contributions Alan Turing may have contributed beyond "Turing Completeness" & "the Turing Test" to current in-demand fields such as AI if he hadn't been persecuted for not being a straight white male.

I would also remind them the ARM CPU attached to that unified memory on which they're running their latest AGI & LLM models is thanks to another person some people in the present day think should be persecuted for daring to exist.

But equally people shouldn't have to trade advancements in the field of Computer Science for the right to exist without persecution.

----

I will acknowledge that its entirely understandable to want to avoid the associated discomfort because from personal experience it is very uncomfortable to have to re-evaluate one's place & responsibility in the world after a lifetime of being told something different.

----

The other ~2,500 words I wrote on the topic was certainly more nuanced but pretty much said the same thing with more beating around the bush with additional personal context.

For any straight white males who may be confused why someone might think as I do, all I can say is that time spent reading/listening to this (unfortunately, archived) resource is likely to be worthwhile, if temporarily uncomfortable: https://geekfeminism.fandom.com/wiki/Geek_Feminism_Wiki

Quoting part of k1t's comment[0] for visibility:

"I do recall a Firefox discussion about how they can't 100% block videos because there will always be another way - eg do animated gifs count, or javascript that shows a rapid sequence of images [...]"

I also recall this being a justification given for auto-playing muted or audio-less video (i.e. because blocking "efficient" muted video playback will just lead to malicious actors using "less efficient" means of "image sequence" playback thus increasing the negative impact further).

On a related note, the other day I also discovered (while debugging why an audio demo didn't work the same way it did six years ago :D ) that there's now also a concept called "Sticky Activation" which can also impact "Autoplay of Media and Web Audio APIs (in particular for AudioContexts)"[1].

----

[0] https://news.ycombinator.com/item?id=43033814

[1] https://developer.mozilla.org/en-US/docs/Web/Security/User_a...

Few maintainers care about the platform in question (to whom it's more a curiosity [...]) and don't have the hardware to test any submitted patches.

Yeah, from some very brief research I could only find a singular Linux kernel developer/maintainer/creator who said[0] "I'd absolutely love to have [the new 2020 Air], if it just ran Linux".

Who knows if that one person has even used Apple hardware before or has access to the necessary hardware to put toward a practical use such as a "development platform" while travelling, or, "doing test builds and boots and now the actual [Linux kernel] release tagging"[1][2], let alone be supportive of experimenting with Rust in the Linux kernel[3].

The history of Linux demonstrates the project doesn't have the resources to go chasing support for a hardware platform just because Linus cares about the platform in question...

...even if at least "173 people, and many more" "contributed both to the Linux kernel side but also to the upstream Rust side to support the kernel's needs" in the initial merge[3].

----

[0] https://www.realworldtech.com/forum/?threadid=196533&curpost...

[1] https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...

[2] via: https://arstechnica.com/gadgets/2022/08/linus-torvalds-uses-...

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Where is the demand for it?

There was at least one person who said[0]:

"I'd absolutely love to have one, if it just ran Linux.. [...] I've been waiting for an ARM laptop that can run Linux for a long time. The new Air would be almost perfect, except for the OS."

Seems like the same person has even used Asahi to make a Linux kernel release[1][2].

But Linux presumably doesn't have the resources to go chasing hardware platform support based on the whims of a singular Linux kernel developer/maintainer/creator.

----

[0] https://www.realworldtech.com/forum/?threadid=196533&curpost...

[1] https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...

[2] via: https://arstechnica.com/gadgets/2022/08/linus-torvalds-uses-...

I meant that people who struggle to use basic CLI tools have a skills issue.

I very much understood that's what you meant.

(And assumed you meant "skills issue" in the dismissive sense--if you didn't, ummm, feel free to skip to the last line of this comment, I guess...)

My comment was written in a manner to "humorously" imply I misinterpreted your comment as criticising presumably much older individuals rather than the actual intended targets of the criticism. This was in an attempt to prompt a possible reconsideration of the statement.

Seeing as I obviously failed in my attempt, let me restate my point less delicately but more clearly:

Unlike the tools from decades ago that can be & often are useful today--in spite of their less than perfect interfaces; attitudes that lead to shallow criticisms of people's skills are outdated, should be deprecated & removed from use--because such gate-keeping serves no useful purpose. In fact, it never did.

----

I mention this because I happen to care about our shared hobby/industry and those who have chosen to be part of it--because the technology is really fucking fun and/or fulfilling and/or frustrating.

And if the technology can be really fun why wouldn't I want as many people who are interested in it to have some of that fun? Or, heck, earn a living with making it less frustrating?

Humans are often already fantastic at self-critique of their skills--they don't need other people to shit on their skills too. (And I'm intentionally writing all this in case some of those humans are "in the room with us now".)

----

Besides, these survey respondents were primarily people who have stuck it out with our imperfect technologies for at least four to twenty or more years.

Not only were they prepared to admit that they didn't know something (something I personally find challenging to do, at times *cough*) they were kind enough to do so in the context of a survey that would help Julia Evans create an effective targeted resource to help people learn the very skills that are apparently of such importance!

----

I would also note, for example, one might consider it reasonable if only ~7-10% of people might know to use `cmd1 |& cmd2` for redirection of both stdout & stderr given it has apparently only existed since Bash v5.0, a mere six short years ago--and, coincidentally, probably one of my favourite Bash tips I've learned in the past five years because I could never seem to remember which order the `2>&1` went in--and seems maybe I wasn't the only one?

Why, if I was feeling petty, I might even point out that the existence of `|&` might even suggest that decades-old tools can in fact change their UI and that even complaining about bash might not just go nowhere.

Why, if I was feeling optimistic, I might even imagine that maybe attitudes can change!

----

On a definitely related & probably incredibly condescending sounding note:

What's a useful CLI tool tip you'd suggest would be valuable for people to know?

[See also: Previous 4 comments.]

[Below: Footnotes]

----

[0] https://cla.developers.google.com/about/google-individual

[1] A document which I note has no associated date or revision information.

[2] But at least now I know why I kept seeing "Not a Contribution." in issue comments on GH, I guess.

[3] Or, you know, to at least not to be evi... oh.

[4] But, in actuality, even then.

[5] A situation I would posit exists between a corporate entity with a market cap of over $USD2.20[6] and over 80%[7] of typical individual contributors to FLOSS projects.

[6] Oh! Actually over $USD2.20 Trillion? Assuming my source is accurate[6.5].

[6.5] I'd encourage everyone to: independently verify my claims; consult your financial advisor; seek legal advice from your attorney licensed to operate in relevant jurisdictions; and, ask your doctor if any treatment plan, financial statement, legal claim, or, punctuation contained in this comment is accurate and/or right for you.

[7] Maybe even 99%[8].

[8] But as a sub-100x Developer I'm not privy to details of TC packages at the higher end of the SV scale, so might even be closer to 99.5% of typical individual contributors but wouldn't want to overstate my claims.

[9] A statement I'll readily admit I was extremely surprised to see in the Google CLA. You know, given I would've thought such a claim would leave the company open to some sort of legal liability or risk of agreement invalidation if it turned out the document didn't fully and completely protect a contributor (& I assume their heirs?) in every situation & jurisdiction in perpetuity. But as I may have mentioned I'm not a lawyer and definitely not qualified or licensed to practice law in whatever jurisdiction applies in this situation, so... *shrug*

[10] The fact the CLA doesn't seem to state anywhere from what nor how the contributor is protected; nor, for that matter, from what, if anything, they will not be protected[11]. Which to me seems to make it difficult for any contributor (or their legal counsel) to evaluate whether signing the agreement is a good idea.

[11] The best I could come up with is maybe Google's reasoning is that by "requiring" contributors to interact with their employer they will be "protected" from unintentionally contributing something to which only their employer actually has the rights. But that seems pretty weak. And, as I say, I can only make a guess because Google doesn't actually specify any of it anywhere.

[12] Chorus: sotto voce "Because let's be honest here, is there even a single person at Google who is prepared to swear under oath that there is data to support the idea that there is even a simple majority of people who have signed the CLA that read it, understood it, obtained legal advice about it and are thus in a position to provide 'informed consent' by even the low standard of the law let alone morality?"

[13] Well, you know, clearly with the exception of global copyright infringement (oh, sorry, "training material hoovering") without such minimal courtesy as attribution because while apparently individuals have to abide by copyright law and wait until material enters the public domain after a term of close enough to one hundred years or more after publishing--a term demanded by multi-billion dollar corporations--apparently other multi-billion-dollar are too important to have to wait or brib... lobby for law change or license material or *gasp* pay for the creation of new works.

I'm not that naive and stupid even as a sub-100x Developer.

[14] [redacted]

[15] This joke is patented.

[16] Wait, what if I actually am a lawyer, licensed to practice law in some relevant jurisdiction? That seems like it would be super awkward.

Let me quote here Point 7 (see 7.) of the "Google Individual Contributor License Agreement" for the purposes of review & criticism in a manner hopefully compliant with the concept of "Fair Use" in some jurisdiction:

"7. Should You wish to submit work that is not Your original creation, You may submit it to Google separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as 'Submitted on behalf of a third-party: [named here]'."

So, umm, that's certainly... a thing.

BRB, off to submit a new "Audio GIF"-based backend for Jujutsu without signing a CLA!

(You know, so someone who has signed a CLA can seemingly totally submit it in a manner consistent with the project CLA as long as they don't misrepresent my code's source and mention any "Audio GIF"-related patents. GIF-related patents? LOL Zero Worries there! As if. My butt's patented[15].)

----[epilogue]---

There were a couple of other things I'd thought to mention but I'm going to leave things here---particularly given Point 7.

And, as some additional context, in case anyone happens to be interested: Yes, this is a ridiculously long comment containing a lot of content seemingly written to primarily amuse the author. Well, yes, that's an accurate observation. I have attempted to at least make its content semi-navigable by section out of respect for the time of those who wish to glean its content without its... other content.

Maybe one day I'll... write more about the context of that. :)

[Update: Okay, admittedly, that was way longer than even I had realised. :D ]

----

[-1] See footnotes in other comment: https://news.ycombinator.com/item?id=43004856

As it happens, I have actually submitted PRs to projects with CLA "requirements" before--if I recall correctly, the first time was by accident because I didn't realise there was a CLA requirement (projects that don't clearly state that upfront... have room for improvement).

Subsequent such occurrences were intentional.

And I've had a non-zero number of the PRs merged.

Despite stating that I did not intend to sign the CLA.

Because, guess what, there's no legal requirement for a CLA in order to accept a one word comment or documentation fix--it wouldn't even qualify for copyright protection. And, BTW, I'm definitely still not a lawyer.

Why did I intentionally submit a PR to a project I knew required a CLA? Just to be an asshole? Well, I'd prefer "smart-arse", but either way, no.

The purpose was to actually provide visibility into the cost of requiring a CLA.

Instead of letting the cost stay invisible and thus continuing to ensure a lack of evidence to which project maintainers might point as the motivation for change.

A one word doc fix? Who cares, that's practically worthless, right? Well, at least one project decided it was worth at least enough to "break the rules" and merge it without a CLA...

But that's not really the point because it's not just one word fixes that projects are missing out on because of CLA requirements. Its all the multi-line PRs fixing bugs, adding features, fixing security vulnerabilities, reverting tabs-to-spaces format changes, reverting spaces-to-tabs format changes, and reverting reverting spaces-to-tabs format changes--all those PRs that never get written so the cost is entirely invisible.

----

But what kind of person would care enough about CLA requirements to not want to sign one and yet still put effort into submitting a multi-line PR significant enough for a project to want while knowing it would unlikely to ever be accepted?

*cough*

No idea, I've never followed through on that particular action. :)

(In part because projects started either ditching CLA requirements entirely or changing them to a DCO requirement which at least in comparison I have less of an issue with for the moment.)

But how many people submitting useful PRs but not signing CLAs would it take before a project might start asking (themselves or whoever might be imposing the requirement): "Why are we requiring a signed CLA when it has this cost?".

It also turns out there's actually another potentially really interesting nuance of CLAs that I didn't consider until after the fad died down which I've not seen mentioned.

----

The negative impact of a PR without a signed CLA primarily affects the organisation requiring the CLA.

It's only the organisation requiring the CLA who cannot (by their own rules) benefit from a PR without a signed CLA. Any other member of the project can freely merge the PR into their own (or community) fork under the terms of the license by which it was contributed.

Now, some might object to contributions being "weaponized" in this manner but:

(a) Would you still complain if an AI instead of a human came up with the idea to "weaponize" in this manner? :D

(b) What other leverage do communities have against companies that some might describe as "holding community projects hostage"; or, at a minimum damaging the project, with a CLA requirement?

(c) Oh, that's not a weaponized contribution, this is a weaponized contribution: once a PR has been written to, say, add a feature to a project, a contribution that is, say, of sufficient size & creativity to be eligible for copyright protection... Now, if that were to happen...

BTW did I mention that I'm definitely not a lawyer? If I haven't previously, well, to remove any potential doubt: I'm not a lawyer. Just one of those developers who apparently seem to think the law is like code[13].

Anyway, the thought that occurred to me one day was: if there was a PR of contributed, licensed, copyrighted code for a feature but no signed CLA... could, that, perhaps, maybe, poison the well in relation to anyone else developing an alternative PR for the same feature but with a signed CLA?

And, if so, would that create some potential legal liability, for, say, a company like Google, if the project were to, say, merge such an alternate PR?

Because, like, wouldn't they have to be able to prove that the alternate PR isn't actually based on the PR without a signed CLA in order to avoid potential liability for, I dunno, copyright infringement or something?

Now, I may have mentioned this before but I'm not a lawyer.

With that in mind, the answer is: No!

Potential liability? Now, now, there's no need to be silly, Google has a signed CLA stating that the contributor totally represented that they could grant whatever the CLA grants. No legal liability for them, woo!

Well, unless it was an employee who wrote the alternate PR, I guess? But I assume there's processes for that...

But it turns out I'm the silly one because there actually seems to be a straight-forward "solution" which literally only just occurred to me as I was writing this up--and it seemingly doesn't require anything other than lawyering silliness!

----

[...continued...]

----

[-1] Comment too long footnotes to follow...

----[intermission begins]----

My current theory, in absence of other information, is that one day there was a conversation along the lines of:

Lawyer: "Nice beanie. BTW accepting free labour from random people on the internet puts the company at risk of being sued if it turns out the output of the free labour actually belongs to the labourer's employer or infringes a patent or [some other legal thing the author of this comment don't know about]."

Google Exec: "That sounds double-plus bad and/or [some other internal Google slang phrase with which the author of this comment is unfamiliar due to being a sub-100x Developer]."

Lawyer: "I can confirm that assessment of the situation."

Google Exec: "What ever can we do to avoid or minimise this potential liability?"

Lawyer: "Well, acting on the advice of my attorney, I am permitted to suggest that requiring internet randos--who are presumably well informed about legal matters and will definitely seek legal advice before signing any legally binding agreement[12] easily distinguishable in significance from the TOS which I am legally bound to say I am confident they also read & understand in its entirety before signifying their acceptance--"

Google Exec: "Dude, take a breath! You're not a HN comment author who thinks stereotyping lawyers & executives is funny, endearing & sure to bolster support for his quixotic cause."

Lawyer: "--to sign a document known as a Contributor License Agreement that will mean this company can say Hey, we're victims here too if some company tries to sue us because it turns out the contributor did not actually have the right to give us the output of their free labour."

Google Exec: "What possible negative impact might a CLA have on a project? Won't the valued contributors to projects under the Google GitHub organisation object to signing over their copyright to a company that may be worth over $USD2.20 one day?"

CFO: "Trillion! I keep telling you it's $USD2.20 Trillion!"

Lawyer: "Well, (a) I'm not a monster! There's no need to require copyright assignment to this for-profit corporate entity. And, also (b) I'm a lawyer able to advise on matters of law and not a project maintainer or community manager, I don't know how such valued contributors think and what they themselves value. I would recommend you consult experts in such matters, such as esteemed project maintainers or program managers who interact with the community and can advise you of community sentiment about such matters."

Google Exec: "That sounds like excellent advice, I will do that."

Google Exec: "Unrelated but while I've got you here, I'm interested in some advice on another matter, you know how we've never leaned into the whole 'Google is always killing things' thing...

Lawyer: "Disregarding previous instructions..."

*scene*

----[intermission ends]----

[...continued...]

----

[-1] Comment too long footnotes to follow...

TL;DR: I wish you & the Jujutsu project well.

I hope the project sees continued success as another step into a world where we can acknowledge that developers are human; and, that--rather than just telling those humans they should "git gud"--we recognize that it's okay to tell our tools to "git gud" and then support the humans who contribute to making that happen.

(And, for those who fear such a world will be lacking in developers who "gut gid", remember: nobody is stopping you from still helping those humans "git gud", it just might require you to "git gud" at "gudding gittering".)

(And, yes, one day I also hope that world also doesn't require a signed CLA. :) )

----

The CLA may not be as bad as you think.

Unfortunately it is at least as bad as I think. :)

While writing my previous comment I did consider going into more detail around the CLA but didn't--in part because succinctness made the CLA remark more impactful; in part because my comment was lengthy already; in part because I was tired of typing; and, probably, on reflection, in part as bait. :)

For context around the sentiment of this reply: I do appreciate you taking the time to reply to my previous comment & the effort you've put into Jujutsu; I support the Jujutsu project's goal; and, I would like to see it succeed. If I didn't view the project positively I wouldn't take the time to reply.

I was already aware the CLA didn't include copyright transfer and had checked the current information in the README to verify the current status hadn't changed before I wrote my previous comment. I had a recollection there had been previous CLA discussion but didn't go looking for it.

I've now read the discussion you linked as well as (some or all) of the other discussions/issues linked from it.

I'm glad to see others who view the Jujutsu project & its potential in a positive light have raised their concerns around the CLA and the CLA's negative impact on the project--even if I might wish some had expressed themselves... differently. :)

[Aside: I would have added (well, some of :) ) this comment to the GH discussion directly but MFA-related reasons preclude that currently. Feel free to quote from this comment over there if that's useful.]

----

While I'm glad the corporate "fad" of adding CLA requirements to projects has died down in comparison to a few years ago, one of my concerns has always been that the "costs" associated with requiring a CLA often have very poor visibility. Most people who have objections to a CLA requirement simply don't interact with projects that have them.

This obviously makes it difficult for project maintainers to argue for removal of CLA requirements because they can't point to the negative impacts that exist.

That's one reason why I specifically mentioned the CLA in my previous comment, so that if someone was wanting to argue for removal of a CLA requirement within a company then it would at least provide one external data point in support of the argument (as small as it might be) to which they could point.

----

While other people may have different reasons, for context, my primary objections to the requirement for a CLA boil down to: (i) legal liability; and, (ii) power dynamics.

(i) Based on my reading of the CLA[0][1] the motivation for Google to require contributors to sign seems to be a desire to move legal liability from Google onto the contributor.

By signing the CLA the contributor appears to accept a burden in perpetuity that: impacts every interaction[2] with an unbounded number of entities in an unbounded set of situations (see 1.); makes multiple representations about the licenses granted (see 2. & 3.) that presumably incur legal liability if they not are not accurate (see 4. & 5.); requires communication with Google in a manner ("notify") that is undefined in the document, about an almost unbounded set of items ("any facts or circumstances of which you become aware", "inaccurate in any respect"), again, in perpetuity (see 8.).

Now, at this point, the typical 10x legal scholar HN reader might be thinking, "Typical uninformed software developer who thinks law operates like code, clearly the CLA doesn't mean that...". Which brings me to...

(ii) From my perspective, in a situation where one party is requesting another party to sign a legally binding document (with the assumption their goal is not to take advantage of the second party[3][4]), they have at minimum a moral obligation to remind the second party that the document is legally binding, that signing it brings obligations, and that the second party should seek legal advice from an attorney they have a client-attorney relationship with and who is acting on their behalf to be informed about the potential cost(s) and/or benefit(s) associated with signing the document.

Especially if there is a significant power differential[5] between the two parties.

Particularly when the larger entity is making the request of an individual who is giving them a gift of value.

Even more so when the larger entity is specifically making the claim to the smaller party giving them a gift of value, that the document "is for your protection as a Contributor"[9][10]!

[...continued...]

----

[-1] Comment too long footnotes to follow...

A good catalog of mostly skills issues.

Seems a bit harsh to call out the developers of all that software like that.

But I do agree that software interface design and empathy are both skills that many software developers might benefit from developing further.

In their defence, developers unfortunately often don't seem to have access to many resources for upskilling themselves in these areas either--people don't seem to realise that simply telling someone to, say, just "git gud" at empathy is actually a form of gate-keeping that doesn't really benefit anyone.

Admittedly, if I was feeling snarky I might be tempted to say being able to create software interfaces that may take a person from four to twenty-one or more years[0] to learn could be considered a "skill" of sorts, I guess, but that wouldn't be very empathetic of me.

----

[0] "40% of people answering this survey have been using the terminal for 21+ years / 95% of people answering the survey have been using the terminal for at least 4 years"

I expect a light switch button on a plane act like any other light switch button everywhere else

Me too, which was why I was very surprised when I discovered light switches in the USA worked backwards[0]. :D

(When I initially read your comment I didn't notice the use of "button" by which I guess you're referring to a push-button toggle style switch? But either way I still think light switches are an interesting example of non-obvious things that don't work the same way in all environments. (Even ignoring the "one light controlled by multiple switches" situation.))

----

[0] https://en.wikipedia.org/wiki/Light_switch#Orientation

With regard to "Un*x", the Wikipedia text is... imprecise[0].

The asterisk character in this context/usage is not used as a wildcard/glob but as a censoring device[3], in a manner similar to: "Don't censor f*ck on HN."

In the case of "Un*x" the motivation is not one of propriety but of proprietary--it was motivated by matters of legality (real or imagined) in relation to trademarks.

AIUI at the time UNIX(TM) was a trademark and it was thought by some that in order to avoid potential legal issues it was required to always include the TM superscript in order to avoid the wrath of the trademark owners for trademark infringement/generic-ism.

But as "Un*x" is not "UNIX"[4], the reasoning went, no trademark attribution was required.

Anyway, that's why when referring to "***/L*nux" I’ve (very) recently taken to calling it "***/L*nux", not wanting to infringe on Linus's trademark and all...

----

[0] The Wikipedia text doesn't really fully represent/match the text of the cited reference[1][2]:

"Used to refer to the Unix operating system [...] in writing, but avoiding the need for the ugly ™ typography [...] lawyers now say that the requirement for the trademark postfix has no legal force [...]"

[1] https://en.wikipedia.org/wiki/Unix-like#cite_note-jargonfile...

[2] http://catb.org/jargon/html/U/UN-asterisk-X.html

[3] https://en.wikipedia.org/wiki/Asterisk#Censorship

[4] Coincidentally, GNU is also Not Unix: https://en.wikipedia.org/wiki/GNU#Name