GPL license

Mon May 8 18:26:04 UTC 2023

Hi,
we have update the jextract download page [1] with some clarifications 
re. what's affected by the jextract license:

>   * The output of jextract does not result in the generated output
>     being affected by the jextract license.
>
I hope this addresses the concerns.

Cheers

Maurizio

[1] - https://jdk.java.net/jextract/

On 21/03/2023 23:29, Maurizio Cimadamore wrote:
> 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>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230508/78116586/attachment-0001.htm>