GPL license

[Shane Pearlman]

Yes Sebastian, that is my point precisely.

As far as following OpenJDK license—the use-case is a bit different for the runtime versus a development tool like jextract.

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.

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.

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.

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.

GNU themselves give the following caveat on GPL license trade-offs [https://www.gnu.org/licenses/why-not-lgpl.html]:
>> 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’m not arguing in favor of LGPL, but the reasoning is the same)

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.

Licenses I would be happier with include: Eclipse EPL, Apache, MIT, BSD, CDDL, Mozilla MPL, etc.

—Shane

> On Mar 20, 2023, at 4:51 AM, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>
>> 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
>
> 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.
>
> Cheers, Sebastian
>
>> Am 20.03.2023 um 12:23 schrieb Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>
>> 
>>
>> Hi,
>> jextract being GPLv2 just follows what the rest of OpenJDK is doing.
>>
>> 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).
>>
>> Does that address your concern?
>>
>> Regards
>> Maurizio
>>
>> On 20/03/2023 02:11, Shane Pearlman wrote:
>>
>>> What’s the reasoning for licensing a tool like this under the GPLv2?
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> —Shane
>
> <smime.p7s>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230321/d1111fb1/attachment.htm>