giltene
commented
6 months ago TLDR: Zulu binaries are real, 100% Open Source. It is diligently packaged as such. Unlike many other binary packages that are not quite that.
(copied from prior clear response to the same gaslighting comments above posted elsewhere).
"Open Source" is a very well-defined term. That definition has long been documented by the OSI, at opensource.org, under "Open Source Definition". As someone who has been producing and contributing Open Source software for well over 30 years, and since well before this definition was solidified, I can assure you that Zulu carefully adheres to both the Open Source definition and to open source principles. It also carefully adheres to the various OSS licenses associated with the various parts that make up the overall Zulu package. We take this adherence very seriously. More so than most. That adherence comes with a fairly large amount of work under the covers since Zulu distributes (literally) hundreds of new binary artifacts per quarter, requiring careful tracking of each to its specific source code in order to be able to actually comply with OSS source code availability requirements as spelled out in the actual licenses involved.
Contrary to the [not so popular] belief held by some, "posting some version of the source code for some specific package variant on GitHub" does nothing to satisfy many actual OSS license requirements, including several that are part of the OpenJDK code base. A common theme in those OSS licenses is the requirement for the source code being shared to be the actual source code used to build the actual binary in question.
For a specific example, GPLv2 (under which large parts of OpenJDK are licensed) includes very specific requirements for making source code available. Under section 3, which describes the source code sharing requirements for distributing binaries under GPLv2, the license lists only 3 ways by which one can comply with the source-code availability requirements when distributing binaries. "Look up the source on GitHub by version" is not one of them, and doing so does not relieve one of the burden of adhering to the actual GPLv2 requirements.
IANAL, but to my understanding, wherever you find a binary that is (at least in part) licensed under GPLv2, and none of the 3 specific means of satisfying the source code availability requirements is available to you as the holder of that binary, you are looking at an OSS license violation. Those are unfortunately quite common, including with many binary artifacts that can be found here on GitHub, and whose as-is re-distribution would plainly violate GPLv2 requirements as some downstream receiver of the binary has no way by which to request or locate the exact source code used to build the binary they have...
Zulu binary packages carefully avoid this pitfall by transmitting the information needed to receive all required source code within the actual binary package. This satisfies e.g. section 3.b of GPLv2, as well as similar requirements in other OSS licenses related to Zulu contents.
There is nothing hard about getting Zulu source code. The instructions for doing so sit right there in the readme.txt in the base directory of each binary. And yes, the details can easily differ from binary to binary since the specific ID codes needed for each binary artifact may vary, even within a given quarterly update release.
jochenchrist
I was looking for the source an Azul zulu build in an Alpine container, and I have some concerns about their open source and license status. See the thread in https://github.com/zulu-openjdk/zulu-openjdk/issues/263
TLDR: Zulu sources are only available by email, so IMHO not really open source. I would have a hard time to recommend these as "open source".