<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Yes Sebastian, that is my point precisely.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">As far as following OpenJDK license—the use-case is a bit different for the runtime versus a development tool like jextract.</span><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""/><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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 <span dir="auto" class="">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.</span></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">GNU themselves give the following caveat on GPL license trade-offs [<a href="https://www.gnu.org/licenses/why-not-lgpl.html" dir="auto" class="">https://www.gnu.org/licenses/why-not-lgpl.html</a><span style="color: var(--text-color); background: var(--bg-color);" class="">]</span><span style="color: var(--text-color); background: var(--bg-color);" class="">:</span></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">>> <span dir="auto" class=""><i dir="auto" class="">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.</i></span></div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><div dir="auto" class=""><br class=""/></div>(I’m not arguing in favor of LGPL, but the reasoning is the same)<br class=""/><div dir="auto" class=""><br class=""/></div>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.</div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""/></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Licenses I would be happier with include: Eclipse EPL, Apache, MIT, BSD, CDDL, Mozilla MPL, etc.</span><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><div dir="auto" class=""> </div><div dir="auto" class=""><br class=""/></div>—Shane</div><div><br class=""/><blockquote type="cite" class=""><div class="">On Mar 20, 2023, at 4:51 AM, Sebastian Stenzel <<a href="mailto:sebastian.stenzel@gmail.com" class="">sebastian.stenzel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"/><div class=""><meta http-equiv="content-type" content="text/html; charset=UTF-8" class=""/><div dir="auto" class=""><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="">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</span><br class=""/></blockquote><div class=""><br class=""/></div>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.<div class=""><br class=""/></div><div class="">Cheers, Sebastian<br class=""/><br class=""/><div dir="ltr" class=""><blockquote type="cite" class=""><br class=""/>Am 20.03.2023 um 12:23 schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" class="">maurizio.cimadamore@oracle.com</a>>:<br class=""/><br class=""/></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""/><p class="">Hi,<br class=""/>
jextract being GPLv2 just follows what the rest of OpenJDK is
doing.</p><p class="">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 class=""/>
</p><p class="">Does that address your concern?</p><p class="">Regards<br class=""/>
Maurizio<br class=""/>
</p><p class=""><br class=""/>
</p>
<div class="moz-cite-prefix">On 20/03/2023 02:11, Shane Pearlman
wrote:<br class=""/>
</div>
<blockquote type="cite" cite="mid:mkWhldswZ4ATgjwq0UXX_H5pLh-slp98fSV0375sUGH6rdtRfmqNvliPlCbiUjygNdXIKFXN0zoRQs4LTKmt15mRaWzTPQfPoTKH4tY8mPc=@pm.me" class="">
What’s the reasoning for licensing a tool like this under the
GPLv2?
<div dir="auto" class=""><br class=""/>
</div>
<div dir="auto" class="">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.</div>
<div dir="auto" class=""><br class=""/>
</div>
<div dir="auto" class=""><span dir="auto" style="color: var(--text-color);
background: var(--bg-color);" class="">Even the code generation
template classes are under GPLv2, which is enough to prevent
me from using jextract generated bindings in </span><span style="color: var(--text-color); background: var(--bg-color);" class="">my
non-GPL</span><span dir="auto" style="color:
var(--text-color); background: var(--bg-color);" class=""> projects. </span><span style="color: var(--text-color); background: var(--bg-color);" class="">Maybe
someone’s</span><span dir="auto" style="color:
var(--text-color); background: var(--bg-color);" class=""> reading of
the license is that it is permissible, but is the uncertainty
really necessary?</span></div>
<div dir="auto" class=""><span dir="auto" style="color: var(--text-color);
background: var(--bg-color);" class=""><br class=""/>
</span></div>
<div dir="auto" class=""><span dir="auto" style="color: var(--text-color);
background: var(--bg-color);" class="">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.<caret class=""></caret></span></div>
<div dir="auto" class=""><span dir="auto" style="color: var(--text-color);
background: var(--bg-color);" class=""><br class=""/>
</span></div>
—Shane</blockquote>
</div></blockquote></div></div><span id="cid:3A86C388-D4F6-4F98-84CE-D721B7DF5FCD"><smime.p7s></span></div></blockquote></div><br class=""/></body></html>