It's only a trade secret as long as the company takes reasonable steps to protect it, and as long as what is being protected is a reasonable thing. Even if the code is legitimately a trade secret, if an employee publicly says "That code looks to me almost exactly like this GPL software" then (assuming the employee is correct) any court would take a dim view of a court case against the employee, because stealing shit is against public policy.

> This is doubly stupid because

No, that part really isn't. Trade secrets are about general business stuff, and as long as the company isn't asking you to help them hide evidence of malfeasance, they can ask you to keep any stupid shit secret.

That notion only applies to patents and trademarks, and it seems highly unlikely that it would ever directly apply to copyright.

It may seem like the notion applies to copyrights, but it really doesn't. Independent creation is, and has always been, a solid defense to claims of copyright infringement.

That is why, when Phoenix Technologies reverse-engineered the IBM PC BIOS, they had two teams -- a team that took apart the original and documented the functional features (which have never been copyrightable) and a second team which took the description of the functional features and wrote new code.

The issue with songwriters has always been that, for civil laws, it's hard to prove a negative. How can you prove you never heard that song? Especially when it got a lot of radio airtime.

Now, how do you prove that your AI didn't ingest copyrighted code and then regurgitate it. Obviously, you can't.

> if AI is the instrument of that invention's demise, then I look forward to it.

Any court ruling that you would find beneficial for code copyright would mean that a human could have two windows open on their computer and cut and paste from one to the other and claim independent invention. That seems unlikely to be a good result, and also seems unlikely to come to pass.

The US recognizes exactly 3 types of intellectual property: copyrights, patents, and trademarks.

There are also, of course, trade secrets, but if you didn't surreptitiously gain access to the information and didn't sign any NDA, that's not something you have to worry about.

> as always, nuanced discussion will get lost in clickbaity headlines

Well, yeah, but if a human didn't use enough skill and judgment in creating something, the article is right. He won't be able to copyright it or patent it, although he could conceivably keep it secret.

Someone else!

All they have to do is show it's close enough to code that was swallowed during training.

Songwriters have been successfully sued for many decades for creating songs that are too close to songs that they probably heard.

Once this line of reasoning gets applied to code, all hell will break loose.

The first issue is on the purely physical level. The fabs (and integrated companies like Intel) fight this one out, and eye each others' patent stacks and maybe exchange a bit of money. This is not something the average Joe can worry about; nobody has the money to build the fab or engage in the chemical and materials research.

The second issue and implication is on the logic and circuitry level. The average Joe is not going to be able to design and test something really big and performant, but many companies (not just Intel, AMD, and ARM) are capable of this, and again, money might change hands, but (aside from things like China) absolute shutting down of competitors is not really going to happen.

So big players will dominate the highest performance market, but at least there are probably a dozen or so of them, so that will provide some pressure on its own.

Lower performance chips (some of which will be more than performant enough for many niches) will probably proliferate. The profit margin on these chips will be cutthroat, because the average Joe can design them, and then needs to negotiate with, e.g. TSMC, to actually build the damn things.

And a lot of innovation will happen in these lower-level chips as well. Expect many startups to be bought by the bigger players to enhance their own patent portfolios. And expect that their competitive prices will also drive down the cost of the most performant chips a bit.

The performance chip companies will have interesting choices to make. Lower the price to knock out the competition below? Or raise the price? If they raise the price too much, their available market will shrink, and then they'll need to raise the price even more.

But there are now several RISC-V IP vendors, and ARM can't possibly shut them all down, and companies can develop IP in-house, so there are lots of different designs already out there.

So, at this point, developing a RISC-V processor provides a certain amount of safety in numbers, kind of like swimming in a school of fish, while developing an ARM compatible processor paints a target on your back.

Developing a low-end x86 processor wouldn't attract any legal attention either, but now that the RISC-V ecosystem is big enough, why bother? Decoding all those instructions might be a lot of extra work for no real market share gain.

Developing a high-end x86 processor would probably attract careful scrutiny of exactly how you managed to get that performance and whether you violated any patents to do that. Again, that the same sort of patent scrutiny would happen with bleeding edge RISC-V, but certainly, a fast x86 processor would be higher on the priority list of the Intel and AMD legal departments.

The Republicans are trying to strangle the IRS and outsource everything.

The IRS, despite its many shortcomings, consistently tries to help people get their taxes filed.

So when the Republicans were in charge, and the IRS wanted to ensure that people could just fill out their forms, but the Republicans in congress wouldn't directly support filing through the IRS, the IRS came up with a workaround. It was a workaround both for them and for Turbotax et al, because it sort of acted like a pressure relief valve.

The workaround allowed people to file their taxes for free, so the IRS was, well maybe not happy, but certainly mollified. The workaround kinda sucked for the taxpayer experience, so Turbotax was happy. And the workaround was implemented by private companies rather than the US government, so the Republicans were happy.

But you definitely have to hand your data over to a third party to use this workaround -- effectively the same evil (cough, Turbotax, cough) party you were trying to avoid in the first place.

When the democrats were in charge, they effectively torpedoed the workaround with DirectFile, so of course when the Republicans got back in charge, they had to axe that.

By the way, you mentioned an API. Free file fillable forms does not have one. The only one I know of is the one that the tax program vendors use. Yes, it is publicly documented, but to use it you have to jump through a lot of regulatory hoops.

The site that was killed was the IRS direct file site.

The webform is through the free file alliance, aka Turbotax and friends.

The API requires you to jump through a million hoops. Heaven help you if the reason you want to use the API is because you are behind on your taxes, because that will signal that you are not of good character.

Speaking of being behind on your taxes, you have to use paper for any but the last three years of returns anyway.

Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal.

So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued.

Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code.

Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you.

For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs.

ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive.

Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing."

At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago.

You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.

Because if the government is going to accept returns electronically instead of through the physical mail, then it should accept them without requiring an intermediary.

Interestingly, it does this for corporations, but not for individuals.

Gee, I wonder why.

Personally, I think that (a) the government needs to have my PII to process my taxes, and that (b) having the government require me to also hand my PII to a third party in order to pay taxes is a big fucking security nightmare.

Sure there are. If you want to do weird and wacky stuff, try to do it with an ARM and see how fast you get shut down.

> The improvement is entirely "we don't have to pay ARM"

No, it's "we don't have to beg and grovel, or pay ARM."

Well, they don't and they do. Linux runs on everything from an $8 generic IP camera to the world's fastest supercomputers.

RISC-V is attempting to achieve the same feat in hardware, so there will be many implementations at many price points.

As with any of the T-shirts that list 3 things and say "Pick two" it's always difficult to reduce cost, increase speed, and decrease code size.

But...

You can pick two.

So if you don't mind spending the money for things like fancy micro-op caches, you don't care about the compressed decode, and you can still make it run like a bat out of hell with compressed instructions.

Or if you don't mind lower performance, you don't worry about fusing operations, and the pipeline implications aren't so bad, so you can still make something cheap that works with compressed instructions.

It's only when you're trying to pick all 3 (compressed instructions, high instruction throughput, and low cost) that the difficulty of decompressing the instructions becomes problematic.

Or look at it this way. x86 decode is infinitely more complicated than RISC-V decode, and still occupies maybe 2% of the die area.

Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.

What you find may or may not match reality. In this instance, I don't believe it does.

> We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them.

This, of course, is a silly argument. Yet, it is completely orthogonal to the one I was making, and is 180 degrees away from the complaints leveled at Risc-V which are that it is an overly simplistic, nay childish, specification, written in crayon by kindergartners.

> The issue is that «the vendors» are not a single mythical intelligence or force possessed of infinite technical wisdom, unlimited, cosmic scale engineering resources and an relentless desire to right the wrongs.

I find this statement accurate, yet condescending. Who the fuck thinks that they are? Claiming that this is an "issue" with my statement appears to be a reductive argument that I have not thought it through. To be blunt, this statement reveals a hell of a lot more about your ignorance on this issue than mine.

> It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.

And yet, we have seen this play out in x86, with Intel v. AMD, and it worked exceptionally well.

> An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.

Of course, AMD and Intel were always trying to one-up each other, but that is tempered by the necessity for their improvements to be supported by compilers. By the time an improvement is well-supported, the other side has caught up.

With Risc-V this is even more likely to be the case, because proprietary extensions will simply not be that well supported by major compiler vendors, who have a hard enough time keeping up with the ratified ones.

There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons.

And, as others have mentioned, the ISA doesn't really matter. As long as it's agreed upon, then the CPU vendors can optimize on one side, and the compiler writers on the other side.

Sure, Risc-V has its warts, but you can certainly say the same about all the rest.

Exactly.

> It satisfies my two requirements for an ISA as a hobby CPU designer...

You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code."

Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.

Compression requires prediction.

The better the prediction, the better the compression, whether you are measuring fidelity or result size.

This doesn't mean that compression is prediction.

In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large community consensus building mechanism.

> The key definitional question is the license, not any of the cultural stuff.

For direct modification, certainly. For customization, maybe. For ignored issues like the parent to my original comment was bemoaning? Maybe LLMs are good enough that we are almost ready to say "Make me a custom version of Photoshop" and then it doesn't matter.