GPL license

Tue Mar 21 23:29:38 UTC 2023

Thanks for all the comments. It is good (and realistic) feedback, which 
I appreciate.

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

Maurizio

On 21/03/2023 22:02, Shane Pearlman wrote:
> Regarding Sebastian's suggestion, I'm not sure this approach is compatible with the current, generic GPL license:
>>> Thus I would support publishing the templates under a permissive license.
> Here's the GPL exception used by GNU's GCC, so that generated binaries are not "infected" by the copyleft [https://urldefense.com/v3/__https://github.com/gcc-mirror/gcc/blob/fac64bf456cf56f0c6309d21286b7eaf170f668e/COPYING.RUNTIME__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5eRhKVQ3A$ ]:
>>> 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.
>>> 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.
> 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.
>
> 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.
>
> javacpp [https://urldefense.com/v3/__https://github.com/bytedeco/javacpp/blob/ea4e5f7ca6556455f8e1117ae369f33ca92cd6ca/LICENSE.txt__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ezs0dSEg$ ]:
>>> 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).
> jna [https://urldefense.com/v3/__https://github.com/java-native-access/jna/blob/e96f30192e9455e7cc4117cce06fc3fa80bead55/LICENSE__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5ehihnx4A$ ]:
>>> 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.
> 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:
>>> You must give any other recipients of the Work or Derivative Works a copy of this License
> 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.
>
> –Shane
>
>> On Mar 21, 2023, at 1:02 PM, Shane Pearlman <shanepearlman at pm.me> wrote:
>>
>> 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://urldefense.com/v3/__https://www.gnu.org/licenses/why-not-lgpl.html__;!!ACWV5N9M2RV99hQ!Kc7RnIZJoBZinQDJFwsEICB-TrxujuavKEMQdMk_i0fzANts8VnNbOS5ZYi7cXrCRD0ISUbgZlZ-85znqvZQe5fruQdn0w$ ]:
>>>> 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>
>