www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lahoda (Jira)" <j...@apache.org>
Subject [jira] [Created] (LEGAL-489) Distributing javac (GPLv2+CPE) with Apache NetBeans convenience binaries
Date Thu, 07 Nov 2019 19:05:00 GMT
Jan Lahoda created LEGAL-489:

             Summary: Distributing javac (GPLv2+CPE) with Apache NetBeans convenience binaries
                 Key: LEGAL-489
                 URL: https://issues.apache.org/jira/browse/LEGAL-489
             Project: Legal Discuss
          Issue Type: Question
          Components: Policy Question
            Reporter: Jan Lahoda

h1. Summary

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.
h1. Apache NetBeans

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.
h1. History

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.
h1. The Problem

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.
h1. The Proposal

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.
h1. Alternatives

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.
h1. Drawbacks

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.

This message was sent by Atlassian Jira

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message