Headers and Samples License Issues

[tajmone]

Hi @adamjs, I'm currently working on Ultralight bindings for the PureBasic language. So far, I've managed to successfully port Sample 6 (Intro to C API), and created some custom variations thereof.

Right now, I'm working on a local repository only; before publishing it I'd like to wait that the bindings are more polished, and still need to decide if and how to abstract away some functionality to make it easier to access. But there are also some license issues which are holding me back, and which I need to ask you about.

Since this repository doesn't contain a LICENSE file, in my repository I had to include a script that downloads the latests pre-compiled Ultralight binaries and unpacks the DLLs and the C/C++ headers to project folders which are ignored by Git.

The Ultralight header sources contain an explicit copyright statement:

/// Copyright (C) 2020 Ultralight, Inc. All rights reserved.

with the exception of the JavaScriptCore/*.h headers, which are Copyright by Apple Inc. and do contain an explicit license text within the comments.

If the Ultralight C/C++ headers (here and elsewhere) came with a common FOSS license, it would make it easier for me to include them in my bindings repository, thus ensuring that all collaborators have direct access to the same exact headers I'm working on (i.e. right now v1.2.0), and allow repository transitions to newer Ultralight SDK versions independent of a custom script.

Also, the lack of a clear license in the header files introduces uncertainty regarding the license status of custom bindings. I'd like my bindings to be ultimately released under MIT License, which shouldn't be a problem since they shouldn't constitute a derivative work, strictly speaking; but the problem is that due to the intrinsic language differences I need to paste in my source comments the original C functions (and their comments), as references to the ported interfaces and their parameters' types — which ultimately means that a significant portion of the original headers' code will be included in the bindings' sources, which does bring into question license and copyright issues.

Unfortunately, PureBasic's native types don't always match C's native types, so some workarounds are required to ensure types consistency and prevent data corruption (especially with unsigned integers). Hence the need to always keep in the PureBasic bindings source comments the original C/C++ functions declarations, as a reminder of the types involved in each function or structure.

Another licenses related issue concerns the code samples found in the release packages of the Ultralight repository. As mentioned above, I've ported to PureBasic the Sample 6 (Intro to C API) that ships with the binary release, which in this case is definitely derivative work (I've pasted the whole C source into a PureBasic source file, commented it out, and then started adapting it line by line). Besides that, there are also the various assets (html files, images, etc.) which I've kept as they were in my example, to begin with.

The EULA.txt and LICENSE.txt that govern the Ultralight repository are too strict to allow reuse of the samples' code and assets in a third party binding, and might not be compatible with the license under which the bindings are released — which ultimately requires to create any examples from scratch, without reusing the original assets.

I suggest that you release the C/C++ headers under some common FOSS license that would allow easy inclusion of the original headers in any bindings project, also keeping into account that some languages provide headers converters from C/C++ to the target language (which would effectively make the thus generated headers a derivative work, legally speaking).

Also, if you could release all the samples' source code and their assets under a common FOSS license, it would make it easier to quickly provide the same samples in the ported language's repository (saving the time and effort to having to create custom assets).

Although the EULA.txt and LICENSE.txt files are clear and practical when it comes to creating and distributing a custom application which uses Ultralight, they don't seem to cover very well the needs of collaborative open source projects for bindings to other languages — honestly, you'd need to consult a lawyer before taking any steps with these two legal documents; they're surely unlike the typical FOSS license, or the 20-odd lines copyright notice by Apple Inc. found in the JavaScriptCore/ headers.