4

Let's assume I am building an embedded linux device using amongst other things (L)GPLv3 software. The device is sold to non-business users so the anti tivoization clause applies.

I want to be compliant, so I offer the complete corresponding source code as well as a mechanism to install modified (L)GPLv3 software.

The hardware isn't subsidized, so I am fine when people buy the device and use and modify it for their own purpose, but I don't want to offer guarantees or services for users with a modified device. Is that legal under the provisions of the (L)GPLv3?

Question:

  • Can I reject service calls for modified devices?
  • The device is tied to a cloud service. Can I prevent modified devices from using the service?
  • Can I remove my proprietary bits as soon as the user is modifying his device (after a stern warning of course).
Improve this question
7
  • "Can I remove my proprietary bits as soon as the user is modifying his device" - what proprietary bits?
    – MadHatter ♦
    Feb 8, 2018 at 15:18
  • Could be an application, could be certificates needed to use the cloud service
    – Frank Meerkötter
    Feb 8, 2018 at 15:19
  • You should re-read this paragraph of the GPL: "The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient .... Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network."
    – Brandin
    Feb 9, 2018 at 9:26
  • @FrankMeerkötter How would you remove it? If you intend to use GPL software to run a "deletion" procedure that deletes certificate files whenever you press a button, then per the GPL you would need to allow users to modify the GPL software and remove this backdoor if they so choose. Denying network access is fine if the modified client is behaving badly, so I don't see why you need a backdoor like this.
    – Brandin
    Feb 9, 2018 at 9:30
  • 1
    @FrankMeerkötter If you deny or degrade network access only because it is modified (and not because, say, the modifications are causing network problems or are violating network rules), I don't know if that is allowed or not, but it is certainly not in the spirit of the license, and is probably not a good idea anyway. If I modify my copy of Firefox to try to break into my bank, my bank should deny me because of the specific network behavior, not because I'm running a 'modified' Firefox copy.
    – Brandin
    Feb 9, 2018 at 10:02

1 Answer 1

Reset to default
3

I am fine when people buy the device and use and modify it for their own purpose

It seems to me that you're honouring your obligations under the GPL (and therefore under LGPL). There will of course be the obligations to make source available, etc., but you don't ask about those, so I'm assuming you have them covered.

Can I reject service calls for modified devices?

Many vendors supply devices which incorporate software covered by the GPL and consider the warranty voided if you install your own software on them - just about any company who's ever sold an Android phone fits into this category. If you've ever tried to get warranty support on an Android phone that's been Cyanogenmodded or LineageOSed, this will not be an alien idea. I don't say it's a nice thing to do, but lots of other companies do it without issue. Be clear with your customers about your policy.

Can I prevent modified devices from using the service?

Legally, it's not clear to me. GPL3 s6 requires that you provide the user with "installation information", which

must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Whether access to a network service constitutes "continued function" will, I suspect, depend on how useful the device is without that service.

But the point may be moot, because you may find it technically difficult or even impossible to do this; free software has a long history of precisely emulating closed devices in order to obtain service over a network. Consider, for example, get_iplayer; the BBC tries very hard to distinguish between an iphone connecting to view a programme, and a Linux box running get_iplayer doing the same, but has not reliably been able to do so.

Can I remove my proprietary bits as soon as the user is modifying his device (after a stern warning of course)

I wouldn't. Not only is it unlikely to work reliably (see above), but many jurisdictions will take it amiss if you are accessing customer devices to change the contents of them after the customer has pretty clearly expressed a desire to remove the device from your control (by installing modified software). And of course, and as ever, IANAL/IANYL.

Improve this answer
5
  • What if the software is designed in such a way as to allow servers to validate that a client is running a particular version of the client program using configurable certificates, and includes information sufficient to set up a server with a new certificate and sign a modified version of the code using any signing key possessed by the person making the mod, but witholds the private keys necessary to use mods on servers that don't explicitly accept them? Would that satisfy the letter and spirit of the GPL?
    – supercat
    Apr 14 at 17:26
  • Without having details of such a scheme it's hard to comment further. But I note in passing my point about get_iplayer above: schemes that rely on clients to self-certify their state generally don't work, unless the client hardware can be relied upon to betray its owner - which is what the anti-Tivoisation provisions of GPLv3 are specifically designed to forbid.
    – MadHatter ♦
    Apr 15 at 9:48
  • One could design a server which could authenticate that a particular client has access to a dongle that holds the universe's only copy of a unique private key. If a program were to rely upon the dongle to perform certain essential functions using encrypted data, and its author had a list of the public keys associated with all legitimate dongles, it could be sure that the functions performed by the dongle were not tampered with. Such a dongle could be designed to disallow all persistent modifications to its state if it supported import/export of key data using an AES key that existed...
    – supercat
    Apr 15 at 19:20
  • ...nowhere in the universe outside the dongle. If every dongle whose keys would be accepted by a server has been indelibly programmed with a flash program that will use a derived key to decrypt a received code image into RAM and execute it, one could make it so that only someone with a copy of the server owner's private key would be able to produce a code image that would be compatible with a server using that private key, but owners of other servers would be able to generate code images that were compatible with their servers.
    – supercat
    Apr 15 at 19:35
  • How does the dongle know it's currently connected to a legitimate client? If it doesn't, then all you're authenticating is that a particular client has a valid dongle, not that it's a valid client. In any case, protocol design is beyond the scope of this comments field - and probably OT for this site; I don't think we should continue this conversation here.
    – MadHatter ♦
    Apr 15 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.