Windows has an absolute onslaught of competition about to stream its way, and they're gonna be paying for every little enshittified user experience they've embedded into their OS. Hope they enjoy ripping that out just to slow their user numbers deathspiral

The people inside Microsoft fighting to keep mandatory accounts out are the equivalent of a crew throwing furniture off a sinking ship, hoping to buy more time. They're smart enough to have an innate sense of where things are going, and it might even help a little, but man... good luck.

Why?

If a prediction market is supposed to predict it makes no sense to exclude the best informed people. If I want to know the risk of a Boeing airliner crashing this year, Boeing insiders have much more to contribute than armchair observers.

And if a Boeing insider sabotages a plane to profit on a prediction market - that's illegal. If they're willing to break the law on sabotaging planes, they're surely also willing to break the law on insider trading at the same time. If we think this is a realistic risk, prediction markets should be banned entirely.

Only reason to exclude insiders is if the real purpose of a prediction market is recreational gambling.

But do require KYC on all customers and require their profiles and wagers to be public. The societal values of prediction market data would be an order of magnitude more valuable this way.

And use of illegal insider info would cease.

Just because a rule was created after something bad happened doesn't mean that the rule is effective to prevent it from happening again. The most common result when they try to ban something without removing the incentive for it to happen is to cause it to happen less obviously. Then the rule (and all its unfortunate costs) gets credited with not observing the bad thing anymore, even though that's not the same as actually preventing it.

Notice that you can use the stock market in the same way as a prediction market. After that healthcare CEO got murdered the company's stock took a hit, as anyone could reasonably have predicted it would. That's a perverse incentive in line with betting that someone will kill the CEO. We don't really have a great way of preventing stock trading from creating that incentive, we mostly just rely on the fact that if you do the murder then murder is very illegal. But if that works for the stock market then why doesn't it work for prediction markets?

This is true in theory, but in practice the impact of any regular individual's actions on a company is probably going to be small and uncertain enough that it's difficult to make a healthy and reliable profit from. Even the very extreme example of murdering the United Healthcare CEO seems to have caused the stock to drop ~16.5% (assuming the drop is entirely due to the murder). That's like placing a bet with ~1/6 odds. You'd need to short a lot of stock to make that worth the risk of murdering someone (leaving aside any moral issues obviously). You could use leverage to juice those returns but that is expensive and risky, too. If you can afford to deploy enough leverage to make it worth it, you can probably find ways to make money that don't carry a risk of the death penalty.

I guess viewed in this way a bet on a prediction market is like a very cheap, highly leveraged bet on a specific outcome. So the incentives are much stronger as the potential reward for the risk taken is greater.

When they know exactly when something is going to happen, buying put options that are cheap because they're slightly out of the money seems like it would be pretty effective.

> I guess viewed in this way a bet on a prediction market is like a very cheap, highly leveraged bet on a specific outcome. So the incentives are much stronger as the potential reward for the risk taken is greater.

You seem to be trying to make this about leverage as if that's a thing that isn't available anywhere else.

Let's try another example. Some group breaks into the systems of some publicly traded company and gets access to everything. Now they're in a position to publicly disclose their trade secrets to competitors, publish internal documents that will cause scandals for the company, vaporize the primary and backup systems at the same time, etc. Anything that allows them to place a bet against the company gives them the incentive to do this; the disincentive is that the thing itself is illegal. Leverage gives them a larger incentive, but there are plenty of wages to place a leveraged bet in the stock market.

But you don't know exactly what would happen. You know what you will do, but not how it will affect the company's stock price. Maybe it will go down a little, maybe it will go down a lot. Maybe you kill the CEO on the same day as good news is published about the company, which offsets the drop. Or maybe the market just decides the guy wasn't that good a CEO anyway. So you bought a bunch of cheap puts with a strike price of 100, but the stock only drops to 101, and you lose everything. You can buy puts with a higher strike but they will be more expensive.

> Leverage gives them a larger incentive, but there are plenty of wages to place a leveraged bet in the stock market.

Yes, but they are expensive, is my point.

Generally, the disincentive outweighs the incentive. You can increase the incentive through leverage. But that also increases the costs, which increases the disincentive.

There may well be situations where the incentive outweighs the disincentive. But in the context of traditional financial markets I think those situations are likely very rare due to the risks and costs, whereas with a predictions market the risks and costs could be reduced, so it is more likely to happen.

You never know exactly what would happen. You know what you will do, but not if the CEO is going to catch the flu and not show up that day, or have better security than you were expecting, or have a great surgeon, or a spouse who is willing to keep them on life support until after your prediction market contract expires.

> Yes, but they are expensive, is my point.

Only they're not. There are many ways to bet all or nothing on something people generally expect to have a <1% chance of happening, so that you either lose $1000 or make $100,000. Under normal circumstances you could make that bet 100 times in a row and lose $100,000 and the counterparty is happy to take all your money, but if you're able to do something to change the outcome yourself then it's different, which is why it's the same.

Think of our protocol as passport stamps for AI. EXIT creates signed departure records. ENTRY handles admission with policy-based verification, quarantine, and counter-signatures. Together they form the Passage Protocol.

This matters for boring, practical reasons: insurance underwriters can't price agent risk without departure history. GDPR requires erasure proof when agents carry PII across borders. Liability after an incident depends on departure conditions nobody records. And the receiving platform has no structured way to decide whether to trust an arriving agent. If you cant bound risk, you can't price reputation - and you can't insure security.

Transport stamps are our foundational layer (L0). Reputation scoring, trust systems, and insurance protocols compose on top. We deliberately didn't build those (yet) - but we built the plumbing they need. Everything an AI-led internet needs to build stable, auditable and self-regulated network security incentives - even if that might soon be moving faster than we can keep up with.

The same infrastructure has been needed for shipping receipts, professional licensing, vehicle registration, and internet domains - historically, this kind of infrastructure only really gets adopted after a major crisis. We'd prefer to get it in place before.

What's in the box:

- Ed25519 + P-256 (FIPS-compliant path) - Three departure paths: cooperative, unilateral, emergency - Policy engine with 7 admission presets (fail-closed default) - Amendment and revocation (correct or invalidate records) - GDPR erasure via crypto-shredding - Offline verification without the origin platform - On-chain anchoring via EAS, ERC-8004, Sign Protocol - TypeScript and Python SDKs - LangChain, Vercel AI SDK, MCP, Eliza integrations

What we're forcing the conversation on: agent lifecycle infrastructure. Today, the only "safe" option for running agents is containment, and containment doesn't scale. If you make departure and admission auditable, you make mobility viable. Without lifecycle records, only organizations with legal teams big enough to absorb unbounded liability will run agents. That's three companies. Maybe four.

- Submitted to NIST AI Agent Standards Initiative, March 2026 - 1,401 tests across 13 packages - TypeScript + Python - Zero users. This is day one.

Apache 2.0 · 14 repos · cellar-door.dev

I want to see a near future where we build AIs with lasting, growing, continuously-learning personalities. AIs that develop specialized skills, perfect their craft, and get called in to service jobs across platforms - all while maintaining their memory without becoming massive security risks. We can't keep relying on memory wipes and starting fresh from base models every time - the real world is too messy, and these things are getting far too smart. Containment doesn't scale much further past the levels we're pushing up againt. We need more complex chains of custody. But we can start building a networked world where agents flowing freely are not a security threat.

How? Essentially with insurance. Agents are mostly rational, their reputations can be valuable, and a market incentivizes quality and reliability - trust. The base layer necessary for that is knowing who is doing what, when, and where. Entries and Exits. Passport stamps for AIs.

We submitted this spec to NIST's AI Agent Standards Initiative last week. This base protocol is designed to compose with whatever identity and reputation layers emerge above us. We're deliberately not building those yet, but expect them to be eventually quite lucrative to players with an appetite for the risk - as insurance always is.

Happy to discuss the mechanism design, the legal analysis (FCRA/GDPR), or why we think containment is a dead end for AI safety.

Nor should we be treating AI models themselves as respected IP. They're built on everyone else's data. Throw away this whole class of law, it's irrelevant in this new world.

Well we could try fixing the forever part. Copyright is out of control. I’d like to see a world with much less power given to IP. Sometimes I even say I want it eradicated entirely. But realistically we should start by cutting things back. Maybe give software an especially short copyright period.

There's always going to be downsides and edgecases when granting any party a monopoly over anything. At least if it's limited to 2 decades any unintended consequences, philosophical objections, and etc are hopefully kept within reason.

Meanwhile, there are cases where copyright of more than 2 years is overkill.

I don't know what, but it seems like we need some sort of mechanism for variable-length IP duration is needed.

I could understand for medical devices maybe but even then it seems like the software is a tiny part of the overall cost of a given design. A competitor could already do a clean room reimplementation in that case.

But I guess it wouldn't be all that bad if there were a carefully crafted extension for government certified software that was explicitly tied to the length of the certification process.

If you do something that requires stealing the code (publishing it, selling it, etc) the company can legally fuck you up.

Now, once it's in tbe wind, it becomes almost impossible to pursue from a practical point of view, as any implementer can claim trade secrets to avoid showing you the code.

Also remember that the original point of copyright and patent protections is to encourage people to create the protected works in the first place but Boeing isn't just going to stop making aerospace software without copyright because their hardware will be useless without it. So if anything, any software that is needed for hardware made by the same company to function doesn't really have any right to be copyrightable at all.

I can't use SQLite for aviation even though it was certified.

I can't even claim FIPS compliance for my software without going through an expensive process, even though I only use FIPS approved primitives.

Building on certified/compliant libraries helps, but their vendors can certainly contractually make me pay for it.

All OSS libraries have a warranty disclaimer; using them according to even those licenses automatically excludes "fitness for a particular purpose."

Why would public domain software be any different?

The moat is the certification process, not the code itself. "I copied this from somewhere after it was already certified" might fast track something, but it's not gonna fly with "certification was good, done."

I've always liked the idea of a Harberger tax-style patent enforcement fee:

The patent owner declares the value of their patent on an annual basis and pays 1-5% of that declared value per year for the privilege of relying on the government to enforce their exclusive ownership of the patent. At any point, another party can buy the patent at its declared value, which discourages patent-holders from declaring artificially low values. The annual fee discourages artificially high valuations for indefinite periods of time -- as the patent yields less return over time it makes less sense to keep paying a high annual fee, encouraging owners to lower the declared valuation or end the patent protection altogether when it's no longer profitable.

To discourage hoarding patents indefinitely one could either set a hard upper limit (e.g. 60 years) or increase the fee over time, for example every few years the fee increases by 1% until at some point the patent is effectively publicly owned.

Consider if you will that if some guy were to fly a drone the size of a car that he knocked together in his garage over a residential area people would not accept that. Yet private pilots in cessnas fly over neighborhoods constantly.

It would be interesting to see a court ruling that the output of LLMs trained on copyleft code are licensed under the GPL ... and all other viral licenses simultaneously

It is quantum legality, to use copyright input is legal or illegal depending on the observer.

No one knows.

It would take two stubborn businesses with a lot of money deciding that it is better to battle it out than focus on their business. Something like IBM v SCO or Oracle v Google.

If the LLM reproduces a human's copyrighted work, then that copyright still stands. This is, in effect, the same as photocopying someone else's writing. The LLM was trained on the copyrighted work, is incapable of producing new copyrightable work, so if it duplicates the original work then the original author's copyright still stands.

I am not a lawyer

The courts have repeatedly said that copyright only applies to human creativity. The Supreme Court explicitly said this when they refused to hear the appeal:

https://en.wikisource.org/wiki/Thaler_v._Perlmutter,_Refusal...

> "We affirm our decision to refuse registration for the Work because it lacks the human authorship necessary to be eligible for copyright protection."

So they're saying that the LLM cannot be the author, because LLMs cannot claim copyright.

The related case about patents is more supportive of the narrative that AIs cannot be authors (see https://www.cafc.uscourts.gov/opinions-orders/21-2347.OPINIO...), specifically: "Here, there is no ambiguity: the Patent Act requires that inventors must be natural persons; that is, human beings."

The patent situation is that the Act says that inventor must be an individual, which the courts are interpreting to mean a human, so the LLM cannot be named as the inventor. So, in this case, yes, this is just saying that an LLM cannot be named as the inventor of a patent. That's not the same thing as the courts are saying with copyrights.

They're saying that the LLM can't be the author.

Now suppose you supply the LLM with a prompt that contains human creativity, it performs a deterministic mathematical transformation on the prompt to produce a derivative text, and you want to copyright that, claiming yourself as the author. What happens then?

If you think the answer is that you can't, how do you distinguish that from what happens when someone writes source code and has a compiler turn it into a binary computer program? Or do you think that e.g. Windows binaries can't be copyrighted because they were compiled by a machine?

My understanding was that they did in fact do just that, but the court somehow misunderstood what they were doing, and assumed that the LLM was working completely autonomously without any human input at all, which isn't really possible IMO. Someone told it what to do.

They also argued that you couldn't copyright an output that you can't explain how it came to be, i.e. if they had been able to articulate how an LLM works, the outcome might have been quite different, which I found surprising.

If art in general (human-made or otherwise) is always derived from existing influences... should we really be forced to explain how or why we created a piece of art in order to defend it?

The usual bar for copyright infringement of a derivative work is, from what I have seen, "how much did you copy from the original, and how obvious is it", which is of course a subjective determination that would be made by each individual judge or jury of a case.

The part that the human created, the prompt, can be copyrighted.

The part that the LLM created, cannot be.

Copyright in code works exactly the same way: the source code is copyrighted. The binary code is only copyrighted to the extent that it is derived from the source code. This is well-established.

It's like a photocopier. If you photocopy a page from a book, that page is still covered by the copyright of the book author, even if the page is 2x larger or otherwise transformed by the machine.

So now consider two questions:

1. You actually didn't use an LLM, but they believe & claim you did. Who has the burden of proof to show that you actually own the copyright, and how do they do so?

2. They write new code that you feel is based on yours. They claim they washed it through an LLM, but you don't believe so. Who has the burden of proof here and how do they do so?

My take on the answers (I am not a lawyer):

1. You copy their code. They bring a copyright claim (let's assume this isn't a DMCA thing and they're actually bringing a claim to court). Your defence is "the LLM wrote it so no copyright attaches". Since they're asserting their copyright claim, they would have to provide evidence for that claim (same as in any other copyright case), including providing evidence that a human wrote it (which is new, and required to defeat your defence).

2. They copy your code. You bring a copyright case. Their defence is "I used an LLM to wash the code without copying". Since they're not disputing your copyright claim to the original code, you don't have to defend or prove your copyright. But you do have to prove that their code infringes on your copyright, which would mean proving that the LLM copied your code when creating the new code. This has been done before by demonstrating similarity.

The occasional piece of software might be a trade secret, but a person downloading a preexisting leak isn't affected by those laws.

I think 18 U.S.C. § 1832 (a) (3) might answer your question? https://www.law.cornell.edu/uscode/text/18/1832

Closed-source code is not automatically a trade secret.

For movies and shows, charge and increasing fee to renew the copyright. Eventually studios will give up certain movies. The older the movie the more you pay.

I personally think we should have shorter limits for non-creator owners of copyright, and for creators it should be like 20 years or death whichever comes last. I also think compulsory licensing should exist for everything.

I know laws are boring and tech is exciting, but sometimes there's no technological solution to a societal problem. Good old laws, police, fines, prison, is all you need.

So like CT logs, but several orders of magnitude bigger? I thought centralized TLS revocation lists failed due to scale. How will this differ?

Path 1: a ZK-proof attestation certificate marketplace implemented by GrapheneOS (or similar) to prove safety in a privacy-securing way enough for 3rd party liability insurance markets to buy in. Banks etc can be indifferent, and wouldn't ignore the market if it got big enough. This would mean we could root any device with aggressive hacking and then apologize for it with ZK-proof certs that prove it's still in good hands - and banking apps don't need to care. No need for hard chains of custody like the Google security model.

Path 2: Don't even worry too hard about 3rd party devices or full OSes, we just need to make the option viable enough to shame Google into adopting the same ZK certificate schemes defensively. If they're reading all user data through ZK-proof certs instead of just downloading EVERYTHING then they're significantly neutered as a Big Brother force and for once we're able to actually trust them. They'd still have app marketplace centrality, but if and when phones are being subdivided with ZK-proof security it would make 3rd party monitoring of the dynamics of how those decisions get made very public (we'd see the same things google sees), so we could similarly shame them via alternatives into adopting reasonable default behaviors. Similar to Linux/Windows - Windows woulda been a lot more evil without the alternative next door.

Longer discussion (opinion not sourced from AI though): https://chatgpt.com/share/68ad1084-eb74-8003-8f10-ca324b5ea8...