For starts, wouldn't it be kind of ironic to set up limits and authorization in a context that is about making some content available to the public?
I'd say any technical or legal restrictions or possible means to enforce DRM ought to be disabled or absent from the media format used when disseminating content that must be disclosed.
Censorship (of necessary) should purge the data entirely,ie: replace by ###
Well, in video land there is patent pools. For example, you pay nominal fee to download specs from iso/ice 14496-12 to learn the details about BMFF and then pay mpeg-la a couple of dollars per device of it uses an AVC / h264 decoder.
These are open standards, but mpeg-la tries to recoup some of the research costs from "freeloaders".
Open source implementations like ffmpeg are a bit of a grey area,here
For now at least - for H.264 AVC, the patents are expired in most countries and most of the final US patents that may apply to AVC High profile will expire in the first half of 2026 [1].
Except in Brazil, where there are even MPEG-4 patents still in effect (expiring later in 2026) and the H.264 patents will last until the early 2030s, I think because of a rule that gave 10 years extra but is now changed but not retrospective for these patents [2].
It most likely would prevent you from playing anything HDCP. HDCP is illegal (?) to reverse engineer, and there are special versions of HDCP2 specifically for HDMI. You need a license and a verified device for HDCP.
That might not matter much for an ordinary PC, but this Steam Machine will be competing for the living room with the PS5 and Xbox which have Netflix, Disney, HBO, etc; Not sure if things like Spotify are HDCP-protected.
It will be interesting to see how Valve works out the kinks for that. Honestly in general it'll be interesting, because putting those things on Steam Store basically turns Steam Store into a general software store instead of a game store. And the only cross-platform store at that.
With iOS and Android being broken open, you could have games be completely cross-licensed. I'd say other software too, but sadly with everything going the subscription model, you usually already have cross-licensing, in the form of an account.
it's removing HDCP protection that's problematic, not adding HDCP protection
looking at the available information on HDCP, it looks like the transmitter does not have to be authenticated - they use the receiver's pubkey, much like a web browser transmits to an HTTPS server
The source and the sink need a HDCP-licence. Both devices have embbed keys that get exchanged to estabish a encrypted channel. Without the licence you can't get the required key material.
AFAIK, you can even sell HDMI devices without HDCP. Practically though, every entertainment device needs HDCP support.
Part of what you're paying for is the right to use the trademarked tern HDMI, just like how the USB Consortium charges you stupid money to use the USB logo.
The suit over usage of "HDMI" in a reverse engineered version would wind up arguing whether or not HDMI is a genericised term and the HDMI Forum would lose their trademark. They will throw every cent they have into preventing such a decision and it'll get ugly
Can't you use a trademark to refer to the thing as long as it's clear you're not claiming to be them? Like if you say your PC is "IBM compatible" you're not claiming to be IBM, are you?
Yes, that might work. Strictly, HDMI is a registered trademark that might have strings but you could always say something like EIA/CEA-861... compatible instead
trademark doesn't cover descriptive language. saying it is an HDMI port is trademarked. Saying it is compatible with HDMI cables and displays is a purely descriptive statement.
It's called nominative use, and describing a thing as "HDMI compatible" is permitted.
One doesn't get to use the logo or even the typeface, but that's not a dealbreaker at all for the purposes being discussed here. Words themselves are OK (and initialisms, such as "HDMI," are just a subset of words like nouns and verbs are).
HDMI is patent-encumbered. The original specification has lost patent protection, but VRR and the other bits which form HDMI 2.1 and 2.2 are still protected as part of the Forum's patent pool. You could certainly try and upstream an infringing implementation into the kernel, but no one would be able to distribute it in their products without a license.
> no one would be able to distribute it in their products without a license.
In some jurisdictions, yes; however, some would probably still distribute it anyway, on purpose or not. I doubt all of them would get sued either, since lawsuits are expensive and difficult.
From my perspective, the objective is to make enforcement impractical.
> You could certainly try and upstream an infringing implementation into the kernel, but no one would be able to distribute it in their products without a license.
Isn't that actually a pretty good workaround? Hardware vendor pays for the license, implements the standard, sells the hardware. Linux kernel has a compatible implementation, relying on the first sale doctrine to use the patent license that came with the hardware, and then you could run it on any hardware that has the port (and thereby the license). What's the problem?
> relying on the first sale doctrine to use the patent license that came with the hardware
First-sale doctrine protects against copyright or trademark infringement. You might be thinking of "patent exhaustion"[1], which is a mostly US-specific court doctrine that prevents patent holders from enforcing license terms against eventual purchasers of the patented invention. There is no "transitive law of patent licensing", so-to-speak.
In this case, it would still not protect Valve if they exercise each claim in the relevant patents by including both hardware and an unlicensed implementation of the software process. It would protect end users who purchased the licensed hardware and chose to independently install drivers which are not covered by the license.
It's murky if Valve would infringe by some DeCSS-like scheme whereby they direct users to install a third-party HDMI 2.1 driver implementation on first boot, but I don't think they would risk their existing HDMI license by doing so.
What would the legal repercussions be against an anonymous coder who donated the code to multiple code forges? Action against the code forges themselves? I mean, not like they would be able to find the guy.
Yes, that. I think you're only allowed to claim support/compliance if you're certified. And that, allegedly, means they run a couple of closed source tests and involves paperwork and NDAs.
But Nvidia also has some less than transparent arrangements to support their customers in buying their goodies.
Which is not to say they aren't making money, it's more that in hindsight we may discover that the p/e ratios were not the primary measure we should have paid attention to...
> Yes but one can't just ignore the federal government itself, as if this wasn't an organization
True, though (at least in principle) a democratic government is a very special organization because it (again, in principle) exists only because it's the people's will.
I think when we think about our social fabric and the empowerment that individuals feel, that this is more of a theoretical rather than practical argument. All of the disenfranchisement, the feeling that your individual participation doesn't matter, the inability to steer the goals of the organization around your individual opinions, these are all just as present in a large state.
Sure a democratic government derives its legitimacy from the people's will but not from your will, and that is the role of the small community organization.
This is more propaganda than reality, though. Most democratic societies today have evolved out of very non-democratic ones gradually, in a process where the elite had given up some of its privileges to prevent losing all. One of the tricks involved in that process was the notion of a "popular mandate" - not that this isn't a thing, but genuine cases of it are far less common than politicians using the fact that more people voted for them as some kind of argument in support for some specific policy of theirs.
In practice the difference between a democratic and a non-democratic society is more quantitative. In a non-democratic society, people still have a check on the government - they can revolt, and, being far more numerous than any security apparatus that can be maintained over a long time, the rulers therefore cannot simultaneously piss off too many people at the same time. So the bar is pretty high, but not entirely insurmountable. In a democratic society, the people also get an option of protest voting, which provides a safety valve that bleeds off a lot of effort that would have otherwise gone into potential violence, but at the price of making this kind of "voter revolt" less costly to participants and thus more likely. However, representative democracy is still pretty bad at accurately reflecting population preferences - it still takes a lot of abuse before protest voting becomes prevalent enough to alter election results. And then, of course, new mechanisms were developed to "manage" democracy - more efficient propaganda, mostly.
Thus, in practice, governments can indeed be treated mostly similarly to other organizations in this regard.
That approach may be a viable heuristic but it will only get you so far. It's like flagging an opinion because it doesn't rhyme with the opinions of others.
That's not what humans do when they are fact finding, though. It's not what a (proper) scientist would do if she/he discovered a great insight or theory and was wondering whether it was true.
If you're turning to LLMs for great insight or theory, you're definitely doing it wrong. These tools are for well trod terrain, and when they're really just making shit up, it's almost always different shit each time. So yes, it's a heuristic, but for dealing with the stochastic weirdness these models sometimes spit out it works pretty damn well.
(I work at Oxide, though I wasn't around for the initial chip selection process)
It's at least partially a matter of timing: Oxide was picking its initial hardware in roughly 2020, and the RP2040 wasn't released until 2021.
A handful of people have done ports, e.g. https://github.com/oxidecomputer/hubris/pull/2210, but I expect to stick with STM32s for the foreseeable future – we've got a lot to do, and they're working well enough!
The internal RFD on the SP's design still talks about choosing RISC-V, and I don't think (or am simply bad at using search) that the move ended up being in an RFD.
How about banking apps? In my part of Europe a growing number of banks require installing an app via Google or Apple story. The Android ones are known to use sdks that at full of "telemetry". Cash is no longer an alternative.
Can you not use a browser to access banking services? If not, you should vehemently complain and/or move to another bank. And while cash is better for privacy, you can always use a credit card instead of your phone.
If nothing else works, my suggestion would then be to buy a cheap Android phone just for that indispensable banking app. Just leave it home in a drawer powered off when not in use, and use your a degoogled phone for your daily business.
I'd say any technical or legal restrictions or possible means to enforce DRM ought to be disabled or absent from the media format used when disseminating content that must be disclosed.
Censorship (of necessary) should purge the data entirely,ie: replace by ###
reply