But that's Qualcomm, isn't it? Qualcomm is anything but the open source company.
Enough end users are developers that they can make things for other end users who are merely "power users". This is how custom firmware works in practice on most devices. Sure, many many users won't care or know at all.
However, many innovations on Android started out as a root or custom rom exclusive rom, before Google decided to take the idea and make it official (with their own implementation generally). Access to code fosters innovation. Examples from Android include: night light, revokable app permissions, gesture navigation (instead of on screen buttons). There was also plenty of features that first showed up in vendor firmware of course (like one handed mode on Samsung phones).
So I don't consider the scenario valid. Everyone benefits from the end user being able to tinker with their devices, and copy left licenses is a way to apply pressure in that direction. Sure, you may not benefit directly, but you do benefit indirectly.
This is unfortunately true for GPLv2, but GPLv3 forbids lock down. As such I believe GPLv3 is vastly preferable.
This will not prevent proprietary binaries of course, but it does prevent the case where you can't update the firmware because it needs to be signed.
Voiding the warranty is fine (if a bit petty). Reverse engineering is legal (in many jurisdictions), though you need to take care with how it is done.
Qualcom only bought Aruduino recently (last month, but sure there were likely negotiations for quite a while before that), but they were successful for many years. So we really haven't seen the results of Qualcom yet. As such that point is irrelevant.
A better counter argument would be that Aruduino sell hardware, the software is there to support the hardware. So the software was never their primary income. However the counter to that is that the hardware is also open (schematics etc), yet many people prefer to buy rather than spin their own boards.
Stallman wrote a little bit more about the subject directly linked to OP at this brief section here.
For example, one paragraph says:
A special issue arises when a license requires changing the name by which the program will be invoked from other programs. That effectively hampers you from releasing your changed version so that it can replace the original when invoked by those other programs. This sort of requirement is acceptable only if there's a suitable aliasing facility that allows you to specify the original program's name as an alias for the modified version.
PS: although I think FSF does consider Rust free software. They list it in their directory and use it. I was curious about Stallman's analysis.
I think he is just being cautious.
Which bring us to the next argument: cheap quality hardware can be sold without any software at all, see Raspberry Pi: sure they rely on free and non-free software but they don't produce any software themselves and are doing just fine.
It's relevant in a sense that Qualcomm haven't bough Arduino for software, Qualcomm bought it for the community that's centered around hardware.
But yeah, I guess if you sell hardware and offer software for free that may workā¦ why, IBM pioneered that approach 70+ years ago!
If you want to ensure that end user wouldn't get your software on a device then yes, GPLv3 achieves that nicely. But are you sure ensuring that user wouldn't use your code, but would use someone's else code is good allocation of resources?
No, it doesn't prevent that at all. In the wast majority of cases of GPLv3-based software is used at all it's put in a jail where it may be updated without touching anything else, thus firmware as whole is still not updateable.
What I'm saying is that it doesn't depend on the licence so much as what the product vendor decides to make public. The Nikon example illustrates that: it uses Linux, which is under GPL, yet the end user has no freedom at all because the camera can't work without other essential elements, which are not public. More explicitly, the user can recompile the OS part and even modify its sources, but it's not possible for them to load a new firmware into the camera.
Also, if those other proprietary elements like the compression and image processing algorithms were public, Nikon would have a hard time competing with other manufacturers like Canon, Sony, and so on. As users, we benefit from the competition itself: vendors strife to create products with an edge over other similar products. It would not be possible if all the code was always public since the competition would then focus on other things, like the service (which might in fact be the only added value left).
I'm not considering here the open-source licences, since we're opposing them to the "free" GPL (cfr. the article you gave in your first post).
I'm replying to your argument that "MIT, BSD and Apache all maximise the freedom of the developers. While GPL tries to protect the freedom of the end user over that of the developer."
Since I'm opposing GPL to the open-source licences in general, that excludes the developers. You can't have it both ways. 
For the developers, I don't think GPL maximizes the freedom since it forces them to release the modified code. But I think the argument I made in my post just above about Nikon applies to power users, too.
I agree that there are cases like Linux where everyone benefits from the sources being in the open. But only if they can modify the sources, compile them, and use the result in the product (see again my example about Nikon). It's also necessary to have enough momentum in the community to produce something useful and with an acceptable delay; Linux is an example that works well, but not all areas have enough volunteers or the necessary skills to make it viable. Volunteers normally work on open-source projects as a hobby and can't afford to spend as much time as employees do. "Employees" means a company that needs to make a profit, which is hard if your know-how is public (i.e. if your source code is entirely public).
Android is another case that works well, as you said. And it's based on Linux.
PS: And no, voiding the warranty isn't fine at all when you're taking the user's point of view. Those products can be very expensive and sometimes require servicing. 
We would be discussing forever. This is a matter of values. I value freedom more than the practical benefits. Perceived quality comes second if it is not free software for me. That is what free software stands for.
You think it does not, I disagree, but it is deeply intertwined with each persons worldview and values. So won't extend a subjective discussion. I hope that is okay.
2 Likes
I didn't know; that's interesting.
What I had in mind in my example was the binaries and the packaging. I don't know if there's any validation of the firmware by signature or otherwise.
The source code of the modified OS is available, but there's no instructions on how to assemble the compiled result with what makes up the firmware. AFAIK, exactly what's in the firmware isn't public, either. I don't know if that's something that can be prevented by GPLv3.
It's quite a complex problem, especially if you consider security. To continue with the example of those cameras, they now include a secret key used to sign the photographs, so that the user can prove their authenticity (using C2PA). How would you reconcile that in an entirely "free" and open context? I could start exploring scenarios, but the conclusion is likely that Nikon would have had to anticipate that feature from the beginning by adding a special key exchange protocol in the ROM that would ultimately allow the C2PA to work only for original firmware, if that's even compatible with GPL.
I rather think it depends on the case, so I'm not 100 % against, but I understand and respect your point of view about the freedom angle. It's probably debatable as well, as everything, but as you said, we could go on forever.
GPLv3 requires instructions detailed enough to use upgraded version. In practice that means that GPLv3 component is carefully isolated and curated so it couldn't go out of jail.
The same way it's done to Linux on Windows: ensure that GPLv3 component is never on the critical path and can not affect anything security-sensitive.
GPLv3 GCC may be replaced as per license, it just could never touch camera or video or anything else. Problem solved.
Of course no one would have accepted GPLv3 kernel, but that's moot point, as I have said FSF couldn't even risk relicensing glibc, and it's much easier to replace than kernel (Android, novadays, includes field-upgradeable libc ā for security reason, not to comply with GPLv3).
Voiding warranty can be fine for a tinkerer. And if you want to fix, repair or prolong the life of a product after the company has stopped supporting it access to fixing it is critical. This applies not just to the hardware itself (right to repair: schematics, service manuals etc) but to the software so that the product can be used securely after the company stops releasing security patches. Or at all if it is tied to a cloud server.
Every couple of months I read about some product or other being bricked because the cloud serves shut down. I think companies should be mandated by law to make the products no longer depend on the cloud if they do that. But failing that, if you can change the firmware an enterprising individual could make them work on their own.
I was not precise enough in my wording.
- MIT etc maximises the freedom of the developers at the company (or in practise their bosses).
- GPL etc maximises the freedom of the developer who buys that product.
There are developers in both groups.
One thing that happens is where you extract and reuse the binary blobs and rebuild the open parts to add whatever new things you want there. This at least used to be common for custom Android roms for things like camera drivers. So it isn't black and white about if it can be modified or not.
The details of the process varies, sometimes binary blobs are extracted from the old ROM during install (to be careful about redistributing the files).
Speaking of cameras: some do have custom firmware. Cannon DSLR cameras in particular can use the CHDK firmware to add additional features. I don't have one so I have never looked into exactly what it brings.
That sounds like an anti-feature to me. I would absolutely want that gone if I had such a camera. Besides: you often do want to edit the photo anyway, if nothing else to crop, adjust black level and curves etc. That is the whole point of raw photos for example. Which will presumably loose the signature? So it seems like a pretty useless feature to me.
The bigger issue with changing a free or open source license is, as I understand it, that all contributions are still under the copyright of their original contributors (at least in any license I've seen), so you can't change the license without permission from every contributor. That said, you can, and people have, changed the license new contributions are accepted under.
2 Likes
Hm, yeah. I think the rust trademark policy ought to explicitly allow naming distributed binaries the same name as the official ones.
It already does ā which is precisely what prompts an RMS's ire. Because it lists a [pretty reasonable, in my opinion] things that you have to do to still continue to call Rust, wellā¦ Rust ā and that's āfreedom restrictionā, according to RMS.
1 Like
I mean that it should be unconditionally allowed and not affect whether the program is considered to be claiming to be rust. although arguably filenames are functional enough that they ought to be exempt from trademarking anyway
Oh yes, in that sense I agree. I've done my share of it, though it's not for everyone.
It's very much a feature in demand; professional photographers need it and received the update very well (well, except there was a flaw at first).
Because of fake photos, especially since generative AI, more and more publishers ask for a way to verify the sources and how the photos were transformed in the editing chain (so it's mainly the raw that's verified). You can see relatively large before/after thumbnails, so you don't have to fear anything if you're just colour grading or cropping your media. But if you start masking parts or embellishing someone's face, everyone is able to see it by clicking on the C2PA link and might reject your work. Same for competitions.
It's entirely optional. I haven't enabled it because it's just a hobby for me.
It's just one example; I'm sure there are others with an interest to preserve the software's integrity and secrets: smart cards, DRM, libraries under licence, ...
The confidentiality of the keys stored on the smart card is what matters in the end, not the integrity of the software running on the smart card. A smart card where you can change the software but in the process wipe all keys would be in theory be perfectly safe. In practice it could make it easier to attack the physical hardware, but even then the software integrity is not what actually matters for smart cards, it is just a means to an end.
User freedom restricting anti-feature
Why would anyone reasonably[1] care that a user is able to change such libraries? At most they should care about their library not getting copied without permission.
Yes I acknowledge there are companies who care about users not modifying their stuff. I don't think they are reasonable except in the narrow case where such modification can reasonably endanger someones life, like when modifying a car MCU where you can cause the breaks to no longer function for example. ā©ļø
1 Like
I said the software's integrity and secrets. Here, "the secrets" are the keys, but it's important to protect both together; e.g. to forbid changing the software while keeping the keys. So you're right, if the software can't be updated without erasing all the keys, it's fine. The smartcard loses its initial purpose, but it can be used for something else. Maybe it wasn't a good example in this scope.
The DRM protects an asset, which makes it possible to share the asset under controlled conditions. Without that, the author or the publisher might decide not to share it that way or ask for a completely different price.
As for the libraries under licence, it's similar: the vendor signed a contract stating precisely under which conditions the library is used. So it's important that the software cannot be modified to use the library differently. A typical example is the codecs used in imaging software.
But how would firmware for such a smart card be updated? Someone is supposed to process these secrete, etcā¦ it's incredibly stupid to make that part 100% unfixable ā but if you permit upgradesā¦ oops, that hardware is no longer respects your freedom.
After FSF proudly declared, dozen of years ago that the proper way to make thing āmore freeā is to increase liability for the maker of hardware and, simultaneously, make life of the user more problematicā¦ I think they lost most followers. Because that's precisely āredoubling your efforts when you have forgotten your aimā.
At this point it's not an effort to improve anything at all, but more of a quasi-religionā¦
Trademarks:
I read it as saying that if I fork rustc and modify it to my tastes (say make use of UNIX file IO in the standard library - non-blocking file handles say) I cannot then call it "Rust", because "Rust" is a trademark.
IANAL, so I could be way off base - but if I am right I do not see what RMS is complaining about. Usually I am very comfortable with RMS' statements, I do not always agree as I am much more pragmatic, but I very much appreciate him.