Announcement

Collapse
No announcement yet.

Mir Relicensed To GPLv2 Or GPLv3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by GhostOfFunkS View Post
    On a related note the Unity8 forks seem fine. Who would've guessed
    fixed.

    Comment


    • #12
      Originally posted by linuxgeex View Post
      Yes 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!
      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.

      Comment


      • #13
        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.
        I'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.

        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


        • #14
          Originally posted by starshipeleven View Post
          I'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.
          From the text of the holy GPLv3 itself:
          Originally posted by GPLv3
          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.
          This 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.

          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.

          Comment


          • #15
            Originally posted by bregma View Post
            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).
            I don't agree with your interpretation. The clause says you have to provide the Install Information. It doesn't say you have to include extra electronics in order to make a later installation possible.

            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).

            Comment


            • #16
              Originally posted by bregma View Post
              This 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.
              Hm, I keep forgetting that we are talking of GPLv3, I actually never saw anything more than GPLv2 in embedded, so I was unconshiously still thinking about GPLv2.

              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.
              (going on a tangent) It's even greater when you can still find refrigerators and cars that lack any kind of such retarded bullshit on board, but maybe it's only me.

              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.
              I don't hate them as long as they aren't violating licenses. If they only use proprietary or please-fuck-me-I'm-a-permissive-license licenses then it's fine.

              Comment


              • #17
                Originally posted by krach View Post
                Furthermore, the sentence right after the part you quoted makes this expressly clear (emphasis mine):
                https://www.gnu.org/licenses/gpl-3.0.html
                Most firmwares are upgradable and receive some kind of updates nowadays. True ROMs are very very rare even for microcodes and other very low level stuff.

                Comment


                • #18
                  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.
                  There'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.

                  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


                  • #19
                    Originally posted by linuxgeex View Post
                    There'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.
                    I think you don't understand the point of "tivoized".

                    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.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      They keep them safe by keeping them disconnected from unsafe networks AND guarded, not by using flamboyant DRM or whatever.
                      Ha! You'd think. But you'd be wrong. https://ics-cert.us-cert.gov/advisories/ICSMA-17-215-02 <- And that's a problem because hospitals often have these machines in the same internet-facing network as all the other machines in the hospital: https://arstechnica.com/information-...cal-condition/

                      Comment

                      Working...
                      X