What about a law the forces vendors to either provide security updates or publish the source code? That seems like a reasonable trade off between consumer rights and ip protection.

Why not both? There is no compromise needed here. Both things benefit the public interest which, after all, should be the author of the law (in a democratic country at least).

> Why not both? There is no compromise needed here.

You're assuming that it's actually feasible to keep old devices up to date for that long. It may well not be. It gets substantially harder to maintain old branches the further mainline has diverged from them. The original engineering team has typically long since moved on. The magnitude of the issue, here, can be on the scale of "we now need several times as many engineering teams".

This isn't a matter of "security updates would be better than no security updates". This may potentially be a matter of "security updates for four years is economically feasible, security updates for seven years isn't". (I'm not saying it is infeasible, just that it may well be.)

Thus a neat effect of such a law would be that SOC manufacturers would not purposefully break compatibility as much as they do now. Sounds like a win-win to me!

Or, much more likely, they'll continue building new hardware as they do now, and let the length of software support for old hardware in one particular market be a software problem for the vendors selling into that market.

Don't assume that attempting to solve a problem with a law can only have one possible outcome, and can't possibly have a different outcome instead.

Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. By the time the hardware actually ships, those changes don't work any more with the current Linux kernel.

Trying to make those work 2 years later is a huge effort -- probably worth less than just replacing the phones.

Mind you, I agree with you in principle, but I can see how in practice in might all go to shit.

If the code were open source, I'd be willing to bet quite a lot that this kind of code would get cleaned up and mainlined. Certainly for popular handsets from major manufacturers which probably account for the majority of handsets sold.

Thanks to the GPL this is already often the case (at least for the kernel). But vendor code is so abhorrent in quality, upstream efforts are few and far between.

I guess they gotta stop doing that then, huh? I don't see how consumers and society benefit from rushed, vulnerable crap software. Oh, right. Time to market. Race to the bottom. That's what we need more of.

Magic of compartmentalization of concerns.

It turns out that getting a bunch of programmers to do careful modifications to some C code base over a couple of months is more work than getting great many thousands of people across multiple companies to manufacture, distribute and sell new hardware to millions of customers.

> I guess they gotta stop doing that then, huh?

Why would they? They get paid to put out crap, so they'll continue doing it.

Bottle water continues to come in plastic bottles, even though glass if far cheaper/easier to reuse or recycle. Plastic bottles are literally trash, yet it'll continue being produced if people keep buying it.

Near-disposable phones (both hardware and software) won't stop being manufactured if they continue being in high demand.

> I don't see how consumers and society benefit

Actually, you do see. The price of your phone would be higher if Qualcomm had to hire competent engineers to make properly designed kernel changes for their hardware.

How much higher though? If you were to take the total extra expenditure on increased salaries for those engineers, and divide by the number of phones produced, the result is what? A dollar?

Sure, but when applying Marketing Math™, remember that all prices need to end in "49" or "99" to "sound cheaper" than the next incremental bump. So you'll end up with a device that is either $50 or (more likely) $100 more than otherwise.

Or they'll eat that $1 from their profit margins…eh, who am I kidding?

If they're rounding to the nearest $50, they're doing it based on the final cost. They're not going to base it on a what-if scenario of having a cheaper development team. So it's more or less a 2% chance of the price going up $50.

The price of your phone would be much lower if the software stack was truly Open Source, allowing distribution to remove clutter and spyware, and make older phones perfectly usable again.

Planned obsolescence is designed to increase TCO

> Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel.

SoC makers deliberately do this as a way to force phone manufacturers to buy new chips.

For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say?

Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible).

So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.

> and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible

Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.

Reversing engineering is hard. It would be nice if the kernel didn’t trash it’s ABI all the time for ideological reasons. Hopefully a new OS (fuscia) will fix this.

Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity.

I can see why Android was so popular with OEMs!

> Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity.

You can sometimes run 20 year old drivers, assuming same ISA and that none of the ABI has changed, which does in fact happen, just more rarely. Windows 10 is certainly not compatible with 100% of drivers from Windows 7, let alone XP (20 years ago is 2001, so Windows 2000 is actually likely).

I think this is much more reasonable as well, for many kinds of devices. Either give people the ability to update the device themselves, or you have to supply updates. (I think 7 years is a bit much, but the duration is a quibble over a minor detail rather than a fundamental principle.)

>In my view, one other feasible good step would be to require companies to publish the source code of their phones

That is definitely not feasible. Vendors are very protective of their code. eg. https://github.com/github/dmca/blob/master/2019/08/2019-08-0...

Vendors can be as protective as they want, they can't go against the law of the land.

The point is that there will be a lot of pushback from vendors. Meanwhile I doubt even 5% of the electorate actually cares about this. For that reason I don't think it's really "feasible".

>Meanwhile I doubt even 5% of the electorate actually cares about this. //

Representational democracy is supposed to work around the problem of an uninformed electorate. The question should be "if a member of the electorate understood this situation well enough would they care", representatives are supposed to use subject experts to help them answer that question and then use their political expertise to implement laws that move us towards a solution.

It's a big ask, and it doesn't work that well -- politicians often work at what will win them plaudits in the press (or what can be presented as a win, if they control the press), rather than actually doing their job.

Fundamentally though "the electorate doesn't care" is the wrong measure, there are a million things the electorate don't care about but would care about if they had the situation presented to them fully ... we pay representatives and advisors so we don't have to care directly ... that's supposed to be how it works.

If the EU will also be happy to pay 100s of billions in IP reparations to the US and Asian countries affected then I’m sure the law will big fine :)

The law only works if it makes sense. Aggressive and borderline punitive laws where IP is forced open will not be followed.

You could just give vendors the option:

- Release all code necessary for independent developers to provide updates.

- Release updates for 7 years yourself.

Then they can decide what is cheaper for them.

This is not just feasible, there is a device like this: https://puri.sm/products/librem-5.

requing operators to allow phone owners to update all OpenSource code, which is probably the majority of the Internet/network facing code in ios and android, could be doable.

They are. But perhaps there is little reason for them to be.

Especially if everyone else wanting to play needs to open up as well.

I would prefer if instead smartphone makers were at least forced to add a tool so users could wipe the memory and install a free bootloader.

And would be great if they had to also provide a free OS, like postmarketos, lineage, Debian or something like that. It could be very rudimentary without a GUI, just drivers for GPS and Wifi. And they would not have to provide even security updates for that. So I would think that many companies would also prefer that.

I think that would be the ideal scenario.