Announcement
Collapse
No announcement yet.
Mir Relicensed To GPLv2 Or GPLv3
Collapse
X
-
Originally posted by linuxgeex View PostYes I think they are trying to create a best-of-both-worlds ambiguity which allows more freedom to link with proprietary code, while at the same time (creating an illusion that) proprietary users can inherit the implied patent license. However anyone linking under v2 restrictions is revoking their right to the implicit V3 patent grant, so they had better watch their backside!
- Likes 1
Comment
-
Originally posted by bregma View PostI think (and I have no inside information on the matter any more) that the addition of GPLv2 has nothing to do with patent indemnification and everything to do with Tivoization. An embedded or IoT manufacturer wants to be able to burn a ROM without having to worry about making sure a consumer can replace the ROMs, and everything that entails (making the sources available in provably buildable form, adding additional circuitry to make the ROMs flashable, etc). Turns out that the additional freedoms the GPLv3 is designed to enforce (through the anti-Tivoization clause) are expensive, and given the very small margins in consumer electronics these days, can be deal killers. I don't think this is anything malicious, I think it's just business in the age of commodity computing.
In most cases it's the device manufacturer that goes out of its way to add signature checks and other stuff to prevent custom ROMs, not GPL that requires them to do more work to allow people to flash custom ROMs.
But really, outside of mobile it's much more relaxed.Last edited by starshipeleven; 09 August 2017, 01:58 PM.
Comment
-
Originally posted by starshipeleven View PostI'm pretty sure the GPL does not require the hardware manufacturers to allow people to flash custom ROMs, and many embedded devices have a bootloader that has a recovery mode already because it had that ability in the chip manufactuer's SDK too.
Originally posted by GPLv3If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.
It's great that you can afford to buy a refrigerator or an in-dash automotive infotainment system with a port to flash your own software. It really is. For the rest of us, it's either MIT/Apache licensed code that runs it in an inaccessible manner, it's GPLv2 code, or it's completely proprietary but it's within our spending limit.
As for manufacturers that go out of their way to add cryptographic signature checks and other DRM, they're also definitely the target of the GPLv3 under the Tivoization clause. I've run in to few (none) of those that would also accept the GPLv2 but feel free to hate on them they deserve it.
- Likes 2
Comment
-
Originally posted by bregma View PostIt means not only do you have to make the source code available (Freedoms 2 and 3), but you have to be able to change and use the software (Freedom 1).
Furthermore, the sentence right after the part you quoted makes this expressly clear (emphasis mine):
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
- Likes 1
Comment
-
Originally posted by bregma View PostThis is known colloquially as the anti-Tivoization clause. It means not only do you have to make the source code available (Freedoms 2 and 3), but you have to be able to change and use the software (Freedom 1). In order to do that you have to be able to install your modified software on your device (the Installation Information). That means the manufacturer has to make available a method to do that, which as I said usually includes extra electronics and infrastructure and increased manufacturing costs in a near-zero-margin industry.
Although on the hardware part you're still plain wrong. Please note that it's very common to have some unsoldered contacts for TTL/UART (serial console) or debug ports or even whole unpopulated areas for other kinds of debug electronics in the the device's board design because your engineers need to debug it anyway during development and this saves tons of cash as you don't need to design and then manufacture 2 different boards.
Even x86 boards (desktop or laptop) usually have (undocumented but labeled or at least very likely) debug contacts or ports.
Designing boards without debug is usually more expensive, so it is quite rare in anything that can afford wasting some space for stuff that won't be populated/used in production boards.
It's great that you can afford to buy a refrigerator or an in-dash automotive infotainment system with a port to flash your own software. It really is.
As for manufacturers that go out of their way to add cryptographic signature checks and other DRM, they're also definitely the target of the GPLv3 under the Tivoization clause. I've run in to few (none) of those that would also accept the GPLv2 but feel free to hate on them they deserve it.
Comment
-
Originally posted by krach View PostFurthermore, the sentence right after the part you quoted makes this expressly clear (emphasis mine):
https://www.gnu.org/licenses/gpl-3.0.html
Comment
-
Originally posted by bregma View Post
I think (and I have no inside information on the matter any more) that the addition of GPLv2 has nothing to do with patent indemnification and everything to do with Tivoization. An embedded or IoT manufacturer wants to be able to burn a ROM without having to worry about making sure a consumer can replace the ROMs, and everything that entails (making the sources available in provably buildable form, adding additional circuitry to make the ROMs flashable, etc). Turns out that the additional freedoms the GPLv3 is designed to enforce (through the anti-Tivoization clause) are expensive, and given the very small margins in consumer electronics these days, can be deal killers. I don't think this is anything malicious, I think it's just business in the age of commodity computing.
The extra circuitry doesn't often apply these days since these devices almost always have an MCU responsible for coordinating booting, controlling sensors, putting the device to deep sleep, etc. and that can be programmed via JTAG a UART from one of the MCU's GPIO pins... so one way or another. That hardware exists at no extra cost because it's there as part of the design, and reduces costs by making it possible to fix devices mid production, patch devices in the field, and avoid far more costly recalls. At worst we're talking about the cost of a couple solder pads on the board to meet compliance. Probably more expensive is even having the conversation with the dev team and your lawyers.Last edited by linuxgeex; 13 August 2017, 02:45 AM.
Comment
-
Originally posted by linuxgeex View PostThere's definitely things I want Tivoized. I really don't want the medical equipment in the hospital having published, documented backdoors (being able to re-flash it with consumer code is the mother of all backdoors) along with sources.
Also proprietary software has published and documented vulnerabilities, and most hospital, industrial and military stuff is weakest, as it is usually decades-old and can't be replaced easily anyway.
They keep them safe by keeping them disconnected from unsafe networks AND guarded, not by using flamboyant DRM or whatever.
Because really, if the bad guys can solder the serial port on the device's motherboard they have full hardware access, and that means they can do whatever they want anyway.Last edited by starshipeleven; 13 August 2017, 08:17 AM.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostThey keep them safe by keeping them disconnected from unsafe networks AND guarded, not by using flamboyant DRM or whatever.
Comment
Comment