You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2021/05/16 09:12:43 UTC
nb-javac@16.0.0.0 is covered by "Classpath exception"
Hello guys,
let's continue the tradition of manual inspection of nb-javac sources[1][2].
NetBeans project downloads both nb-javac JAR files from Maven central - the
standard Java way of distributing, using and archiving Java libraries/
artifacts. Essential part of that system is `pom.xml` file with a mandatory
`<license>` element. In case of nb-javac@16.0.0.0 it says:
https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0/jar
"Licenses: GPLv2-CPE". As that license comes directly from the Oracle's nb-
javac project:
https://github.com/oracle/nb-javac/blob/release124/make/langtools/netbeans/nb-javac/pom-nb-javac.xml#L18
and the intention of that element is to state the license of the uploaded
Maven central artifacts, it is natural for a Java developer to conclude that
"nb-javac (as uploaded to Maven central) is fully licensed under GPLv2-CPE".
In addition to the above evidence, let's do a manual verification:
```bash
$ wget https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/
16.0.0.0/nb-javac-16.0.0.0-sources.jar
$ unzip nb-javac-16.0.0.0-sources.jar
$ rm nb-javac-16.0.0.0-sources.jar
```
now one can build the two nb-javac JARs successfully with:
```bash
$ JAVA_HOME=/jdk-8/ ant -f ./make/langtools/netbeans/nb-javac/build.xml
```
but let's rather inspect the sources:
```bash
$ grep -r "GNU General Public License" . -l | wc -l
747
$ grep -r "GNU General Public License" . -l | while read X; do grep
Classpath.*exception "$X" || echo Missing $X; done | grep Missing
Missing ./LICENSE.txt
Missing ./src/jdk.jdeps/share/man/jdeprscan.1
Missing ./src/jdk.jdeps/share/man/jdeps.1
Missing ./src/jdk.jdeps/share/man/javap.1
Missing ./src/jdk.compiler/share/man/serialver.1
Missing ./src/jdk.compiler/share/man/javac.1
```
e.g. there is 747 files that contain "GPL" header and all of them but license
and manual pages (not used in the nb-javac JARs) contain the "Classpath
exception" header.
The manual inspection confirms that Maven central licensing information at
https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0/jar
is correct and both nb-javac@16.0.0.0 binary JAR files are covered by GPLv2-CPE
license.
Thanks in advance for checking my conclusion.
-jt
[1] https://lists.apache.org/thread.html/
r821d9e9fdc8d9fd5663e7c326d25e4626e1a27eb13e45f4d639ea199%40%3Cdev.netbeans.apache.org%3E
[2] https://lists.apache.org/thread.html/
rb5d091662f88dafb2fd878a0acc5e5bdb80ddfb17b47bfbff248b4d7%40%3Cdev.netbeans.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Build nb-javac from sources
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 29 May 2021 at 07:19, Jaroslav Tulach <ja...@gmail.com> wrote:
> > It can't be here can it, from a licensing perspective?
>
> The GPL-CPE sources would remain hosted where they are - e.g. in the
> https://github.com/openjdk/jdk
> repository. The only thing that would need to be in here is the build script.
> I assume such build script can be Apache licensed.
Well, that was the question! Your repository you linked to has a
GPL+CPE license and a load of files with that header. What can be
re-licensed and donated, or removed?
> Such a verification would be in the build script.
>
> > then it's easier for PMC review of the
> > process, etc.
>
> +1 having the build script properly reviewed by PMC would simplify the
> verification of correctness
Yes, but if it proves impossible to have the source patching side
here, then it would be good to have at least the verification and
compilation from patched sources (published on Maven Central) as part
of the NB build?
> Alternative: Do it as with launchers: Regular users download pre-built binary.
> The final build runs from sources.
I'm not sure that's a useful model, and I (and others) have argued for
doing separate official ASF releases of launchers and other native
binaries so that all main source builds use downloads. The two
different paths to build have caused us release issues before, and
will likely be more of a problem with things like the new macOS Swift
launcher, etc. Having a common path to build the IDE (across all
users and OS) is surely better?
The wording of CPE also makes publishing of pre-built binaries of
nb-javac from here impossible anyway, so we'd still need to resolve
that issue.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Build nb-javac from sources
Posted by Jaroslav Tulach <ja...@gmail.com>.
Thanks for your comments Neil...
@ May 27 2021 @
> On Wed, 26 May 2021 at 09:45, Jaroslav Tulach <ja...@gmail.com>
wrote:
> > Do you think these wrappers and the build script should become part of a
> > NetBeans repository? Or is it better to get it working in a separate
> > repository - like the one I have?
>
> It can't be here can it, from a licensing perspective?
The GPL-CPE sources would remain hosted where they are - e.g. in the
https://github.com/openjdk/jdk
repository. The only thing that would need to be in here is the build script.
I assume such build script can be Apache licensed.
> However ...
>
> > Adding a RAT check to verify only "Classpath exception" files are imported
> > from the OpenJDK repository would certainly be a step towards the
> > desirable state and it could prevent human mistakes when releasing the
> > bits.
>
> Ideally the aspect that verifies headers and builds from patched
> sources would be here IMO,
Such a verification would be in the build script.
> then it's easier for PMC review of the
> process, etc.
+1 having the build script properly reviewed by PMC would simplify the
verification of correctness
The next question is: Should such build be part of regular NetBeans build?
E.g. should it be invoked everytime someone invokes
```bash
nbbuild$ ant build
```
Downside: The build requires checkout of the whole openjdk repository and even
building takes quite some time.
Consideration: there already is a build of `langtools-9.zip` in the build
process. We could replace it by building nb-javac from sources PMC trusts?
Alternative: Do it as with launchers: Regular users download pre-built binary.
The final build runs from sources.
I guess I'll continue working in my current repository for now with the goal
to produce 100% working version. I'll keep in mind we want a system easily
reviewable by PMC. I'll continue to assume that the build script assembling
everything together can be Apache licensed.
-jt
> And we potentially get the basis of something that
> could be used for other CPE dependencies here or in other ASF projects
> should that arise.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Build nb-javac from sources was: nb-javac@16.0.0.0 is covered by
"Classpath exception"
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 26 May 2021 at 09:45, Jaroslav Tulach <ja...@gmail.com> wrote:
> Do you think these wrappers and the build script should become part of a
> NetBeans repository? Or is it better to get it working in a separate
> repository - like the one I have?
It can't be here can it, from a licensing perspective? However ...
> Adding a RAT check to verify only "Classpath exception" files are imported from
> the OpenJDK repository would certainly be a step towards the desirable state
> and it could prevent human mistakes when releasing the bits.
Ideally the aspect that verifies headers and builds from patched
sources would be here IMO, then it's easier for PMC review of the
process, etc. And we potentially get the basis of something that
could be used for other CPE dependencies here or in other ASF projects
should that arise.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Build nb-javac from sources was: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Neil.
> A longer term approach to this might be to download the sources from
> Maven, validate the license headers (akin to RAT), and build from
> source as part of our build?
Yes, building from (OpenJDK) sources is an approach I'd prefer in the future
as well. Actually I've prototyped it in my https://github.com/jaroslavTulach/
nb-javac/ repository.
The repository contains just a few wrapper files:
https://github.com/JaroslavTulach/nb-javac/tree/
7e51495f3a275a7891ee93b96d092f600990cada/make/langtools/netbeans/nb-javac/src/
nbjavac
and it clones the rest from OpenJDK in an Ant build script:
https://github.com/JaroslavTulach/nb-javac/blob/
7e51495f3a275a7891ee93b96d092f600990cada/make/langtools/netbeans/nb-javac/
build.xml#L91
Do you think these wrappers and the build script should become part of a
NetBeans repository? Or is it better to get it working in a separate
repository - like the one I have?
> > This also raises the question whether the build
> > is reproducible and whether it is ok, that there is no direct
> > connection between the binary artifact ant the source artifact.
>
> Yes, and the ambiguity of the LauncherProperties file does raise a
> question about the current process there too.
Adding a RAT check to verify only "Classpath exception" files are imported from
the OpenJDK repository would certainly be a step towards the desirable state
and it could prevent human mistakes when releasing the bits.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Mar R <ma...@gmail.com>.
What about asking repo owner / Oracle of editing the license and make it
all CPE? After all it's free software, that they made open source, publicy
available and with a very permissive license so I see no reason why they
shouldn't make it also easy to use in case like this if asked
Il giorno lun 17 mag 2021 alle ore 11:19 Neil C Smith <ne...@apache.org>
ha scritto:
> On Sun, 16 May 2021 at 18:28, Matthias Bläsing
> <mb...@doppel-helix.eu> wrote:
> > Oracle decided to add the "Certain source files
> > distributed ..." paragraph, which make the license from my POV
> > problematic as it puts the uncertainty onto the user and not the
> > copyrightholder.
>
> Yes, as far as I'm aware it's mainly this uncertainty which leaves
> GPL+CPE in the Cat X, ask per use, on Legal's side, rather than the
> text of CPE itself. And Legal have still not resolved that we, as
> user, can assert this in the way done here.
>
> > In the future I wonder whether each nb-javac release will need to be
> > vetted like this,
>
> Assuming no clarification in the repository of the terms, then that
> seems to be the only option. And hopefully we can get resolved that
> that approach is OK.
>
> > This also raises the question whether the build
> > is reproducible and whether it is ok, that there is no direct
> > connection between the binary artifact ant the source artifact.
>
> Yes, and the ambiguity of the LauncherProperties file does raise a
> question about the current process there too.
>
> A longer term approach to this might be to download the sources from
> Maven, validate the license headers (akin to RAT), and build from
> source as part of our build?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 16 May 2021 at 18:28, Matthias Bläsing
<mb...@doppel-helix.eu> wrote:
> Oracle decided to add the "Certain source files
> distributed ..." paragraph, which make the license from my POV
> problematic as it puts the uncertainty onto the user and not the
> copyrightholder.
Yes, as far as I'm aware it's mainly this uncertainty which leaves
GPL+CPE in the Cat X, ask per use, on Legal's side, rather than the
text of CPE itself. And Legal have still not resolved that we, as
user, can assert this in the way done here.
> In the future I wonder whether each nb-javac release will need to be
> vetted like this,
Assuming no clarification in the repository of the terms, then that
seems to be the only option. And hopefully we can get resolved that
that approach is OK.
> This also raises the question whether the build
> is reproducible and whether it is ok, that there is no direct
> connection between the binary artifact ant the source artifact.
Yes, and the ambiguity of the LauncherProperties file does raise a
question about the current process there too.
A longer term approach to this might be to download the sources from
Maven, validate the license headers (akin to RAT), and build from
source as part of our build?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
I aggree with the assessment. There are two .java files without CPE
header (in fact without any license header):
make/langtools/netbeans/nb-javac/test/com/sun/tools/javac/parser/DocCommentParserTest.java
Test only, so I would not expect it in the final jar
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/LauncherProperties.java
As Neil already pointed out, this needs fixing (though I don't think this is critical).
It is regrettable, that Oracle still does not manage to declare a clear
and unambiguous license. It was claimed, that Oracle would need to
invent a new license to make this clear. This is untrue. The orginal
GNU Classpath license:
https://www.gnu.org/software/classpath/license.html
is identical to the Oracle version, BUT it does not have the
"uncertainty" element. Oracle decided to add the "Certain source files
distributed ..." paragraph, which make the license from my POV
problematic as it puts the uncertainty onto the user and not the
copyrightholder.
In the future I wonder whether each nb-javac release will need to be
vetted like this, because a big tech company does not manage to get its
license story straigt. This also raises the question whether the build
is reproducible and whether it is ok, that there is no direct
connection between the binary artifact ant the source artifact.
Greetings
Matthias
Am Sonntag, dem 16.05.2021 um 11:12 +0200 schrieb Jaroslav Tulach:
> Hello guys,
> let's continue the tradition of manual inspection of nb-javac sources[1][2].
>
> NetBeans project downloads both nb-javac JAR files from Maven central - the
> standard Java way of distributing, using and archiving Java libraries/
> artifacts. Essential part of that system is `pom.xml` file with a mandatory
> `<license>` element. In case of nb-javac@16.0.0.0 it says:
> https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0/jar
> "Licenses: GPLv2-CPE". As that license comes directly from the Oracle's nb-
> javac project:
> https://github.com/oracle/nb-javac/blob/release124/make/langtools/netbeans/nb-javac/pom-nb-javac.xml#L18
> and the intention of that element is to state the license of the uploaded
> Maven central artifacts, it is natural for a Java developer to conclude that
> "nb-javac (as uploaded to Maven central) is fully licensed under GPLv2-CPE".
>
> In addition to the above evidence, let's do a manual verification:
>
> ```bash
> $ wget https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/
> 16.0.0.0/nb-javac-16.0.0.0-sources.jar
> $ unzip nb-javac-16.0.0.0-sources.jar
> $ rm nb-javac-16.0.0.0-sources.jar
> ```
> now one can build the two nb-javac JARs successfully with:
> ```bash
> $ JAVA_HOME=/jdk-8/ ant -f ./make/langtools/netbeans/nb-javac/build.xml
> ```
> but let's rather inspect the sources:
> ```bash
> $ grep -r "GNU General Public License" . -l | wc -l
> 747
> $ grep -r "GNU General Public License" . -l | while read X; do grep
> Classpath.*exception "$X" || echo Missing $X; done | grep Missing
> Missing ./LICENSE.txt
> Missing ./src/jdk.jdeps/share/man/jdeprscan.1
> Missing ./src/jdk.jdeps/share/man/jdeps.1
> Missing ./src/jdk.jdeps/share/man/javap.1
> Missing ./src/jdk.compiler/share/man/serialver.1
> Missing ./src/jdk.compiler/share/man/javac.1
> ```
> e.g. there is 747 files that contain "GPL" header and all of them but license
> and manual pages (not used in the nb-javac JARs) contain the "Classpath
> exception" header.
>
> The manual inspection confirms that Maven central licensing information at
> https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0/jar
> is correct and both nb-javac@16.0.0.0 binary JAR files are covered by GPLv2-CPE
> license.
>
> Thanks in advance for checking my conclusion.
> -jt
>
>
> [1] https://lists.apache.org/thread.html/
> r821d9e9fdc8d9fd5663e7c326d25e4626e1a27eb13e45f4d639ea199%40%3Cdev.netbeans.apache.org%3E
>
> [2] https://lists.apache.org/thread.html/
> rb5d091662f88dafb2fd878a0acc5e5bdb80ddfb17b47bfbff248b4d7%40%3Cdev.netbeans.apache.org%3E
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
LauncherProperties was: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Jaroslav Tulach <ja...@gmail.com>.
Dne neděle 16. května 2021 12:58:43 CEST, Neil C Smith napsal(a):
> On Sun, 16 May 2021 at 10:12, Jaroslav Tulach <ja...@gmail.com>
wrote:
> > The manual inspection confirms that Maven central licensing information at
> > https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0
> > /jar is correct and both nb-javac@16.0.0.0 binary JAR files are covered by
> > GPLv2-CPE license.
> >
> > Thanks in advance for checking my conclusion.
>
> Agreed! There is one file without a header at all, but I don't think
> it's a particular concern?
>
> ./src/jdk.compiler/share/classes/com/sun/tools/javac/resources/LauncherPrope
> rties.java
Interesting file. It is not available at the Git repository:
https://github.com/oracle/nb-javac/tree/release124/src/jdk.compiler/share/
classes/com/sun/tools/javac/resources
The file was said to be be generated during the build (from files with
"Classpath exception"). However when I do the build from release124 branch
myself, there is nothing:
```bash
$ unzip -v ./make/langtools/netbeans/nb-javac/dist/nb-javac-16.0.0.0-impl.jar
| grep Launcher
```
Yet the file is present in the files uploaded to Maven central:
```bash
$ wget https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/
16.0.0.0/nb-javac-16.0.0.0.jar
$ unzip nb-javac-16.0.0.0.jar
$ rm nb-javac-16.0.0.0.jar
$ grep -r Launcher .
Binární soubor ./com/sun/tools/javac/resources/LauncherProperties$Errors.class
odpovídá
Binární soubor ./com/sun/tools/javac/resources/LauncherProperties.class
odpovídá
```
What is surprising is that the file is present in the JAR, but it is not
referenced by any other file!
Toni, didn't you have some debris on the disk when uploading the JAR files?
-jt
PS: My favorite way to clean a git repository is:
```bash
nb-javac$ rm -rf *; git checkout -f
```
the `.git` directory contains all the necessary data to recover the repository
and `*` doesn't match hidden files like `.git`.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: nb-javac@16.0.0.0 is covered by "Classpath exception"
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 16 May 2021 at 10:12, Jaroslav Tulach <ja...@gmail.com> wrote:
> The manual inspection confirms that Maven central licensing information at
> https://search.maven.org/artifact/com.dukescript.nbjavac/nb-javac/16.0.0.0/jar
> is correct and both nb-javac@16.0.0.0 binary JAR files are covered by GPLv2-CPE
> license.
>
> Thanks in advance for checking my conclusion.
Agreed! There is one file without a header at all, but I don't think
it's a particular concern?
./src/jdk.compiler/share/classes/com/sun/tools/javac/resources/LauncherProperties.java
I still think this process needs documenting and resolving in
LEGAL-563 before we can say nb-javac is not still Cat X though.
Ideally the process outlined (or similar) would be documented and
GPL-CPE moved to Cat B, but we're not quite there yet!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists