2

Is there a way, to have the, from my perspective all-important, libraries such as gmp, mpir, mpfr be used in a license that fully supports code-signing?

My perspective is that of a curious researcher. My main lines of thoughts are:

  1. These libraries are so good and so widespread that they are used in many very important software systems. I consider them (critical) infrastructure.
  2. These libraries have recently changed to LGPL3.
  3. LGPL3 requires that any software system build on these libraries must allow the user to compile her own (self-compiled) version of the library and link it to the software system. The software must still be able to run fully functional as before.
  4. Big software companies use code-signing to ensure that only authorized, signed software is run in their networks. This helps to mitigate the risk of malware infections for their customers. The process of deploying software is in these settings often automatized.
  5. However, 3) seems to inherently contradict 4). The software company cannot safely sign binaries of LGPL3 building blocks. The problem is that in these situations, according to 4) users should also be able to create signed code that will run equally fine on the companies network. To enable users to sign code, there must under these circumstances a) either be a process to allow specific users to obtain signatures on their binaries (which seems impossible to automatize efficiently in a secure manner) b) or the signing key must be available to many users (which defeats the purpose of signing).

Is my understanding correct?

I feel that I am surely not the first to realize this tension between different strategies to improve the state of software development more broadly - open source development and code-signing. Is there a consensus answer that should be common knowledge?

How does the software community deal with these two apparently contradicting paradigms?

So here are the ways that I can see to nevertheless use these awesome libraries in a project that does apply code-signing.

  1. use older versions of the software that were published under LGPL2.
  2. re-implement the functions in the header files using free libraries like openssl. This however, would come at a huge speed disadvantage and is likely to result in buggy and less secure code. (I wonder if there are similar projects that have tried to achieve this for any LGPL3 library. I am not aware of such an endeavor - so this makes me feel that either this idea is totally flawed from the get-go or that it's still too early for such a project to have taken place.)
  3. find forks that specifically conserve the state of an older version of some library (while possibly at the same time extending it in other ways).

Is there another way that you can see? Are you aware of ways others have used in the past to achieve the same goal? Although libraries like gmp, mpir already have licenses, could one imagine additional extra licenses for such purposes? I have found an example here that introduces a static linking exception:
http://wiki.zeromq.org/area:licensing which seems to address this specific purpose.

Improve this question
3
  • While this is definitely an interesting and important topic, it is not for SO Commented May 11, 2021 at 6:44
  • 2
    Does this answer your question? (L)GPL software on devices provided for internal use. In short: when it comes to software used by employees, it is the company that is the user of the software, not the individual employee. Commented May 12, 2021 at 5:51
  • It sounds to me at first blush that the requirement "users should also be able to create signed code that will run equally fine on the companies network" is too strict. If the resulting binary runs fine (signed by the user's own personal key, perhaps), then how it interacts over a network is outside the scope of what the (L)GPLv3 requires. The tivoization requirements pertain to the (refusal of) execution of the binary on some hardware, not network interactions. If you are talking about execution on company-owned hardware, I agree with @Bart above; in that case no distribution occurs. Commented Dec 9, 2021 at 17:24

1 Answer 1

Reset to default
0

The question is interesting, and yes, you are not the first one to think about it. There is a similar question answered here.

The GNU FAQs are pretty specific about your question. Only when you use a combination of HW and SW to prevent execution of the code you run into issues.

Improve this answer