Best Keyboards Ever: A Deep Dive (Documentary)

Rayndalf

24 May 2021, 09:18

Findecanor wrote:
24 May 2021, 08:42
I don't think the strange-looking PCB design is a result of cutting corners, but more of the designer's (lack of) style ...
I've never heard about any problems leading from the ugly routing though.
My accusations of cost cutting mostly come from the quality of machine work. They used too large a cutter on the high profile cases. The corner should be tighter, but instead they just increased the gap on all sides to work around the radius of the larger cutter.

It looks cheap and the stabs are poor. Boards like the Hansung TFG line show that better fit and finish can be had for $100 less. The standard CTRL may well be competitive in it's price range though.

Edit: I could not find an official close up image of the Hansung TFG ART so I poached one from reddit. Those are no the original keycaps, but the tighter tolerances should be visible.
Attachments
c3qev1e4nnq21.jpg
c3qev1e4nnq21.jpg (887.97 KiB) Viewed 6389 times
aqGz8vES8OJiIh4i3ggt_1500x1000_MD-92936_14.jpg
aqGz8vES8OJiIh4i3ggt_1500x1000_MD-92936_14.jpg (291.01 KiB) Viewed 6390 times

jmaynard

24 May 2021, 13:07

esr wrote:
24 May 2021, 01:39
Findecanor wrote:
24 May 2021, 01:28
Cool that you know Jay Maynard (aka "The TRON guy") and chose to have him. :)
Jay and I have been friends for a very long time. I knew him before he was Tron Guy.
I've known Eric and his wife since the early 1990s. Keyboards have been a frequent topic of discussion between us over the years. I've got plenty of experience with IBM keyboards, having once been an IBM mainframe systems programmer; I just don't like them much any more. My daily driver is an Apple Magic Keyboard, which I love. I do own 3270- and 5250-layout M122s, and the terminals they're attached to.

Oddly enough, my current project involves a 3270-layout M122, which I'm having to bolt mod, and that's driving me nuts...

User avatar
Muirium
µ

24 May 2021, 13:32

I did an M122 bolt mod, a good few years ago. The process will definitely drive you bolt and nutty. Sympathy!

As for keyboard tastes: I quite like the integrated keyboard on my M1 MacBook Air here. As far as thin goes, it's a huge improvement over their recent stuff, and beats everything they did on all earlier chiclet Intels. Have to go back to the PowerBooks to find better.

User avatar
XMIT
[ XMIT ]

24 May 2021, 13:44

I will have more to say later. Apologies for the few, rambling thoughts.

HaaTa has force curves on plot.ly/~haata that show many (possibly all?) of the keyboards you describe.

It took me ages to wrap my head around how a buckling spring board works so an animation would be super helpful.

Did you talk about dye sublimation and the single key profile? Both of these were cost saving measures.

Clickykeyboards is a regular here, in case you want him to make a cameo on your show.

The entire script is a bit US centric. IIRC Germany had a requirement for keyboard ergonomics that drove lower profile designs. I've never done a deep dive on it, though.

I would be a little more precise with wording for the rollover situation with a membrane keyboard. You get two key rollover by default but this can be up to n key rollover in certain situations.

User avatar
Muirium
µ

24 May 2021, 14:06

That's a rollover definition thing.

X key rollover means that ≥X simultaneously pressed keys will be correctly reported to the host. Note the greater than!

Well designed 2KRO boards, like classic Model Ms, are fine with many combos like Shift + Alt + Arrow keys because they were designed well to prioritise the modifier keys. Rollover is an artefact of the matrix design, the logical layout, rather than the physical layout. So if you separate important keys out a bit in the matrix, you can score extra key presses while still remaining technically 2KRO.

Here's how IBM did it on the Model M:

Image

Nice and roomy around those Control and Shift keys, as it should be. They won't block or ghost, because the relevant cells in the matrix are simply empty!

But the Model M is still 2KRO. Just try mashing the WASD keys on a vintage Model M. IBM had no idea some kids writing videogames would use those in lieu of arrow keys! They block badly, proving the board is still just 2 key rollover in the worst case; which is how rollover is defined.

esr

24 May 2021, 16:18

XMIT wrote:
24 May 2021, 13:44
HaaTa has force curves on plot.ly/~haata that show many (possibly all?) of the keyboards you describe.
Wow, that is an amazing resource. I've added it to the references in my Tactile Keyboard FAQ.

http://www.catb.org/esr/faqs/tactile-keyboard-faq.html
It took me ages to wrap my head around how a buckling spring board works so an animation would be super helpful.
This one is in my stage directions:

https://i.imgur.com/pPQTlu6.gif

I'm open to a better one.
Did you talk about dye sublimation and the single key profile? Both of these were cost saving measures.
No mention of that yet. I don't think it's very important for this video to get into details of cost-saving tactics except as they directly affect keyfeel.
Clickykeyboards is a regular here, in case you want him to make a cameo on your show.
I'm not at all opposed to that idea - he does excellent work and seems like a friendly, upright guy. I have not thought of anything for him to do in a cameo, though. We added Tron Guy for humor and a visual to break up the talking-heads stretches; I don't think I'd want to play Clickykeyboards for laughs, though.
The entire script is a bit US centric. IIRC Germany had a requirement for keyboard ergonomics that drove lower profile designs. I've never done a deep dive on it, though.
Admiral Shark actually posted the gory details of the German standards thing upthread. I fear that's too deep in the technical weeds for this video, though we do now nod to the ISO layout where ANSI is mentioned.

(Minor personal grumble: My ideal layout would be ANSI-like but with an ISO-style big-ass Enter. Dunno where I'd put the backslash key, though...)

What else would you like to see to make the presentation less US-centric?
I would be a little more precise with wording for the rollover situation with a membrane keyboard. You get two key rollover by default but this can be up to n key rollover in certain situations.
Yeah, I'm going to work on that.

User avatar
XMIT
[ XMIT ]

24 May 2021, 16:56

Muirium I'm working on a fairly long, technical deep dive on the Model M's matrix so I am familiar. A few kind folks have reviewed it and provided some excellent feedback so far. I don't want to waste anyone's time until I've incorporated their revisions.

But, for the Model M, it suffices to say that 2KRO is guaranteed for all keys, and 10KRO (how many fingers do you have?) is possible for some very specific combinations. More precisely, max(($NUMROWS)KRO,($NUMCOLS)KRO) is possible for the right keys.

esr

24 May 2021, 17:25

Muirium wrote:
24 May 2021, 14:06
Nice and roomy around those Control and Shift keys, as it should be. They won't block or ghost, because the relevant cells in the matrix are simply empty!
Thank you, thank you, thank you for that graphic. We'll use it in the video, it illustrates the point about prioritizing the mod keys well and I have upgraded the explanation in the script to match.

Also in general more eye candy to break up the talking-heads sections is a good thing in this kind of vid.

User avatar
XMIT
[ XMIT ]

24 May 2021, 18:17

esr wrote:
24 May 2021, 16:18
XMIT wrote:
24 May 2021, 13:44
Did you talk about dye sublimation and the single key profile? Both of these were cost saving measures.
No mention of that yet. I don't think it's very important for this video to get into details of cost-saving tactics except as they directly affect keyfeel.
Cost reduction is an important theme in the Model M saga.

After all, what is a Model M but a cost reduced Model F? What is a Model F but a cost reduced Beamspring? What is a Beamspring but a cost reduced Selectric?

The Selectric was offering tactile feedback in the 1960s.

It's remarkable how IBM adapted, generation to generation, the idea of mechanical hysteresis as tactility, through a number of completely different mechanisms.

Not entirely orthogonally, cost reduction is the primary reason that there are so many Model M boards alive today. Millions of these boards were made, and many of them ended up in landfills.

esr

24 May 2021, 18:40

I have thoroughly reworked the section on rollover and ghosting. Please scrutinize carefully as I don't have hard documentation for some of this, especially the bit about older Unicomps coming up in USB normal mode. I deduce this from the fact that one of mine would never talk to the BIOS firmware on my last desktop machine - I literally had to keep a crappy Logitech nearby for reboots.
Yeah, let's talk about rollover. Rollover and ghosting, two
different concepts that are often confused.

A keyboard has N-key rollover if you can press N keys down without
letting up on any of them and they will all register in the correct
order before any of them is released.

CAPTION: 2KRO, 6KRO, NKRO

The most common rollover limits are 2KRO, 6KRO, and NKRO. Very old
keyboard designs often have 2KRO. 6KRO is characteristic of USB
keyboards when they power up into what's called "boot mode". NKRO is
unlimited rollover; USB keyboards have this when the host USB
controller has told them to switch from boot to normal mode.

Well...maybe. Operating systems are supposed to issue that mode switch
near the end of their boot sequence. It's fairly common for broken
firmware in cheap keyboards to fail to interpret the mode switch
correctly. Less commonly, obscure bugs may prevent the OS from
issuing the mode-switch command when it should.

Often, failure to switch out of boot mode goes unnoticed because
actual 7-key combinations are very, very rarely invoked even by
twitch gamers.

Those are minimums, not a maximum. 2KRO keyboards can, and often do,
support lots of three-key and longer combinations. Just not all of
them - and for modern uses, the problem is worst when there are WASD
cluster has collisions.

FADE CAPTION

IMAGE: https://upload.wikimedia.org/wikipedia/ ... _stamp.jpg

A different problem that affected some older Unicomp products is that they
powered up in normmal USB mode rather than boot mode. This meant they
couldn't be used at all until the boot phase of some operating
systems was over.

FADE IMAGE

When a keyboard has limited rollover, the worst that can happen is
some keystrokes in a multi-key press fail to register. Ghosting is a
nastier failure mode: if a keyboard is susceptible to it, a
multiple-key press will generate spurious "ghost keystrokes" that
weren't in the sequence you pressed.

If this sounds like a different definition of "ghosting" than you've
heard before, that's because sloppy usage of the term "anti-ghosting"
in keyboard marketing literature has misled a lot of people about what
"ghosting" is.

When vendors talk about "anti-ghosting", what they actually mean
is that they support more than 2-key rollover, but only for certain
groups of keys like the WASD cluster and shift or control modifiers
that they expect to be used in combinations.

FADE IN: download/file.php?id=55938

Model F keyboards, both old and new, have unlimited rollover
and never ghost. For model Ms, it's more complicated. They
never ghost, but their rollover is limited. Most variants only support
2-key rollover. However, modifier keys like Shift, Control, and
Alt have their own traces so they don't count against that limit.

As you can see from this diagram, the WASD cluster that many
modern games use as arrow keys does *not* have its own traces.
That's because the Model M was designed well before that convention
developed in the 1990s.

FADE OUT

The new Unicomp Mini-M is an exception. It reworks the traces on its
sensor membrane to eliminate possible collisions with frequently-used
keys, including not just the modifiers but the WASD cluster as well.
Then it repeats a trick used in many gaming-oriented keyboards to
support more than the boot-mode USB limit of 6-key rollover. That is
to stuff two USB controllers into the board handling different sets of
leads from the keyboards.

With two USB controllers, you get better than 6KRO even if the
operating system fails to issue the keyboard mode switch when it
should.

According to Unicomp, the Mini-M can correctly report combinations as
long as 10 simultaneous keys. But not all such combinations; some
will still drop keys. It would take a much more fundamental redesign
of the sensor membrane to entirely solve that problem.

User avatar
Muirium
µ

24 May 2021, 20:05

Re: two USB controllers. There is a downside: it doesn't work on Macs. The Mac will see two distinct keyboards, and unlike Windows, it does not merge all their states into one logical keyboard. You can get absurd situations like Shift + letters not producing upper case, because "you're pressing Shift on the wrong keyboard." It's a hack that assumes every OS works like Windows, not the spec.

User avatar
raoulduke-esq

24 May 2021, 20:47

Muirium wrote:
24 May 2021, 20:05
Re: two USB controllers. There is a downside: it doesn't work on Macs. The Mac will see two distinct keyboards, and unlike Windows, it does not merge all their states into one logical keyboard. You can get absurd situations like Shift + letters not producing upper case, because "you're pressing Shift on the wrong keyboard." It's a hack that assumes every OS works like Windows, not the spec.
The more I see, the more I'm glad I haven't purchased one. Unicomp is gonna have to work all of that out AND release a Mac version before I hop in that boxcar and start sipping jungle juice with the other hobos and smoking corn husk cigarettes.

esr

24 May 2021, 21:03

Muirium wrote:
24 May 2021, 20:05
Re: two USB controllers. There is a downside: it doesn't work on Macs. The Mac will see two distinct keyboards, and unlike Windows, it does not merge all their states into one logical keyboard. You can get absurd situations like Shift + letters not producing upper case, because "you're pressing Shift on the wrong keyboard." It's a hack that assumes every OS works like Windows, not the spec.
That is a serious bummer. Linux user here, so not affected because it does merge USB keyboards, but...wow. I had a bad feeling about that dual-controller hack, I wish it had been unjustified.

User avatar
Muirium
µ

24 May 2021, 21:08

The nippy thing is NKRO over USB is a solved problem. Soarer managed it all by himself. TMK/QMK/Xwhatsit and every other self respecting hobbyist controller and converter all support it, and it works a beaut on Mac and everywhere else with USB. Unicomp did not need to reinvent this particular wheel at all.

User avatar
Yasu0

24 May 2021, 21:38

Knock on wood I've so far not had any problems with my mini-m related to the dual controllers. Said as a user who only needs it for a windows workstation.

Findecanor

24 May 2021, 21:41

esr wrote:
24 May 2021, 18:40
Very old keyboard designs often have 2KRO.
I would rewrite the script about that, so that you untangle the issue in one go so as to make it less confusing.

The number is for the minimum of all arbitrary chosen keys.
In other words, 2KRO means that of all possible key combinations on the keyboard, there is at least one combination of 2 + 1 keys that does not work.

BTW. The 6KRO-limiting USB "Boot Protocol" is actually 6 arbitrary keys + the eight modifier keys (Shift, Ctrl, Alt, "GUI" on both sides). The six arbitrary are encoded in an array, while the modifiers are encoded as bits in a byte.

However, there are brands that totally disregard the conventional way of counting, and write "10KRO", "14KRO" or even "NKRO" when it is the same bog-standard 6KRO protocol.
esr wrote:
24 May 2021, 18:40
6KRO is characteristic of USB keyboards when they power up into what's called "boot mode".
The HID spec clearly says that a "boot-capable" keyboard starts up in normal mode ("Report Protocol"), and that the BIOS should send "Set_Protocol (Boot Protocol)" to make the keyboard change protocol to the 6KRO "Boot Protocol".
Every operating system resets boot keyboards to the default when they start after the BIOS.

A keyboard does not have to be boot-capable, but keyboards that don't are rare.
esr wrote:
24 May 2021, 18:40
NKRO is unlimited rollover; USB keyboards have this when the host USB
controller has told them to switch from boot to normal mode.
It's a lot more complicated than that. Some have it, most don't.

The USB HID protocol works by the host regularly polling the device for a "report" of its full state.
The normal "report protocol" is not hard-coded in the spec but actually expressed in a blob called a "Report Descriptor", that the operating system requests from the device before starting to poll.
It is encoded in a binary data description language which has to be parsed by the host and used to decode every report. It is because of the complexity of the parser/decoder that the "Boot protocol" exists — for less capable USB stacks.

The report descriptor is supposed to allow each USB HID device product to have its unique report format, while the complexity would be relegated to the host side. This is how USB devices can do more things than PS/2 without requiring special drivers: there can be media keys and volume knobs on keyboards, keypads on mice, etc.
So, in theory, the use of the report descriptor should allow any device should be capable of NKRO, but ... with more complexity comes more opportunities for errors to creep in: USB stacks sometimes interpret different things in different ways — which the device engineers would have to be aware of, or work around.

The biggest issue is actually related to the boot protocols. A part of the spec for the boot protocols had been written ambiguous, and different writers of PC BIOS and keyboard firmware interpret the words differently.
The issue of confusion can be narrowed down to the question: Does a boot keyboard's normal "Report protocol" need to be identical to the boot protocol? (yes or no)
* Some keyboard engineers thought "Yes", so their keyboards use the 6KRO protocol regardless of mode — and the report descriptor describes the 6KRO protocol. (it is typically copied verbatim from an appendix in the spec)
* Other keyboard engineers chose to use the 6KRO protocol always because it was easier.

What's worse is that:

* Some BIOS engineers also thought "Yes" ... and never bothered to make their BIOS send the "Set Protocol (Boot Protocol)" request to the keyboard because they thought that would be superfluous, in total disregard of the spec.
This broke compatibility with some keyboards where the engineers had read spec the different way.

... and subsequently:

* Keyboard engineers chose the common subset, i.e. the 6KRO protocol, mostly so as to be compatible with everything.

Programmers in the keyboard enthusiast community have identified this problem and actually devised a workaround that is present in all major open source enthusiast keyboard firmware: providing both compatibility with all (known) BIOSes and N-key rollover.
Now, this above is not the only issue. Operating systems have different Report Descriptor parsers that are fussy about different details in NKRO report formats/descriptors ... but those details have also been identified and worked out together by the programmers in the community: at least for Windows, Linux and Darwin ...

Not all professional keyboard firmware engineers are knowledgeable about these workarounds, and there's a lot of firmware already out there that never sees maintenance. Firmware writers get hired to do one job, and bugs in the firmware are never fixed. some keyboard controllers come with firmware pre-installed, which can't be upgraded, etc.

However, for other keyboards there is an even simpler reason: There are different USB speeds, and over a
"Low Speed" USB bus, reports can't be longer than eight bytes anyway.

Some engineers have in the past tried to work around limitations with NKRO by using multiple keyboard interfaces, i.e. two virtual keyboards inside a USB device. (which is perfectly legal in USB: a USB device can be multiple things).
This trick was believed to be a reason why one particular keyboard did not work with MacOS X ... but it turned out to be Apple's fussy report descriptor parser. A workaround exists that injects a different report descriptor somehow. (don't ask me how Darwin's driver subsystem works)

Did I make your brain hurt again? :lol: Mine does whenever I think about this ...
Last edited by Findecanor on 24 May 2021, 22:26, edited 1 time in total.

esr

24 May 2021, 22:26

Findecanor wrote:
24 May 2021, 21:41
Did I make your brain hurt again? :lol: Mine does whenever I think about this ...
Yes. Yes, you did. That's just awful.

With the changes I'd have to make, that section is going too get too deep into the weeds for a video.

Is the explanation you gave me written up in a narrative form anywhere that the video can reference?

If not, will you cooperate with me in writing up that explanation in a "USB Rollover Demystified" FAQ that the video can reference?

User avatar
Muirium
µ

24 May 2021, 22:51

From Fin’s link:
OS X has modifier state local to each keyboard; The Noppoo implements NKRO with two keyboard interfaces but only of which has the modifier state. This makes it impossible to use modifiers with any key on the non-modifier keyboard.

This project only fixes the problems caused by the descriptor. However installing KeyRemap4MacBook has the side effect of making modifier state global.
A few things have changed since then. Macs no longer support third party kernel extensions (which is generally a good thing, given how flaky those can be) and KeyRemap4MacBook has been called Karabiner for many years now.

Speaking of Karabiner: I should have remembered it does this. (Certainly by default, can’t recall if there’s an opt out.) So, as an avid Karabiner user, even I might just be able to survive with a Unicomp SSK! Well, pretending the split controller was its only issue…

Findecanor

24 May 2021, 23:35

esr wrote:
24 May 2021, 22:26
Findecanor wrote:
24 May 2021, 21:41
Did I make your brain hurt again? :lol: Mine does whenever I think about this ...
Yes. Yes, you did. That's just awful.
Maybe the revision you had posted first was best.

You could perhaps sum it up something like this:
"The USB standard was intended to support N-key rollover for keyboards that could take advantage of it.
But the standard is both complex and loosely defined, which has led to different host-side USB implementations doing things differently in subtle ways.
In practice, the protocol variant with 6-key rollover has been the only one guaranteed to be compatible with every operating system and every BIOS, at least without the firmware engineers employing different workarounds.
Still, some keyboards with N-key rollover on Windows may not support N-key rollover on Mac for instance.
The keyboards that do N-key rollover over USB the best tend to have open source firmware, actually."

With anything longer I could write that gets too technical, there would always be a number of people who would misinterpret it. English is not actually my native language either.

I have written some on the wiki page for USB though but it did not cover all issues/the same way.
The credit for figuring these things out should go to Soarer, Hasu and HaaTa. I'm just a follower who been on the message boards and read (two of) these guys' source code. (Soarer never published his before he disappeared off the forums).

esr

24 May 2021, 23:45

Findecanor wrote:
24 May 2021, 23:35
The credit for figuring these things out should go to Soarer, Hasu and HaaTa. I'm just a follower who been on the message boards and read (two of) these guys' source code. (Soarer never published his before he disappeared off the forums).
If his source code is gone, how is orihalcon still making Soarer's Converters?

User avatar
Muirium
µ

25 May 2021, 00:20

Hex files, ready to flash, right in his original post:

viewtopic.php?f=7&t=2510

That’s the joy of soarer: you don’t have to build anything to use his work*. A godsend to power user nincompoops the like of me!

Soarer was on the verge of open sourcing his work. It has been reverse engineered since, but not published (because of gentlemanly doubt about ownership).

*One eventual exception was his tools, for live loading configuration files. They are open source and we did eventually manage to get them up to speed on 64 bit exclusive hosts.

Obin

25 May 2021, 02:22

Muirium wrote:
25 May 2021, 00:20
That’s the joy of soarer
Why would something not being open-source make it (more of) a joy for the user? Nobody stops you from distributing binaries, even especially if the source is open and free.

If anything, I could understand if it keeps people from considering Soarer's firmware to be a valid long-term option if all they have is a hex file they can't change.
It has been reverse engineered since, but not published (because of gentlemanly doubt about ownership).
There's also pretty solid legal doubt, both about the usage and redistribution (like by selling a self-built converter). And especially redistributing decompiled binaries that have been released without an accompanying license that expressly permits it is asking for legal trouble. Does not even have to be soarer that sues you, but any copyright troll legal firm that might have acquired the rights to his code since then. I don't like it either, but these things happen and I wouldn't want to risk it myself.
They are open source and we did eventually manage to get them up to speed on 64 bit exclusive hosts.
I was not even aware this was supposed to be hard. On my 64bit Linux system I just downloaded the sources, unpacked them and typed make.
But I guess on Mac not only are the complex things impossible, but the simple things are just a bit more difficult.

User avatar
Muirium
µ

25 May 2021, 02:44

It’s not a Mac thing. It’s a most users (hi!) really don’t wanna code thing. That’s why VIA is the preferred way to use QMK these days, too. Most of us (on every platform) are not maintaining a whole tool chain so we can build from source. The tools break, or our code breaks, and we wonder what the fuck are we doing. Wasn’t this just about mapping Shift + Backspace to Delete? Why are we supposed to be drinking Homebrew and who is this insufferable Git of which they speak?

Soarer’s converter has a lot going for it including the best macro support I’ve encountered and an amazing runtime flexibility which makes it superb for multi-keyboard use. My Soarer converter box detects keyboards on connection and reloads the corresponding config, live, without any user action required at all. That was impossible with any other converter at the time I made it, and may still be for all I know.

jmaynard

25 May 2021, 02:57

Muirium wrote:
25 May 2021, 02:44
It’s not a Mac thing. It’s a most users (hi!) really don’t wanna code thing. That’s why VIA is the preferred way to use QMK these days, too. Most of us (on every platform) are not maintaining a whole tool chain so we can build from source. The tools break, or our code breaks, and we wonder what the fuck are we doing. Wasn’t this just about mapping Shift + Backspace to Delete? Why are we supposed to be drinking Homebrew and who is this insufferable Git of which they speak?
You've touched on one of my recurring grumbles about folks doing open source on the Mac. I refuse to install Homebrew because it sucks in far too many dependencies I have no use for and don't want.

And, while I'd love to use a prebuilt binary for QMK, I'm going to have to do mine the old fashioned way because it's a new wiring/pin mapping...though I will use the online tool to set up the keymaps.

Obin

25 May 2021, 03:32

Muirium wrote:
25 May 2021, 02:44
It’s a most users (hi!) really don’t wanna code thing.
I get that. What I don't get is that "if you don't want to, it's better that you can't (or for it to be needlessly hard)" attitude. I like to have options, even (or especially) for things I don't like.

But I'll stop now since I don't want to send us even more off-topic than my last comment already did. Sorry for that.

esr

25 May 2021, 04:19

Obin wrote:
25 May 2021, 02:22
Muirium wrote:
25 May 2021, 00:20
It has been reverse engineered since, but not published (because of gentlemanly doubt about ownership).
There's also pretty solid legal doubt, both about the usage and redistribution (like by selling a self-built converter). And especially redistributing decompiled binaries that have been released without an accompanying license that expressly permits it is asking for legal trouble. Does not even have to be soarer that sues you, but any copyright troll legal firm that might have acquired the rights to his code since then. I don't like it either, but these things happen and I wouldn't want to risk it myself.
Hmmmm. As it happens, I have some relevant expertise.

I was the founding president of the Open Source Initiative. In that capacity I had to learn a lot about software IP law. My wife is an attorney who is familiar with that area. We might be able to help clarify the status of the code and suggest a legally sound way to relicense it. To be honest, based on the facts you guys have presented so far I don't think this will even be difficult or risky.

A relevant thing for all of you to know is that, supposing some predator did somehow acquire those rights, a court wouldn't look kindly on the predator hauling off and suing anyone. They have to ship a cease-and-desist letter first to give violating parties the option to cure any harm caused by the violation. In the absence of any demonstrable monetary loss by the rights holder (and it would be very hard to demonstrate that here given that the binary is redistributable), the most a C&D could demand is that you cease distributing. You cease, no court case, nobody is worse off than before.

I also know what copyright trolls will and will not bother with. There isn't enough money on the table here to interest those guys. They couldn't squeeze enough damages out of an individual to pay for the court time - their business model is shaking down large corporations.

Could one of you pass me contact information for the person who did the reverse-engineering by PM? I need to find out more about the circumstances. But I think I may see a way out of this. I have solved not entirely dissimilar problems before.

User avatar
Muirium
µ

25 May 2021, 11:00

Ah! Expertise sighted off the starboard bow! I'll write to you in private about the reverse engineer and his Soarer project.


@Obin:
I know I'm sounding like a real Soarer cultist here, but how I can I not point out he made Soarer's Controller too, which allows you to define your own controller pins and matrix as well as all the other functions of his Converter code, all at runtime! I love that Controller, used it on a few customs and even Model Ms. It's a wee gem, precisely because I can understand it all on first glance and get straight to praxis.

Obin

25 May 2021, 13:38

Muirium wrote:
25 May 2021, 11:00
@Obin:
I know I'm sounding like a real Soarer cultist here
Oh, not at all. I mean it is a really great piece of software. If it wasn't so useful and well designed, I wouldn't be annoyed about it not being open source.

esr

25 May 2021, 14:09

Muirium wrote:
25 May 2021, 11:00
Ah! Expertise sighted off the starboard bow! I'll write to you in private about the reverse engineer and his Soarer project.
I've pinged him.

Relevant fact: Soarer has been disappeared for 7 years. In Great Britain where he was domiciled (and in the U.S. which inherited British common law) that is long enough for a declaratory judgment that he is legally dead.

esr

25 May 2021, 14:50

Following that excursion I am still interested in feedback on the script.

Post Reply

Return to “Keyboards”