Do not link to OpenSSL licensing terms from squid -v

[rousskov]

The link is unnecessary and may be unstable. The accompanying text is
unnecessary scary. All libraries used by Squid come with "legal
restrictions on distribution". There is no reason to single OpenSSL out.

[yadij]

OpenSSL is the only library Squid links that is not compatible with the GPLv2+ license of Squid, and which imposes conditions on third-parties distributing Squid.

• "Redistributions of any form whatsoever must retain the following acknowledgment" ...

• "All advertising materials mentioning features or use of this software must display the following acknowledgment"...

• "All advertising materials mentioning features or use of this software must display the following acknowledgement"

Removal of the public reference in the binaries self-documentation makes Eliezers and Diladele, and several other distributors products illegal.

We either have to link as done, or include the OpenSSL and SSLeay licenses wholesale into that documentation text. Which I think you will agree is even worse.

[rousskov]

OpenSSL is the only library Squid links that is not compatible with the GPLv2+ license of Squid, and which imposes conditions on third-parties distributing Squid.

This assertion is incorrect: It is possible to link Squid with many libraries that are not compatible with GPLv2. More importantly, the assertion is irrelevant to this PR: This PR does not change the legal status of Squid, OpenSSL, their combination, or anything else. The PR has no impact on any legal matters.

Removal of the public reference in the binaries self-documentation makes Eliezers and Diladele, and several other distributors products illegal.

Incorrect and irrelevant again: The OpenSSL license does not require any self-documentation in binaries. Moreover, Squid builders are free to add any text they wish to the Squid binaries they built; we even provide an official interface for that IIRC. Finally, this PR does not remove any references that the OpenSSL license requires.

We either have to link as done

Which OpenSSL license item requires Squid binaries to print For legal restrictions on distribution see https://www.openssl.org/source/license.html? I checked before posting this PR, and I checked again after receiving your comment, but I cannot find any such requirement.

[yadij]

It is possible to link Squid.

The distro lawyers tell me that linking is not the same as distribution. It can be linked and used freely, but the resulting binary cannot be distributed to others legally. The -v output does count as documentation of the binary in legal terms, so under the OpenSSL license conditions it requires a full copy of the license text OR a clear and explicit direct link to that full text.

To be extra clear: this is not about the source code, nor about building and linking. It is specifically about the final binary object and what can be done with it.

[rousskov]

Amos: OpenSSL is the only library Squid links that is not compatible with the GPLv2+

Alex: Incorrect: It is possible to link Squid with many libraries that are not compatible with GPLv2

Amos: The distro lawyers tell me that linking is not the same as distribution.

As you can see, you are shifting goal posts here. If you have a new argument, fine, but it is best to be explicit about it (and to withdraw the old argument). Otherwise, we will be going in circles, especially when you ignore specific key questions about the basis of your arguments.

It can be linked and used freely, but the resulting binary cannot be distributed to others legally.

It is certainly true that some licenses (or combination of licenses) make distribution of some binaries illegal, but I am struggling to understand why you are saying that. Are you implying that both of the statements below are true (where "patched" means "after this PR changes")?

1. Unpatched Squid binaries can be distributed legally.
2. Patched Squid binaries cannot be distributed legally.

The -v output does count as documentation of the binary in legal terms,

Yes, Squid -v output is a part of Squid documentation. It certainly is not the only Squid documentation or the entire Squid documentation. To satisfy various licensing requirements (unrelated to OpenSSL), any Squid binary distributor must distribute Squid binaries with more documentation than what squid -v outputs.

so under the OpenSSL license conditions it requires a full copy of the license text OR a clear and explicit direct link to that full text.

Several problems render this argument invalid:

• No OpenSSL license condition requires each documentation part to contain something. Naturally, some documentation parts may not mention OpenSSL. OpenSSL requires that documentation and/or other materials provided with the distribution contain certain statements, but those requirements apply to documentation/materials as a whole and, hence, can and should be satisfied without using -v output.

• No OpenSSL license condition allows an "explicit direct link" to replace the required statements. Thus, the current/unpatched -v output cannot be used to satisfy OpenSSL licensing requirements. Thus, removing it does not introduce a violation.

• OpenSSL licensing requirements discussed here apply to OpenSSL distribution. Squid binaries do not normally contain OpenSSL code. With the exception of rare static builds, a Squid binary uses OpenSSL but does not contain OpenSSL. The distributors distributing OpenSSL (in any form) are certainly subject to OpenSSL licensing terms but the Squid binary itself is not. Those distributors must satisfy GPL, OpenSSL, and many other licensing conditions to distribute their stuff legally, of course, but they may, should, and do that without relying on squid -v output.

[yadij]

Amos: OpenSSL is the only library Squid links that is not compatible with the GPLv2+

you ignore the AND part of my initial statement. Which is about distribution.

Alex: Incorrect: It is possible to link Squid with many libraries that are not compatible with GPLv2

Amos: The distro lawyers tell me that linking is not the same as distribution.

As you can see, you are shifting goal posts here. If you have a new argument, fine, but it is best to be explicit about it (and to withdraw the old argument). Otherwise, we will be going in circles, especially when you ignore specific key questions about the basis of your arguments.

The goalpost was about distribution, and remains about that.

It can be linked and used freely, but the resulting binary cannot be distributed to others legally.

It is certainly true that some licenses (or combination of licenses) make distribution of some binaries illegal, but I am struggling to understand why you are saying that. Are you implying that both of the statements below are true (where "patched" means "after this PR changes")?

Unpatched Squid binaries can be distributed legally.
Patched Squid binaries cannot be distributed legally.

Yes for the PR change as it currently is they are both true.
For the subset of binaries built to use OpenSSL, anyway.

The -v output does count as documentation of the binary in legal terms,

Yes, Squid -v output is a part of Squid documentation. It certainly is not the only Squid documentation or the entire Squid documentation. To satisfy various licensing requirements (unrelated to OpenSSL), any Squid binary distributor must distribute Squid binaries with more documentation than what squid -v outputs.

Indeed. It is up to distributors to ensure that the documentation and advertising they do complies with that license. Which is a part of why that -v output highlights that the requirements are on distribution.

(Also as a side note, the mention and link are partially to assist recipients of Squid products to kno

so under the OpenSSL license conditions it requires a full copy of the license text OR a clear and explicit direct link to that full text.

Several problems render this argument invalid:

No OpenSSL license condition requires each documentation part to contain something. Naturally, some documentation parts may not mention OpenSSL. OpenSSL requires that documentation and/or other materials provided with the distribution contain certain statements, but those requirements apply to documentation/materials as a whole and, hence, can and should be satisfied without using -v output.

Clause #2 of both OpenSSL and SSLeay licenses. Which is effectively the same:

" * 2. Redistributions in binary form must reproduce the above copyright

• notice, this list of conditions and the following disclaimer in
• the documentation and/or other materials provided with the
• distribution."

Providing the link to full-text in the binary -v is apparently sufficient to allow distributors not to have to patch the license into the Squid sources when building. Not having it means somebody has to patch the -v documentation.

As an aside; if you can figure out a good way to add the OpenSSL/SSLeay disclaimers and license to the Squid copyright license files in a way that does not appear at all in non-OpenSSL builds I'm interested - this PR could be doing that instead of just removal. Be aware that including the license text in auto-build scripts etc would itself mean they need to be displayed simply for those scripts to be distributed by us. A nasty catch-22 situation.

No OpenSSL license condition allows an "explicit direct link" to replace the required statements. Thus, the current/unpatched -v output cannot be used to satisfy OpenSSL licensing requirements. Thus, removing it does not introduce a violation.

As you agreed the -v output constitutes documentation. Which makes it fall under OpenSSL clause 6 and SSLeay clause 3 and possibly 4. OpenSSL clause 3 is a grey area since -v is not really advertising materials, though it does document OpenSSL feature availability (eg. --with-openssl).
Using a clear link and mention that it is to legal stuff is apparently sufficient documentation in leu of adding those license texts directly into our source code.

OpenSSL licensing requirements discussed here apply to OpenSSL distribution. Squid binaries do not normally contain OpenSSL code. With the exception of rare static builds, a Squid binary uses OpenSSL but does not contain OpenSSL. The distributors distributing OpenSSL (in any form) are certainly subject to OpenSSL licensing terms but the Squid binary itself is not. Those distributors must satisfy GPL, OpenSSL, and many other licensing conditions to distribute their stuff legally, of course, but they may, should, and do that without relying on squid -v output.

The advice I am working from is from Debian and Ubuntu legal teams. Unfortunately those distros have other issues that prevent OpenSSL builds being added there. But this link and statement was apparently sufficient to make the Squid binary safely/legally distributable by anyone who a) did not also package and distribute OpenSSL itself, and b) complied with the OpenSSL license clauses in their own documentation and advertising materials.

[rousskov]

Amos: OpenSSL is the only library Squid links that is not compatible with the GPLv2+ license of Squid, and which imposes conditions on third-parties distributing Squid.

Amos: you ignore the AND part of my initial statement. Which is about distribution.

I did not ignore it -- I said the assertion is irrelevant, but I now see what happened: I misinterpreted your "linking is not the same as distribution" fact as a goalpost shifting defense of the linking (i.e. first) part of the statement. In fact, it was not a defense of that (indefensible) part but an invitation to discuss the distribution (i.e., second) part. I am sorry I failed to decipher that.

FWIW, the second part of that initial statement is either invalid or misleading -- the OpenSSL license does not impose conditions on third-parties distributing Squid because OpenSSL license imposes conditions on OpenSSL distributors, not Squid distributors.

Unpatched Squid binaries can be distributed legally.
PR-patched Squid binaries cannot be distributed legally.
Yes [...] they are both true.

Even if we assume that the removed -v text affects the legal standing of a distribution (it does not, but let's pretend that it does for the sake of the argument in this paragraph), it is still impossible for both statements to be true because any distributor can take the text produced by the removed -v functionality and add it to the documentation that comes with their distribution!

When OpenSSL license talks about distributing binaries, it always talks about accompanying "documentation and/or other materials" so moving the text there will not affect the legality of a distribution. Thus, if a distribution was legal, it can remain legal (i.e., the second statement is false even under the most generous of assumptions).

Which specific OpenSSL licensing requirement did the removed text satisfy that cannot be satisfied by distributors without the removed -v functionality? I cannot find any such requirement. To minimize waste, we may want to focus on a specific licensing requirement that you believe the removed text satisfied (and nothing else in a distribution can). Some of the candidates are rejected further below.

Alex: any Squid binary distributor must distribute Squid binaries with more documentation than what squid -v outputs.

Amos: Indeed.

Great, we are in agreement that any Squid distribution must include some documentation. Consequently, even if the removed text does satisfy a legal requirement (again, pretending for the sake of the argument), then the same text can be included in that accompanying documentation to restore the status quo. Thus, PR-patched Squid binaries can be distributed legally. This means this PR does not preclude any distributors from distributing Squid legally.

Which is a part of why that -v output highlights that the requirements are on distribution.

Why should squid -v output educate distributors about some 3rd party software distribution requirements that may or may not apply to them, regardless of how Squid was built?? It seems totally inappropriate to me. That education is the task of the 3rd party software itself, not Squid. The job of -v is to inform of Squid version and, if we want to be verbose, Squid license and/or build options. Everything else is out of -v scope, including educational materials.

Alex: No OpenSSL license condition requires each documentation part to contain something. Naturally, some documentation parts may not mention OpenSSL. OpenSSL requires that documentation and/or other materials provided with the distribution contain certain statements, but those requirements apply to documentation/materials as a whole and, hence, can and should be satisfied without using -v output.

Amos: [After citing clause 2:] Not having [the link to full-text in the binary -v] means somebody has to patch the -v documentation.

Why?! I do not understand. I really do not. I see absolutely no connection between clause 2 of the OpenSSL license and the alleged requirement to say something (anything!) in squid -v output. Please show me how you get from clause 2 (which requires OpenSSL distributors to say X in their distribution documentation as a whole) to Squid -v output. You clearly see some connection there. I do not. Please detail it.

In other words, why wouldn't a concerned distributor of OpenSSL just add the required text to their documentation that comes with their distribution? In fact, they must do it already because even if they happen to include Squid in the same distribution, squid -v text alone does not satisfy GPL, FreeBSD, etc. licensing requirements (requirements that clearly do apply to Squid)! Why would they want to patch Squid output to add OpenSSL distribution terms instead of simply making their documentation compliant?! It just makes no sense to me.

As you agreed the -v output constitutes documentation.

... it can be considered to constitute a (tiny!) part of Squid documentation. No more than that. It is not OpenSSL documentation. And, under any scenario where Squid distribution is legal, it is not the whole documentation. It is just a small piece of the puzzle.

Which makes it fall under OpenSSL clause 6 and SSLeay clause 3 and possibly 4.

Being a part of Squid documentation does not make one a subject to any OpenSSL terms. How can you not see it?! squid -h is a part of Squid documentation. Every squid.conf.documented directive block is a part of Squid documentation. The COPYING file is a part of Squid documentation. Does each of them fall under those OpenSSL clauses? Of course not! Squid -v is no different. It is just a tiny part, doing its own tiny job.

OpenSSL documentation/attribution clauses you mention apply to distributed OpenSSL code and/or documentation as a whole. Not to each and every little piece of that distributed whole. This is the only reasonable way to interpret the OpenSSL license and virtually any legally enforceable license. Yes, some clauses may focus on such major parts as "documentation", "binary", or "code", but there again, they apply to each of those major parts as a (smaller) whole; not to every isolated sentence, processor instruction, or C++ statement.

The advice I am working from is from Debian and Ubuntu legal teams.

Since your interpretation and/or application of the OpenSSL license seems completely wrong to me, I fear that your interpretation of Debian and Ubuntu legal team advice suffers the same fate. You are certainly entitled to use 3rd party legal opinion about squid -v output requirements, but since they do not present and defend their opinion here, that onus falls on you. Just mentioning their esteemed names is not enough.

this link and statement was apparently sufficient to make the Squid binary safely/legally distributable by anyone who a) did not also package and distribute OpenSSL itself, and b) complied with the OpenSSL license clauses in their own documentation and advertising materials.

Just because somebody finds X sufficient for claiming Y, does not mean that X is sufficient (or even necessary) to claim Y, or that claiming Y itself is something squid -v should care about.

I am sure a lot of folks would like to include their own statements and links in squid -v output. They can claim that doing so allows them to distribute Squid safely/legally. Should we start patching Squid to accommodate their wild claims? Of course not: Claiming something does not make it so. The text being removed in this PR should go through a similar validation process -- if nobody can prove that it is legally necessary, it should be removed.

---

I am worried that this part will take this discussion further astray, but I did not want it to appear as if I am ignoring your request for help:

if you can figure out a good way to add the OpenSSL/SSLeay disclaimers and license to the Squid copyright license files

IIRC, Squid does not contain OpenSSL code.

• If my recollection is correct, then why would you want to add their license to Squid licensing-related files? Doing so would be straightforward (even if you want to make the inclusion conditional), but I do not understand why you would want to do that.
• Otherwise, where is that OpenSSL code?

[yadij]

It doesn't matter what either of us think about the legal situation or the amount of code included. Fact is Debian went and got a formal legal team to consider it and they came back with the verdict that anyone distributing Squid binaries built to use OpenSSL is required to be aware of any comply with those OpenSSL terms and conditions.

The Debian specific way of distributing (and thus all their downstreams, eg Ubuntu) cannot be made compliant with that license combination. As such Debian et al, are forbidden by the legal team from delivering Squid with OpenSSL support until the license collision is resolved. Part of the resolution is to inform anyone building Squid with OpenSSL that this legal situation exists.

You may (as you said initially) think it scary that distributors actually have to do something with care. I do not, and have not encountered anyone who did once the detail was explained. It makes reasonable sense and is relatively easy to comply with by most (non-Debian) Squid distributors.

As an extra bonus; keeping both distributors and recipients of those builds informed of the situation helps them to self-enforce the legality and avoid us getting dragged into GPL compliance battles.

[yadij]

@rousskov do you want to update this to check for OpenSSL v3 where their license change means we can omit the "scary" sentence, or close this PR entirely?

[rousskov]

@rousskov do you want to update this to check for OpenSSL v3

I do not have the time. Feel free to do that, of course. It would be better than nothing.

OpenSSL v3 where their license change means we can omit the "scary" sentence

As you know, I think we can omit the scary sentence right now, for all OpenSSL versions. I just do not have the time to deal with the invalid (IMHO) arguments for keeping it, especially when they start using insults and vague (as in difficult to verify) references to a higher authority.

or close this PR entirely?

I will close this PR if a version-specific removal is merged. This PR branch can be reused for that if the developer prefers.

[yadij]

Leaving this PR open for future update. Pending OpenSSL v3.0 availability.

[yadij]

Closing this as it has been superseded by PR #694