This topic seems to be similar to the question of using updated bluetooth firmware in place of the one provided on rom. There’s been an answer by @nicole.faerber on this thread:
But we didn’t follow up the topic to the point that Purism and FSF came to a position.
I’d be really interested in the outcome…
The actual text of the RYF certification requirements says that it can’t be intended by the device manufacturer for the final owner to update the firmware. An important note is that the RYF certification predates the modern all-in-one SOCs for phones, and was aimed more at laptops than at phones. The primary “black box” device with firmware stored in a second place and not using the CPU would be the hard drives, or the fairly sophisticated firmware in a blu-ray drive. The expectation, as set forth in the RYF text, is that the whole, integrated, device (the laptop, phone, et cetera) will work to specification at time of release without the user having to directly deal with closed source firmware.
The rational is that the particular bit pattern which constitutes the firmware is relatively fixed, and so is essentially hardware. Of course, just like the company need not glue the case shut to prevent the end user from using a shunt-mod to overclock the GPU, they similarly don’t have to clip off the JTAG pins to prevent the user from rearranging those bits however they like. They just must not expect the user to do so (or have software on the machine to do it for the user automatically) in order to have a correctly functioning machine.
Of course, that’s just what the RYF text says, I can’t speak to what the current leadership of the FSF or Purism will claim, which is what’s going to actually matter here.
Oh, as for the “at time of release”, just like if it were discovered the wrong resistor was used in a current sensing circuit, a flaw discovered in the firmware wouldn’t invalidate the RYF certification. The RYF certification would, however, require Purism to treat it as a hardware bug, which means offering RMAs to anyone who wants to ship it back for Purism to do the firmware update, same as if there were some other hardware defect. Just like hardware defects though, they could offer the option of doing the “repair” yourself, without voiding your warranty.
Last time this was discussed I never got around to posting a response on here but I wanted to say then that I believe it should be the choice of the user whether to update proprietary firmware or not. That is a user freedom, and freedom is what brought me here and to Linux in general. Restricting the end user from that choice is the opposite of freedom. I’m curious, is everyone here in agreement that it should be updatable by the user?
But as @kieran pointed out the modem could potentially update itself, so it’s not like fixed offline hardware.
Right, the user shouldn’t have to update firmware but I would hope and believe it should be that the device does facilitate it. Updates obviously couldn’t be included in the RYF operating system but it shouldn’t prevent it and shouldn’t require specialised hardware to do so. That’s how I think it should be.
Exactly, these are excellent reasons it should provide that possibility.
The question is what did the FSF mean when it wrote: “software installation is not intended after the user obtains the product”?
As I said in my reddit post, “not intended” is different than “not allowed”, and it is unclear what the FSF meant by “not intended”:
I don’t think the FSF is prohibiting that the firmware ever be upgraded in the Broadmobi BM818 or Redpine Signals RS9116 on the Librem 5. The FSF explicitly says that its exception covers the “firmware built into an I/O device.” The FSF knows that firmware for I/O devices can be upgraded, but most users don’t upgrade them. The intention of the manufacturer is that the firmware doesn’t need to be upgraded after sale in order for the device to function, but something unexpected like a security hole or a bug may be discovered in the future that wasn’t intended.
I suspect that the FSF put this language about “software installation is not intended” to prevent manufacturers from trying to exploit the exception for secondary embedded processors. For example, a manufacturer could add a secondary processor that runs Android with proprietary apps and then try to get RYF certification for the device. The FSF only wants its exception to be used for low-level stuff like firmware, but there is no good way to draw a clear line between an Android app and low-level code, so FSF says that this is code that isn’t intended to be installed after sale.
Maybe I’m wrong in my interpretation of the text, but it seems to me that the FSF was being purposely ambiguous by using the words “not intended”. It didn’t want to say “not allowed” and it didn’t want to say that it endorses proprietary firmware updates, so it used vague language in the middle that gives it some wiggle room. It doesn’t want users to be installing proprietary software on a RYF device, but it has to recognize that proprietary firmware updates are necessary in the real world.
If there were any modern WiFi/Bluetooth, cellular modems and GNSS devices with free/open source firmware, then the FSF can draw a hard line between software and hardware, but there aren’t any and there probably never will be any due to the patent situation, which makes every manufacturer try to hide its implementation details to avoid patent lawsuits. If the FSF tries to draw a hard line, all it does is punish companies that are trying to live up to its ideals, and the few companies that care about free software will throw up their hands and conclude that there is no point in working with the FSF.
One of the reasons why I preordered the Librem 5, and not the PinePhone, is precisely because I believe in free software and I want to support a company that collaborates with the FSF to spread its ideals. It makes me irate that people are now using the RYF certification as a reason to publicly criticize the security of the Librem 5.
The other thing that annoys me is that if the FSF clarifies that proprietary firmware updates are allowed on RYF devices, the critics will say that the FSF isn’t holding to its ideals and the organization is going downhill now that Richard Stallman is gone. In the real world, not allowing proprietary firmware updates does nothing to advance software freedom or user rights. If RYF doesn’t allow proprietary firmware updates, it doesn’t make it any more likely that we will get free firmware for wireless devices in the future, but it does mean that makers of devices with wireless communications will never try to get RYF certification in the future, and companies working with the FSF for RYF certification has real value in promoting software freedom in the world.
Why not?
At least in theory, if proprietary firmware updates were forbidden, that would create a stronger incentive for someone to create a wireless device with FLOSS firmware. I guess your point is that this will not happen in practice, but why exactly is that?
Because, at present at least, in the US and allied countries, you legally cannot create an open source firmware for cellular devices. At least, not without facing the high probability of having to fend off multiple lawsuits from patent trolls.
It would create a marginally stronger incentive for an open implementation, but at significantly increased cost and risk. That’s not a winning situation. Instead, it would likely lead to the FSF certification being meaningless, as the list of devices with it would remain 0. Note that, to the best of my knowledge, there isn’t a single device on their certified list which doesn’t use closed source firmware. Again, disk controllers count, and are pretty much all closed.
It would be a very difficult task to create free/open firmware for a wireless device without the manufacturer providing information how the device works. You can’t figure it out by watching the input and output, and they don’t provide memory dumps so you can’t watch what changes when you send in a particular command. Most of the wireless chips don’t even publish their data sheets, application notes or reference designs and you can only get that info if you sign an NDA.
If a manufacturer decided to provide details about how its wireless device works, it would open itself up to all sorts of patent lawsuits. Its competitors might suspect that their patents are being violated, but they often can’t prove it without knowing the implementation details, so manufacturers hide all the information that they can.
I read somewhere that there were 100,000 4G patents and 5G already has about 30,000.
The only hope that we have is if we get info from rouge employees at chip companies, but who is going to destroy their lives just so some geeks can have free/open firmware? At any rate, any info we might get wouldn’t be useful with the next generation of chips. If Purism tried to sell a product with that free/open firmware included, it would probably also get sued out of existence for patent violations. Even if the chip company was OK with it, any company with one of the thousands of wireless patents could destroy Purism.
Finally, the FEC probably wouldn’t allow the device to be sold, for fear that someone might rewrite the firmware to violate FEC rules for frequency use.
Sadly, there is no way to pass laws to abolish patents, because the patent holders have way too much lobbying power. The only solution is to wait for the apocalypse when the insane legal system collapses or stage a revolution which abolishes all patent law.
RYF is clear that any software that can be updated using the CPU must be free software. Our (Purism’s) interpretation is that it does not force a requirement that firmware cannot be upgraded out-of-band from the CPU, or external to regular software updates.
We designed the Librem 5 based on RYF requirements, believe we comply fully, and are in the process of getting certification. In addition to that requirement we also believe a user should have freedom over their hardware similar to Freedom 0 (that one should be able to use free software for any purpose). As applied to hardware this means that we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.
This is significant because burning fuses on firmware is sometimes used as a security control, so attackers can’t overwrite it with malicious software. Yet it also is often used as a control to prevent legitimate users from “rooting” their devices and installing third-party firmware or software of their choice. In fact I’d argue many companies are using the security control more as marketing cover when the real reason behind burnt fuses is to give the vendor tighter control over the hardware at the expense of user freedom.
Beyond that, preventing out-of-band reflashing of firmware would also prevent us from offering a free software alternative to the proprietary firmware to be reflashed later on if we were able to develop it in the future. This isn’t far-fetched either, as we have done exactly this with coreboot and PureBoot firmware on our laptops.
Thanks for replying @Kyle_Rankin. Good to hear that Purism won’t prevent updating the firmware in the hardware. Still, that leaves large questions for me about how feasible it is for normal users to upgrade the firmware.
I see that Chestnut has BOOT_MODE1 and BOOT_MODE2 pins on the back and “Serial Downloader support (loading u-boot via USB)”.
Will there be some special boot mode where new firmware can be flashed (such as from a MicroSD card or over a USB cable connected to a PC)? (That would seem to be allowed by RYF under the “embedded secondary processor” exception, as long as the special boot mode was executing on the Cortex-M4 core in the i.MX 8M Quad or the separate Cortex-M4 used by the smartcard reader or in the USB PD chip.)
Or are you saying that we will have to take out the M.2 cards and put them in a PC to flash the firmware for the BM818 and RS9116 and use special external tools that don’t come with the Librem 5 in order to update the firmware for the other components on the PCB, such as the GNSS and the SPI Flash memory chip holding the proprietary DDR timing code?
Then how is the “Vikings D8 Workstation” RYF certified? It ships with a Crucial hard drive or Crucial SSD, the firmware for which are not open source, and can be updated via a special dd module from Grub. Such an update has been necessary in the past to fix Crucial drives soft locking due to a smart counter error after 5000 hours of on time. Obviously, I don’t expect you to have personal knowledge of the certification process for another vendor’s item, but if your analysis is correct, it should not be RYF certified.
Methods to flash the firmware on the Librem 5 are outside of my area of expertise. I would expect that we would document the process in our Librem 5 developer docs at some point, when it’s relevant (such as when there’s an update to apply).
Thanks for taking the time to respond. I’m very glad to hear it’s not being prevented. That was my biggest concern.
It would be nice if it were that easy. I hope that will be the case for Evergreen but if not maybe they’ll have something like that for Fir. There are probably more important things to work on for Evergreen.
If it is being updated by GRUB, then proprietary code is being executed on the main processor by the main operating system, so the secondary embedded processor exception in the RYF criteria doesn’t apply. This was exactly why I asked the FSF what it means by “software installation is not intended after sale” and why it wrote “not intended” instead of “not allowed”. It seems to me that the FSF must have known that there must be exception like this for security holes and bugs in the hardware:
The intention of the manufacturer is that the firmware doesn’t need to be upgraded after sale in order for the device to function, but something unexpected like a security hole or a bug may be discovered in the future that wasn’t intended.
My point is that the FSF should be upfront about this unacknowledged exception in its RYF criteria, so people don’t think that they have to live with hardware which might be discovered to be buggy or insecure in the future.
If I’m wrong in thinking that the FSF has an unacknowledged exception for problems like the Crucial SSD, then the Librem 5 could design a special boot mode that only executes on a “secondary embedded processors” (the Cortex-M4 core in the i.MX 8M Quad, the separate Cortex-M4 processor for the smartcard reader, or maybe the USB PD chip) for updating the firmware. Otherwise, the only solution is to put the Librem 5’s M.2 cards in your PC and upgrade them there, and do some strange workarounds like soldering wires on the Librem 5’s PCB and use an external device to flash the chips.
If the Librem 5 needs to have a special boot mode running on a Cortex-M4 core, I want Purism to have thought about it before releasing Evergreen, so it can be implemented later in the software and there is nothing in the hardware that prevents it from being implemented.
The more that I think about the RYF rules, the more I think that RYF is simply a poor strategy for promoting software freedom. You can’t build a modern ICT device without WiFi/Bluetooth, SSD controllers, and a dozen other things that require proprietary firmware updates.
At this point, we should acknowledge that the community has only managed to create free firmware for 2 families of WiFi/Bluetooth devices (Prism54 and some Broadcom 43xx) and the firmware is experimental (i.e., doesn’t work well) and it only runs on ancient devices that only support 802.11b/g. The idea that the community is going to reverse engineer the firmware for a modern 802.11n/ac/ad/ax device is ludicrous.
Every single free driver for a recent WiFi/Bluetooth device was either written by the manufacturer (Intel, Marvell, Redpine Signals, Qualcomm/Atheros, Realtek, Broadcom, Texas Instruments) or was based on code and/or documentation from the manufacturer (MediaTek/Ralink, Marvell), and not reversed engineered by the community. What happened was that WiFi/Bluetooth manufacturers decided that they wanted to be able to sell to the Android market and/or server markets, and the Linux kernel doesn’t deal well with proprietary drivers, because upgrades in the kernel can break the driver, and there were also security concerns with using binary blobs. The WiFi/Bluetooth manufacturers got feedback from device makers that they wanted them to release free drivers for the Linux kernel and market pressure made it happen.
The question is how to get WiFi/Bluetooth manufacturers to release free firmware for their devices (or documentation so the community can create firmware). The only viable strategy is to gather together a bunch of device makers who can pressure/incentivize the WiFi/Bluetooth manufacturers. It is the same situation with SSD controllers, USB controllers, cellular modem/GNSS, etc. The patent situation makes if very difficult, because no manufacturer wants to give competitors their implementation details for fear of patent lawsuits, but if we are ever going to pressure the component manufacturers to release free drivers and free firmware, we need to have a block of device makers demanding it.
As it stands now, the FSF has no ability to organize the device makers to call for free firmware, because most RYF device sellers just take equipment made by other companies and install free software, so they have almost no ability to influence the original component manufacturers. If Vikings, Ethnotechnical, MiniFree, Libiquity, Zerocat and NitroKey call up WiFi/Bluetooth manufacturers and say, “we would like free firmware for a WiFi/Bluetooth chip”, they will get laughed out of the room. If Purism and Raptor Computing Systems call up, they might get a polite email saying its not possible, because they manufacture new hardware, so they are talking to component suppliers.
Imagine, however, if we have a block of 40 Linux hardware manufacturers all asking for free firmware. Then, we have some real leverage in the electronic component industry. For that reason, I think that the FSF should create something like a “best practices” certification, which is based on classifying the manufacturers of each type of electronics component.
For example, in CPUs:
Then, FSF can certify devices as “best practices” if they select the best available components. For example, for mobile devices, there is no CPU in the “heroes” category, but there are several in the “contributors” category, so the device has one of those. Then do the same with other component categories (WiFi, cellular modem, GNSS, SSD controller, etc.).
Then, component manufacturers will start looking at the list and plan how they can be moved from “contributors” to “heroes”, or from “sharers” to “providers”, because they know that it will help when trying to sell components to makers of “best practices” devices.
That was essentially my take on how the RYF certification should work. Instead of a pass/fail, it should probably be a grade or rating, and require best effort on the part of the device manufacturer. Make the review process open, on the FSF mailing list, with a public comment period.
As a side note, there actually is an open firmware SSD out there, not sure what pricing, availability, or reliability is, but it is worth noting.
I think there is a misunderstanding on the part of Purism (and others) about what it means to “execute code” on the main CPU. This is something that comes up regularly with the AMD GPU firmware files, so I suppose it’s not a surprise. Let’s consider some concrete examples and see what we can figure out.
First example is the NVidia GPU firmware. There are several pieces of firmware, some of which is provided in the linux-firmware package, and some of which is provided only by the closed source driver. Without any firmware provided at runtime, the GPU runs in ultra low power mode, basically VESA only. The firmware included in the linux-firmware package can be uploaded to the card by the (open source) nouveau driver, and unlocks slightly better performance. This is essentially a file copy, no closed source code runs on the CPU. To get full performance out of the card, the nvidia kernel driver must be loaded, which then uses a cryptographic handshake with the GPU and uploads the remaining, signed, firmware files. This kernel driver runs on the CPU, and stays running after uploading the firmware. Obviously, this is a problem. It would be a problem even if the firmware itself were open, as the card will only accept the firmware if it’s signed, and only from the closed source driver, running in kernel space. Again, to be clear, the firmware updater is closed source, runs on the cpu, in kernel space, every boot.
The next example is the recent AMD GPUs. This time the firmware files are all provided by the linux-firmware package. They are all closed source, but one of them is well documented and can be modified by the end user (it’s just a table of power, temperature, and thermal limits for the card). The firmware is sent to the card by the open source AMDGPU kernel driver. Once again, sending these files amounts essentially to a file copy, with no closed source code running on the CPU. This doesn’t qualify for the RYF certification only because the firmware must be sent to the GPU on every boot.
In the next case, let’s consider the RAM timing training for the Librem 5. This is a blob of executable code provided by some device manufacturer (not sure if it’s the memory, chipset, or CPU manufacturer, but it doesn’t really matter). It must run on some CPU core, every boot. Just like the NVidia driver, it is not firmware, although it may contain firmware. Purism makes it effectively firmware by isolating it to a CPU core that is then not used for anything else.
The next case is the firmware update for a desktop motherboard. This is done by the existing BIOS, followed by a reboot. The updater itself is closed source, and runs on the main CPU, but only runs once, and then resets the computer. The problem here is that the BIOS itself is closed source, not that the updater is closed source.
The last case is the Crucial SSD firmware update. Unlike the previous cases, this firmware update runs in userspace, using standard POSIX tools. It literally is just a file copy (dd if=newfirmware.img of=/dev/sdx) . It also only runs once, and is not normally needed.
I’m not certain I’ve made the situation clear, but the bottom line is that some firmware updates require running closed source code on the main CPU, and some only require copying a file through a particular protocol, with no closed source code executing on the CPU.
I’m guessing that this would be acceptable under RYF, since the only code executing on the main CPU is dd, which is free software. The proprietary firmware code isn’t being executed, simply being copied to another device. I think that all your other examples would violate the RYF criteria.
Yes, a grading system would be better than simple pass/fail. It would take a lot of work to compile a list of hardware and rank how much each component promotes freedom, but I bet that FSF could find volunteers to work on it.
In my opinion, the FSF has largely fulfilled its original mission of a free operating system and free software applications. At this point, the critical work moves to free drivers, free firmware, and free hardware. It bothers me that the FSF does so little to engage the electronics industry. If the FSF was scoring devices in terms of their freedom promotion, the device makers might actually pay attention.
For example, the FSF could create a “Freedom Score”, that assigns a score between 0 and 100 to a device, based on how much free software and free hardware it contains. Purism used to have the highest laptop score in the industry. When System76 introduced laptops with Coreboot and free/open EC firmware, it would have closed the gap with Purism (with a reduction for proprietary WiFi firmware, but a gain for its free EC firmware). When MNT Reform ships, it will become the highest scoring laptop in the industry.
Currently reviews just say that the Dell XPS, TUXEDO InfinityBook Pro, Purism Librem 15, System76 Lemur Pro, and MNT Reform are Linux laptops, but imagine the dynamic if they get Freedom Scores of 55, 60, 75, 75 and 90, respectively. Suddenly, it becomes really clear which laptop is better in terms of software and hardware freedom, and I bet the MNT Reform would have more than 220 preorders.
Now imagine the dynamic with Dell engineers asking, “Can we switch the GPU from nVidia to AMD to get our score up to 60?” TUXEDO asks, “Can we finish our Coreboot port to get our score up to 70?” Purism asks, “Can we change our keyboard and fan controller, so they use free EC firmware to get 3 more points and beat System76?” System76 asks, “Can we switch our WiFi from Intel to Redpine Signals to eliminate the proprietary firmware and get another 2 points?” PINE64 asks, “Can we publish our schematics of the PineBook under the GPL to match the score of the MNT Reform?”
Suddenly, the device makers care what the FSF thinks, and they start talking to component makers, asking for free firmware, and they start asking Intel for permission to release their schematics under a free license. It sets a totally different dynamic in the industry.
I believe that is correct.
The firmware update for the motherboard fails because that firmware, once uploaded, will run on the main CPU. This is the case even if the updater were libre.
The RAM timing fails because it requires running a closed source training program on the CPU.
The AMD GPUs come the closes to working, and would be fine if the card remembered the last firmware files supplied as that would put it in the same category as Crucial (it’s a PCIe data coppy, instead of DD, but still fully open). The problem here is that it must be run at every boot, which means the user cannot delete the closed source firmware files from their machine and have it continue working. You could stash the firmware files onto an embedded flash chip, and send them from that flash chip to the GPU. Less clearly acceptable, you could probably read them back from the embedded flash chip into system memory, and then copy them to the GPU. They’re still not executed on the CPU, but it’s unclear if that counts as the user being expected to update them after product delivery…
NVidia GPUs are actually the worst, requiring both magic code on the main CPU, and copying the firmware files on every boot.
Note that if the motherboard bios were itself open, but required a closed source updater program, that would also not qualify for the RYF certification, unless it were run on a separate microprocessor.
Another example to consider is Intel and AMD CPU/embedded GPU microcode. These are firmware files which are uploaded to the CPU microcode memory at runtime, and the protocol to do so is open source. The key point in this case is that these microcode updates are not required for the CPU/iGPU to function (but they can provide important security or performance fixes). They don’t disqualify the CPU (though the ME/PSP on recent CPUs do), but you must leave it to the user to set up microcode loading if they want it (because it must be done every boot).
Unfortunately, the FSF tends to have an all-or-nothing attitude about most things. It is the same attitude that lead to publishing the AGPL3, which is a terribly convoluted and awful license (which can be circumvented easily by putting a filtering proxy between the covered work and the edge of your network). The idea was to try to force software developers to open source things if they want to use the latest AGPL goodies. Instead it mostly leads to AGPL things being thrown in the dustbin for fear of lawsuits. The GPL in general is in that category, as it is actually less permissive than the LGPL. For something designed to be monolithic, like the Linux kernel, or for something designed to always be distributed in source form (like python scripts), it’s fine. But for anything else, there’s a reason it’s not a very popular license.
Fundamentally, this is the wrong approach. Instead of trying to force people to open source their stuff, with the threat of lawsuits if they don’t, encouraging the culture which leads to cooperation works better. Things like the no-patent-lawsuit reciprocity agreements are the way out of the present pickle where no one is willing to release their source code for fear of revealing that they are using someone else’s patented ideas.
I don’t mind if the FSF sets very strict goals, as long as they are strategically effective. I think that the FSF’s hard line on 100% free software worked, because we had two groups in the FSF and OSI that could appeal to different constituencies. The OSI could talk to Netscape, IBM, SUN, etc. and make the business case for open source, but the OSI never convinced me as a user, whereas FSF was very convincing to me as a user.
When I look at the reasons why free software was promoted by the governments of Brazil, Peru, Venezuela, Bolivia and Ecuador, the FSF made a more convincing argument for these governments than the OSI. In Bolivia (where I currently live), the FSF’s talk about user rights meshed well with Bolivia’s discourse about decolonization and Richard Stallman was invited 3 times to come to Bolivia, whereas the OSI has had little impact. When I go to Linux conferences in Bolivia and Peru, I hear the term “software libre” probably 3 times as much as I hear the term “código abierto”, even from my friends who run companies.
However, when we talk about convincing component manufacturers to release free drivers and free firmware, we simply have to speak a language that translates into business. The FSF has to convince users to value devices that can run free software of course, but it also needs to be able to make a convincing argument to businesses, and the RYF criteria isn’t doing much to move the needle, because it is a standard that almost no device maker can meet, so we need some intermediate strategy as well, such is what I was trying to suggest with the “Freedom Score”.
On the question of licenses, I agree that the AGPL is a cumbersome license, simply because it places too much of a burden on the people using it. Every time that you change even a single line of code, you are obligated to publish your changes under the AGPL, which is too much of a hassle for many people. In the real world, however, it is often very hard to know if a company has changed the source code when they are running it on their own servers and not distributing it, so most compliance is effectively voluntary anyway.
I used to work a company that produced AGPL software. I always told people using our software to not worry about publishing their changes to our code if they were only making minor tweaks and to publish their changes when it was convenient for them. The reality was that we didn’t get strict compliance, but its sole purpose was really to prevent competitors from extending our code without sharing their changes, but aside from a few community forks, no commercial competitors ever touched our code, so it never became an issue.
Whether you like the GPL or hate it, depends on your point of view. Because using a small piece of GPL code can “infect” the rest of the code, it isn’t a good license for widgets and libraries, which is part of the reason why MIT/BSD style licenses have taken over the web. However, I have used the GPL on code that I wrote, precisely because I wanted to guarantee that it stayed free.
Where I think that the GPL has been a very effective is in forced rival companies to work together. One of the reasons why so many rival companies contribute to the Linux kernel is because they know that no other company can take their work and privatize it. When Intel contributes USB 3 drivers to the Linux kernel, it knows that its competitors AMD and Qualcomm can’t ever privatize its work, so Linux becomes a common platform that everyone can contribute to without fear.
I believe that one of the reasons why BSD never had the commercial success of Linux, was precisely because the license encouraged each group to privatize the work of others, so there was less trust. The major flavors of BSD all develop their own kernels and don’t collaborate that much, partly because their license doesn’t encourage them to work together.
Of course, there are counterexamples, so the license isn’t the only factor. For example, competing companies collaborate to produce PostgreSQL under a BSD-style license, whereas MySQL and MariaDB don’t collaborate under the GPL, because each of the companies are claiming that their way of extending the database is better, and frankly Oracle doesn’t have a culture of FOSS in its DNA to facilitate collaboration. It also has an antagonistic relationship with Red Hat, and its management of OpenOffice.org and Virtualbox OSE were poor.
I guess that I see the ethics differently from you. I don’t want to force others to change a large code base to GPL, if all they want to do is incorporate a small piece of GPL code. On the other hand, the idea that someone can take a huge piece of FOSS code (like BSD or PostgreSQL) and privatize it really bothers me.
On one level, I basically agree with the tenet that the developer should decide on the license she wants for her work. However, when I think about my long-term future, I want to live in a world where everything I use is FOSS, and the GPL makes a lot of sense for promoting that strategic goal.
When I analyze why a company like Google hates the GPL, I find its reasons really problematic. I sort of agree with Google when it is afraid that a small piece of GPL code can “infect” it. However, Google also abuses the FOSS community when it takes huge amounts of work from the community, and makes its changes, and does not share back. For example, when Google took MySQL and turned it into BigTable or when Google took Debian and heavily modified it, Google’s refusal to share its changes weren’t ethical in my opinion, and that was exactly the reason why the AGPL was created.
Google takes advantage of large amounts of GPL software and then violates the spirit of the GPL by exploiting a loophole by claiming that it has no obligation to share its changes to code that serves up information to 3 billion people on the planet. I guess what really angers me is that Google then turns around and tells everyone not to use any of the FSF licenses, and actively tries to confuse users with the word “free”, by refusing to show people what is the license of the apps they are downloading in the Play Store.
This topic is right now being discussed on the libreplanet-discuss mailing list:
“RYF can, and should, be improved”: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-01/msg00019.html – by Leah Rowe, linking to https://libreboot.org/news/policy.html and https://osboot.org/news/policy.html
Leah Rowe writes:
Both articles talk about binary blobs from coreboot; the libreboot one
talks about blob deletion, and osboot talks about blob reduction. The
purpose of both projects, is to provide as much software freedom as
possible to users, within those policies. The ultimate goal: free
software everyone, available to everyone, without the injustice that is
proprietary software. The projects differ in their approach, but have
that some underlying goal.I call for discussion of the topics presented in these articles. The
articles also discuss flaws with the FSF’s “Respects Your Freedom”
program, and discusses ways to improve upon it, so as to encourage and
to facilitate more freedoms for computer users in the future.Discussion welcome. Please, tell me your thoughts!
Now might be a good time to join that mailing list and take part in the discussion there, I think it’s the right place for it and FSF people will see it and are likely to respond. (one reply so far, agreeing with Leah)
