Following the following comment:
3) Can we use GPL CPE in Apache Foo to do XYZ?
Open a specific Jira issue.
I have a specific question that involves Apache NetBeans (more are likely to follow):
Could Apache NetBeans bundle the javac (under the GPLv2 with Classpath Exception) with its convenience binaries?
More details follow.
Apache NetBeans is a Rich Client Platform and an Integrated Development Environment (IDE). The IDE supports multiple languages, but the part of the IDE that supports development in the Java programming language is important here. This is mostly an end-user application (as opposed to libraries, like Apache Lucene), althought some non-Apache distributions also exist.
The Java editor in (Apache) NetBeans is using the JDK's Java compiler, javac, to parse the user's source code, to provide various Java IDE features (like, but not only, code completion, refactoring, semantic highlighting). This is done for more than a decade. Before joining the ASF, NetBeans has had its own version of the compiler (nb-javac), which was distributed together with NetBeans. With the transition to Apache, an option has been added to NetBeans to use javac that is in the JDK on which NetBeans runs (for JDK 9+) and the nb-javac is no longer maintained by the Apache NetBeans project. The user is however given an option to download and install nb-javac, which may improve the stability, and allow to use the NetBeans Java editor while running on JDK 8.
While I believe the current status is reasonably in line with the Apache policy it has drawbacks in convenience for our user community, and potentially much more work for the testing and developer communities. The javac is also used by tools like Apache Ant or Apache Maven. But, I believe, that they, unlike Apache NetBeans, use fairly straightfoward, simple and broadly used interfaces to work with javac. Apache NetBeans, on the other hand, is using javac much deeper and more broad way, e.g. it uses the javac's abstract syntax tree (AST) model, including AST for sources that are erroneous (as, while the user types/works in the IDE, the sources are erroneous very often, if not most of the time). And a particular combination of javac and NetBeans may handle the sources less than ideally - e.g. by failing with an exception, failing to perform requested action, performing slower, etc. The situation is improving with every OpenJDK and NetBeans release, but not all users are willing to run NetBeans on the most recent version of JDK. So those running an older JDK may run into issues, depending on their project's size and complexity.
The user may decide to install the nb-javac, which should provide better (and more tested) behavior even on older JDKs, but having to install something separately breaks the out-of-the-box experience, and for some user's may be difficult. So the current state has drawbacks for the user community.
The testing community, ideally, should test on multiple JDKs, with and without nb-javac, which leads to much more (human and machine) effort.
The dev community needs to write code that supports all JDKs since 9 (or 11) as best as it can, which means all access to the new APIs using reflection, more testing, and overall more work etc.
My proposal here would be that Apache NetBeans would:
-be allowed to include the nb-javac (GPLv2 with Classpath Exception) together with its convenience binaries. The Apache NetBeans project as such would not be releasing the nb-javac, and would use an unmodified version released by some other party.
-keep the ability to run without nb-javac, although (depending on the project's decision) with the option to only support selected JDKs for this mode, like possibly only the most recent released version of JDK, or alike.
The alternatives I can see include:
1. continue with the current approach, with its effect on all the user, test and dev communities.
2. restrict very specifically on which JDK's Apache NetBeans can run (e.g. the lastest released JDK at the time NetBeans was released)
3. use a different Java parser.
But, out of these options, only 1. appears to be at all realistic to me. 2. would have detrimental effect on the user community, and the effort needed for 3. is likely to be vastly bigger than what the project can undertake.
So the only alternative I can see is to continue with the current approach, with the effects on all the communities.
It is difficult for me to see any significant drawback in bundling nb-javac with Apache NetBeans convenience binaries. For users, testers and devs, this should be simpler. In the (unlikely, IMO) scenario that there are any downstream distributions that don't want to distribute nb-javac, they would use the ability to use the JDK's javac.