<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi,<br>
we have update the jextract download page [1] with some
clarifications re. what's affected by the jextract license:</p>
<p>
<blockquote type="cite">
<ul class="spread">
<li>The output of jextract does not result in the generated
output
being affected by the jextract license.</li>
</ul>
</blockquote>
</p>
<p>I hope this addresses the concerns.</p>
<p>Cheers</p>
<p>Maurizio</p>
<p>[1] - <a class="moz-txt-link-freetext" href="https://jdk.java.net/jextract/">https://jdk.java.net/jextract/</a><br>
</p>
<div class="moz-cite-prefix">On 21/03/2023 23:29, Maurizio
Cimadamore wrote:<br>
</div>
<blockquote type="cite" cite="mid:5a5056ff-a079-8560-3562-b496ac2c926e@oracle.com">Thanks
for all the comments. It is good (and realistic) feedback, which I
appreciate.
<br>
<br>
As you can imagine, there will need to be some kind of internal
discussion on this, to see what options do we have available (if
any).
<br>
<br>
Maurizio
<br>
<br>
<br>
On 21/03/2023 22:02, Shane Pearlman wrote:
<br>
<blockquote type="cite">Regarding Sebastian's suggestion, I'm not
sure this approach is compatible with the current, generic GPL
license:
<br>
<blockquote type="cite">
<blockquote type="cite">Thus I would support publishing the
templates under a permissive license.
<br>
</blockquote>
</blockquote>
Here's the GPL exception used by GNU's GCC, so that generated
binaries are not "infected" by the copyleft
[<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/gcc-mirror/gcc/blob/fac64bf456cf56f0c6309d21286b7eaf170f668e/COPYING.RUNTIME__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5eRhKVQ3A$">https://urldefense.com/v3/__https://github.com/gcc-mirror/gcc/blob/fac64bf456cf56f0c6309d21286b7eaf170f668e/COPYING.RUNTIME__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5eRhKVQ3A$</a>
]:
<br>
<blockquote type="cite">
<blockquote type="cite">This GCC Runtime Library Exception
("Exception") is an additional permission under section 7 of
the GNU General Public License, version 3 ("GPLv3"). It
applies to a given file (the "Runtime Library") that bears a
notice placed by the copyright holder of the file stating
that the file is governed by GPLv3 along with this
Exception.
<br>
When you use GCC to compile a program, GCC may combine
portions of certain GCC header files and runtime libraries
with the compiled program. The purpose of this Exception is
to allow compilation of non-GPL (including proprietary)
programs to use, in this way, the header files and runtime
libraries covered by this Exception.
<br>
</blockquote>
</blockquote>
An exception like that (translated for Java) could permit
jextract generated code to be used freely. The OpenJDK may not
have such an exception, due to the fact that prior to
Substrate/Graal native compilation, there was no static linking
in Java which tends to mix one's code altogether with the
standard library and runtime itself into a binary executable. I
don't believe Oracle has yet addressed that problem for the open
source version of Graal native image.
<br>
<br>
To retain compatibility with GPL–which would permit jextract
code to be integrated or distributed with OpenJDK in the
future–and allow free use of jextract code elsewhere, I suggest
adopting a dual license such as those used by javacpp and jna.
<br>
<br>
javacpp
[<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/bytedeco/javacpp/blob/ea4e5f7ca6556455f8e1117ae369f33ca92cd6ca/LICENSE.txt__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ezs0dSEg$">https://urldefense.com/v3/__https://github.com/bytedeco/javacpp/blob/ea4e5f7ca6556455f8e1117ae369f33ca92cd6ca/LICENSE.txt__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ezs0dSEg$</a>
]:
<br>
<blockquote type="cite">
<blockquote type="cite">You may use this work under the terms
of either the Apache License, Version 2.0, or the GNU
General Public License (GPL), either version 2, or any later
version, with "Classpath" exception (details below).
<br>
</blockquote>
</blockquote>
jna
[<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/java-native-access/jna/blob/e96f30192e9455e7cc4117cce06fc3fa80bead55/LICENSE__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ehihnx4A$">https://urldefense.com/v3/__https://github.com/java-native-access/jna/blob/e96f30192e9455e7cc4117cce06fc3fa80bead55/LICENSE__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ehihnx4A$</a>
]:
<br>
<blockquote type="cite">
<blockquote type="cite">Java Native Access (JNA) is licensed
under the LGPL, version 2.1 or later, or (from version 4.0
onward) the Apache License, version 2.0.
<br>
</blockquote>
</blockquote>
Under a dual license, users would be permitted to license
jextract under the more permissive Apache license rather than
the GPL. Apache still requires distributors of compiled,
generated jextract bindings in proprietary projects to provide
attribution and a copy of the Apache license required by clause
4A:
<br>
<blockquote type="cite">
<blockquote type="cite">You must give any other recipients of
the Work or Derivative Works a copy of this License
<br>
</blockquote>
</blockquote>
In my opinion, the ideal solution is to adopt a dual license for
the entire jextract repo, possibly with an exception allowing
generated bindings to be used freely without attribution or
distribution of the Apache license, however that burden is small
enough that it may not warrant invention of a novel,
non-standard licensing clause.
<br>
<br>
–Shane
<br>
<br>
<blockquote type="cite">On Mar 21, 2023, at 1:02 PM, Shane
Pearlman <a class="moz-txt-link-rfc2396E" href="mailto:shanepearlman@pm.me"><shanepearlman@pm.me></a> wrote:
<br>
<br>
Yes Sebastian, that is my point precisely.
<br>
<br>
As far as following OpenJDK license—the use-case is a bit
different for the runtime versus a development tool like
jextract.
<br>
<br>
I expect most large binding projects will want to modify this
code base to do things that are too frail or particular to
their C or Java library to do in a general purpose CLI
tool—i.e. generating Javadocs by extracting them from the
target project sources, renaming functions based on patterns,
generating higher level wrappers around the straight bindings,
binding implementation alternatives to tradeoff performance
with safety, or automatic type conversion.
<br>
<br>
Case-in-point, there was an earlier message on this list about
generating common cross-platform interfaces for the concrete,
C pre-processed, platform specific jextraxt bindings classes.
I agree with the answer: that is a library specific problem
which cannot be solved in the general case, but the jextract
implementation classes and libclang bindings can help the
author script a custom solution if his library is conventional
and large enough to justify automation.
<br>
<br>
The libclang C API itself, for instance, has some “object
oriented” functions that follow a naming convention and pass
the first argument as the receiver “object”. You can imagine
if the binding project had a target codebase with very strong
conventions, the author will want to take advantage of them.
<br>
<br>
For reference, the SkiaSharp project has built its own code
generation tool according to the structure of the skia
libraries. There are several huge bindings projects from
Mono/.NET and they don’t all use the same tools or even the
same C++ parsing frameworks. Custom tools are the real world
approach to this messy task of binding, even multiple custom
tools within the same organization and client language.
<br>
<br>
GNU themselves give the following caveat on GPL license
trade-offs
[<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://www.gnu.org/licenses/why-not-lgpl.html__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5fruQdn0w$">https://urldefense.com/v3/__https://www.gnu.org/licenses/why-not-lgpl.html__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5fruQdn0w$</a>
]:
<br>
<blockquote type="cite">
<blockquote type="cite">Using the ordinary GPL is not
advantageous for every library. There are reasons that can
make it better to use the Lesser GPL in certain cases. The
most common case is when a free library's features are
readily available for proprietary software through other
libraries. In that case, the library cannot give free
software any particular advantage, so it is better to use
the Lesser GPL for that library.
<br>
</blockquote>
</blockquote>
(I’m not arguing in favor of LGPL, but the reasoning is the
same)
<br>
<br>
There are some projects from various places that can
substitute parts of OpenJDK under more permissive licenses,
but nobody else has a complete “classpath” standard library.
That’s the main reason OpenJDK can get away with copyleft
terms, and there’s so much legacy it would probably be
impossible to relicense it anyway. On the other hand,
jextract is young and small and would be easy to relicense at
this point. If there is a question about OpenJDK
compatibility, I believe that can be solved by dual licensing
under GPL *and* a permissive license.
<br>
<br>
Licenses I would be happier with include: Eclipse EPL, Apache,
MIT, BSD, CDDL, Mozilla MPL, etc.
<br>
<br>
<br>
—Shane
<br>
<br>
<blockquote type="cite">On Mar 20, 2023, at 4:51 AM, Sebastian
Stenzel <a class="moz-txt-link-rfc2396E" href="mailto:sebastian.stenzel@gmail.com"><sebastian.stenzel@gmail.com></a> wrote:
<br>
<br>
<blockquote type="cite">While the template files are marked
as GPLv2 (as they are checked into the repository), what
comes out of jextract does not have any license header
<br>
</blockquote>
One could argue that „what comes out of jextract“ is a
derivative work of the templates. Thus I would support
publishing the templates under a permissive license.
<br>
<br>
Cheers, Sebastian
<br>
<br>
<blockquote type="cite">Am 20.03.2023 um 12:23 schrieb
Maurizio Cimadamore
<a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a>:
<br>
<br>
<br>
Hi,
<br>
jextract being GPLv2 just follows what the rest of OpenJDK
is doing.
<br>
<br>
I'd like to understand better what your use case is before
commenting further: are you worried jextract will generate
GPLv2 code? Because that is NOT the case. While the
template files are marked as GPLv2 (as they are checked
into the repository), what comes out of jextract does not
have any license header (or at least, that's the spirit,
if you are experiencing otherwise, I'd say that's a bug).
<br>
<br>
Does that address your concern?
<br>
<br>
Regards
<br>
Maurizio
<br>
<br>
<br>
<br>
On 20/03/2023 02:11, Shane Pearlman wrote:
<br>
<blockquote type="cite">What’s the reasoning for licensing
a tool like this under the GPLv2?
<br>
<br>
Code generators often need to be modified or adapted for
large bindings projects, and the classes in
org.openjdk.jextract.impl and
org.openjdk.jextract.clang could be quite useful as a
starting point. Under the current license, however, I
will probably have to roll my own.
<br>
<br>
Even the code generation template classes are under
GPLv2, which is enough to prevent me from using jextract
generated bindings in my non-GPL projects. Maybe
someone’s reading of the license is that it is
permissible, but is the uncertainty really necessary?
<br>
<br>
That said, I am excited for the Panama project to
deliver what looks to be a very well designed solution
to a major, decade-long problem with Java.
<br>
<br>
—Shane
<br>
</blockquote>
</blockquote>
<smime.p7s>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
</body>
</html>