<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>