This project is suspicious [LWN.net]

This project is suspicious

Posted Dec 6, 2024 13:05 UTC (Fri) by mwelchuk (subscriber, #85200)
In reply to: This project is suspicious by coriordan
Parent article: Apertis v2024 released

> If they're working on a system to help people avoid contributing to free software projects, and they say it's for regulatory compliance, then it's difficult to also claim that they have no opinion on whether it's really necessary for said regulatory compliance.

Both rust-coreutils and rust-findutils are existing MIT licensed projects. I'm not aware of any alternative implementations of components being used that aren't licensed under a FOSS license.

> It's a project whose most obvious purpose is to weaken our ecosystem. They're doing what Apple and Google do when they want to sell free software while also blocking the use of those freedoms. If Apertis might spread this model then we should hope Apertis fails.

That is not the purpose. The purpose is as stated, "to increase the adoption of modern, maintained OSS solutions in markets where this has historically been a challenge".

> GPLv3 was specifically drafted to allow medical devices to be locked down. The tivoisation clause is only for consumer products and smart home systems.

Apertis targets consumer products, like cars. Where in many jurisdictions there are regulatory constraints ,which many (including lawyers in the automotive world) would argue such clauses would be problematic.

(For transparency: I have worked on the Apertis project.)

to post comments

This project is suspicious

Posted Dec 6, 2024 14:58 UTC (Fri) by coriordan (guest, #7544) [Link] (3 responses)

> I'm not aware of any alternative implementations of components being used that aren't licensed under a FOSS license.

They're all FOSS, yes, but Apertis didn't say "Hey, rust-coreutils is memory safety!" Instead, it seems they're saying, "Hey, here's a GNU/Linux system that we've modified such that you don't have GPLv3's requirements to ensure the users can modify that software!" The choice of package seems to be motivated by weakening obligations for companies to contribute back or to avoid that their customers get the intended freedoms.

> The purpose is as stated

They say they're removing GPLv3 as a means to solve a problem, but the problem is barely described. And when the solution is so harmful, a bit of justification should be expected.

> Apertis targets consumer products, like cars.

Cars, like medical devices, are (IIRC) not in the "consumer products" definition ("any tangible personal property which is normally used for personal, family, or household purposes"). I don't remember the details, it was many ago that I last looked into that. There are probably some good docs available. The GPL FAQ gives just two examples of consumer products: portable music players and digital video recorders.

This project is suspicious

Posted Dec 6, 2024 16:49 UTC (Fri) by mwelchuk (subscriber, #85200) [Link]

> They're all FOSS, yes, but Apertis didn't say "Hey, rust-coreutils is memory safety!" Instead, it seems they're saying, "Hey, here's a GNU/Linux system that we've modified such that you don't have GPLv3's requirements to ensure the users can modify that software!" The choice of package seems to be motivated by weakening obligations for companies to contribute back or to avoid that their customers get the intended freedoms.

One of the selling points for Apertis is it's ability to be used in places where the GPLv3 would be problematic. The fact that rust-coreutils and other such packages are written in a memory safe language was definitely seen as a positive, however it's not the main focus of Apertis.

Collabora is a consultancy. We strongly believe in open source and work with a number of large companies, promoting and helping them to make use of open source, including frequently submitting improvements upstream. For instance, if you look back at the development statistics for previous kernels on this site, you will see Collabora come up in the most active list from time to time. This is a result of the work we do with our clients.

We will make pragmatic choices (as we have in the case of package selection in Apertis) to enable our clients to use open source, whilst ensuring that we honour the licensing terms for the projects that we choose / are able to use in the given circumstances.

> They say they're removing GPLv3 as a means to solve a problem, but the problem is barely described. And when the solution is so harmful, a bit of justification should be expected.

The problem is that clauses, such as the anti-tivoization clause in the GPLv3, make it impossible for a company looking to ship a consumer focused device, specifically one that needs to comply with strict regulations (typically requiring the manufacturer to ensure that unsanctioned changes can't be made to the software), to use software under that license. This is not a new issue, it's been known about since before the GPLv3 was finalised and is why the Linux kernel still ships under the GPLv2 license.

We're honouring the licensing terms as chosen by the projects involved. As a result the freedoms of each projects users are being maintained as requested by their authors. I agree, there are projects that grant more freedoms to their users, however for the reason described above we avoid using those projects so as not to violate the freedoms they wish to provide their users. There is a pragmatic balance that sometimes needs to be made here in certain circumstances.

In using a Linux based OS on a device, there are still large portions of that OS that are licensed in a way that require source to be shared, but do not require the device to be modifiable. For example kernel support where, unlike a mature low level utility, there is likely to be some support added (and such support is typically upstreamed as we prefer to avoid heavily modified downstream vendor kernels or carrying out-of-mainline patches in Apertis), which can broadly benefit the FOSS community in providing improved access to support for the SoC, functionality in SoCs using similar/identical IP cores or other ancillary components that may well be used in other devices. A common alternative is a proprietary OS such as VxWorks or QNX is used instead, where no such advantage for the FOSS community exists.

> Cars, like medical devices, are (IIRC) not in the "consumer products" definition ("any tangible personal property which is normally used for personal, family, or household purposes"). I don't remember the details, it was many ago that I last looked into that. There are probably some good docs available. The GPL FAQ gives just two examples of consumer products: portable music players and digital video recorders.

I don't know what to say. I personally own a car that's used for personal, family, and household purposes. They're classed as consumer goods, hence the issue.

This project is suspicious

Posted Dec 8, 2024 19:09 UTC (Sun) by sammythesnake (guest, #17693) [Link]

> Cars, like medical devices, are (IIRC) not in the "consumer products" definition ("any tangible personal property which is normally used for personal, family, or household purposes")

I'm a little confused how you think that definition doesn't cover cars. It sure as hell includes *my* car! Even my van, which is *mostly* used for business purposes is also used for daily domestic stuff...

This project is suspicious

Posted Dec 8, 2024 19:29 UTC (Sun) by Wol (subscriber, #4433) [Link]

> They say they're removing GPLv3 as a means to solve a problem, but the problem is barely described. And when the solution is so harmful, a bit of justification should be expected.

I think the problem is extremely obvious. It's called a "lost opportunity". As in "if we don't do this we will get locked out of the market".

And while the GPL fanatics don't seem to care about whether FLOSS is actually used or not, so long as they can live in their digital cave, some of us would actually like to see FLOSS make a difference in the real world. I'm actually rather gutted that my company would rather pay for OpenQM, than use the GPL2 ScarletDME.

If I write NEW code for Scarlet, I'll almost certainly MPL it, with the *deliberate* intention that the owners of OpenQM can incorporate it. I don't particularly like the idea, but imho the alternative is worse.

Cheers,
Wol