Hi, I think this deserves a bit more context for people not following apache-legal and with all matters legal I have understanding for this.
The discussion is this: It is well established, that we can rely on GPLv2-CPE runtime libraries (aka the JDK, OpenJFX). It is a bit of a gray area why we may link against the JDK (is it a system dependency or is the CPE enough or maybe both arguments hold). What is under discussion is, whether or not we may include GPLv2-CPE binries into binary convenience releases. There are multiple open questions, that need answering: a) what are the requirements of the GPLv2-CPE from the perspective of the ASF b) what is the definition of the term "executable" c) what is the definition of the term "independend module" the list quoted below was my reply on apache legal, but in the mean time another aspect was brought to my attention: https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html it might or might not be relevant for the questions. In java for example a single class file could be considered executable. But this whole discussion is only relevant, if all the above questions are answered and apache legal (or the foundation board) agree. Yes, we as the Apache NetBeans community need to form an opinion, but all that is meaningless, if apache legal/the board NACKs that. The thread on apache-legal is still running - a bit slow, but maybe that is a good sign. I say we should give the lawyers a bit more time and not jump to action. I don't want to be misunderstood: I want Apache NetBeans to be able to bundle GPLv2-CPE binaries, I openly question whether the "system dependency theory" for java holds today, BUT at this time we should focus on the archivable in the ASF framework today: a) it was already established, that installer may install GPLv2-CPE binaries b) the ASF policy does not bind outside parties c) we already have options to install GPLv2-CPE dependencies when needed, they currently are just a PITA in corner cases So at this point in time I think forming consensus for one of the questions is not helpful. I don't think we have consensus. I there are people out there wondering what they could do to help: Work on the points enumerated in the last paragraph, if you have connections to the FSF/Oracle get the lawyers to create clear definitions for the license and if you have connections to ASF/Oracle try to get the lawyers to talk to each other. For everyone that reaches this point: Thank you for your attention. Greetings Matthias Am Mittwoch, den 01.07.2020, 15:04 +0200 schrieb Jaroslav Tulach: > Hi. > The purpose of this email is to build consensus of what the term > "executable" means in the context of Apache NetBeans project. > > There has been a discussion on [legal mailing list]( > https://lists.apache.org/thread.html/r0482d10f784f26f72b836f8480a13c7876ef8499f1f285166b1cf241%40%3Clegal-discuss.apache.org%3E) > and it turns out that understanding the meaning of term "executable" > is > quite important. In order to [Avoid Unnecessary Discussion & Stating > Lazy > Consensus](http://community.apache.org/committers/lazyConsensus.html) > I am > calling a lazy consensus vote. I am convinced such a lazy vote has to > happen here, at the Apache NetBeans project, as only the Apache > NetBeans > PMC can decide what forms "executable" in our project and what does > not. > > Matthias offered following classification of various Java artifacts > on the > legal list: > > 1. A jlinked image. This is a directory structure consisting of the > required modules of the JDK and all other required modules. > Distribution would be done as a ZIP or packed as an installer. > > 2. A fat jar - with all dependencies folded into one JAR > > 3. A directory structure with several files (jars and other > resources). This directory would be packed as a ZIP and > distributed. > > 4. An installer image, that contains the directory structure > described > before, but makes the distributable executable and helps the user > installing the application > > 5. A packaging of several libraries into a containing binary. NBMs, > WARs and OSGI jars are samples for this, in all formats the outer > container holds/can hold other libraries. > > 6. Individual library jars > > 7. In the future AOT compiled binaries (currently graalvm native > image, in the future maybe integrated into the JDK) > > For Matthias 1, 2, 3, 4 and 7 are executables. I fully support his > opinion > and I want this to become the official definition of "executable" for > the > Apache NetBeans project. Let's give the usual 72h for stating > objections. > Should nobody object, then following artifacts of [NetBeans 12.0]( > https://netbeans.apache.org/download/nb120/nb120.html) are going to > be > treated as executables: > > Binaries: > * netbeans-12.0-bin.zip (SHA-512, PGP ASC) > Installers: > * Apache-NetBeans-12.0-bin-windows-x64.exe (SHA-512, PGP ASC) > * Apache-NetBeans-12.0-bin-linux-x64.sh (SHA-512, PGP ASC) > * Apache-NetBeans-12.0-bin-macosx.dmg (SHA-512, PGP ASC) > > Other artifacts are *not* executables, namely: > * Source: netbeans-12.0-source.zip (SHA-512, PGP ASC) > * Javadoc for this release is available at > https://bits.netbeans.org/12.0/javadoc > * Bits uploaded to Maven central for release 12.0 > * NBMs on our update center > > Shall the lazy vote end with a consent, then Apache NetBeans project > will > use here-in proposed classification for artifacts of release 12.0 as > well > as future releases, unless redefinition of the term "executable" gets > (lazy) voted again on this mailing list. > > Thanks Matthias for providing the classification. Thanks everybody in > advance for your support, lazy consent or even disagreement. > -jt --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
