Relicense under another license #466
Comments
|
Thanks for sharing this. The very basic idea behind using GPL in the tooling is actually to keep tooling free/libre, i.e. available for everyone to use and contribute to. It's not LGPL exactly because the original intent was to keep tooling (which might make use of inner APIs of the compiler, i.e. IDEs, visualizers, build system plugins, etc), free, while keeping results of compilation under a license that would allow usage in closed-source products as well. I agree that your use case is kind of borderline use here. I wonder what exactly do you use using JPype that you can't do using normal CLI API? If something's missing, may be we could export that using CLI API and/or compilation results? Alternatively, if you can/want, you can relicense kaitaiStructCompile.py under GPL, either whole thing, or a separate subproject that uses JPype only... |
Don't permissive licenses do it? The idea of GPL is not about freedom, it is about total war with everyone not using GPL or other licenses blessed in it.
In fact for now I don't do or plan to do anything which cannot be done using CLI API, either immediately, or with some modifications to KSC (which may be covered by FSF vision of GPL violation).
1 fileless workflow. Now when using the cli the compiler dumps compiled files. Since the tool postprocesses them it is more preferable not to dump them on disk but to keep in memory. Unfortunately, all of these satisfies
Do you mean ? That was what I was trying to do (I have described this in head message) first, but I'm afraid this won't do the trick and just distributing the second variant is illegal according to FSF vision (I guess There are GPL exceptions, but they must be approved by FSF, otherwise they prohibit to call the license GPL (the license text except the preambule is permitted to be used in other licenses). |
That's a deeply philosophical question, and I feel that we don't agree on this one with you. I'm not a huge fan of GPL myself, but in this particular case, it protects us from proprietary code forks which might easily get more popular due to large amount of resources a commercial company might put into marketing. Currently, whole reverse engineering / low-level tooling world (with smaller companies like Hex-Rays, Vector 35, Sweetscape, and bigger fish like Intel, IBM, etc) is heavily dominated with proprietary software. I totally don't want to see any of them getting "Kaitai Struct" and all the work that went into it, integrating it into their closed-source software and start marketing this functionality as part of their own, especially if they will do some non-compatible modifications. GPL would allow them to integrate using ksc CLI calls, but they would be either forced to open source their fork (=> allows people to learn what was the original and come to us), or to not fork anything and stick to original (=> even better, people could just learn and come to us) => i.e. it's a win-win situation.
Actually, ksc for JS already does that. I can introduce the same using an option akin to
Um, what do you mean and what do you want to do with exceptions?
Right. We can try passing RuntimeConfig using JSON input file or something — i.e.
If you mean "compilation progress", then it's actually relatively hard to implement and I don't see much point, as compiler is relatively fast: compiling our whole test suite (148 files) takes ~4.5s. Compilers like javac or gcc work at similar pace and don't give much progress report beyond file being compiled (and even that is not always visible).
The very straightforward way is to just have 2 different projects: one is Unlicensed using CLI, and another is GPLed using JPype. A somewhat less straightforward way would be to have 3 projects: two with inits (Unlicense+GPL), and third one with common code (Unlicensed, as you prefer it). Both GPLed and Unlicense can use your shared unlicensed code, if you want to avoid code duplication. |
|
Just realized that I have typed the answer but have forgotten to post it.
I guess it's better to output a zero compression zip archive into stdout. Serializing into json is damn inefficient because of escaping. BSON/msgpack kay be a good choice, but zip archives are already supported by far more software.
We may serialize them into json.
Using stdin for that is better.
Depends on hardware. For PIII it took about 2 seconds to compile 2 files (one of them is mifare_classic.ksy). I wonder how much of that is taken by JRE initialization and how much by actual compilation.
Not quite, the main concern here is the mentioned FSF interpretation of GPL. It fires even if we use CLI. |
|
@GreyCat, are you going to solve it somehow? I have almost finished the JVM backend (GraalVM support is added, though it won't work now: GraalPython is too unfinished now), but I still don't want to make people license their |
|
@KOLANICH https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) You CAN call GPL licensed software in non-free software so long as you haven't modified it. The FSF specifically mention compilers and other tools in the FAQ as acceptable usage that doesn't violate the license. |
|
This is just an example:
And that case is inapplicable in my case. In my case they are effectively a single program: I use KSC as a lib and this works much better than interacting KSC via a CLI. Unfortunately the license of KSC prevents me from sharing the stuff (sharing the stuff under GPL is not an option because it would mean a requirement to license any programs using the tool and being distrihuted under GPL, which is inacceptable). |
|
@GreyCat, are you going to do anything about this? If not, please close this issue and put a BTW, interacting directly with KS using JNI is still the preferred way. It may require some changes in the license. The optians are:
May be accompanied with technical measures to separate the core from interface. But it has to be done by the holders or from their explicit public approval. The second preferred way is a server communicating to external tools using a message queue in a shared memory mapping. This way is not very good, it has some overhead. But the overhead should be smaller than communicating via stdout. |
|
Am I right, that relicense of compiler is not needed for.
Why JNI is prefered over the methods above? |
|
As All the solutions with a local service have an additional drawback - one has to deal with service starting, restarting and dying. All the solutions using network has an additional issue - one has to deal with network issues. 2 sockets and pipes and everything kernel-mediated stream-based is inefficient. A better approach is a pair of shared memory pages + a message queue using them. |
|
I see the obsession about performance in every argument. Which is strange in the case of Kaitai compiler looks like premature optimization anti-pattern to me. It only affects compilation. It is only run when .ksy files are changed. People don't need to run in in production. Only for development. What is your expected speed up for this change? Shared memory + message queue is intra-process, unless your provide a service, which us again HTTP / TCP / UDP etc.to pass the credentials needed to access that. |
It is not obession, it is necessity.
JVM backend gives a few seconds noticeable benefit, when used for bulk processing of ksys.
Which makes the issue especially important because when we design a spec, we have to compile it a lot of times. Few seconds * 1000 ≈ few hours.
A memory page (and its corresponding page frame) can be shared by multiple processes. |
|
I see not real numbers here. Can you address non-answered question - What is your expected speed up for this change? And more specifically these questions.
|
You didn't answer how you pass the handle to this memory to another process. This will be the performance bottleneck. |
I have not measured. Just experience.
Loading everything needed into memory. Have not measured the time, know only that the difference is noticeable and in batch processing takes seconds.
a. initialization is probably unavoidable. a solution may be to compile KSC into native code ahead of time. As fast as possible. Should work fast even on Pentium 3 machines.
The handle can initially be passed using stdin. |
The argument of a programmer, but not of a software engineer. |
Running Kaitai as an HTTP server that accepts .ksy files will be more beneficial and even faster for much more developers than |
Measuring it is an additional effort. Should be done definitely. For my purposes it is enough that I perceive them as faster.
Are you personally gonna to implement it and merge into the upstream? If yes, I'm happy to add a backend to kaitaiStructCompile supporting this mechanism. But please note - if you personally implemented it, it'd be a GPL violation (in FSF and Mercurial understanding of the matter). You likely need every contributor blessing to make it not a violation.
ZeroMQ yas something similar, but for intra-process communication between threads. I wonder if it works for different processes too. Have not tested though, have no time for that currently. |
|
Non-GPL client sending API request to HTTP server is not a GPL violation. |
What "understanding" are you referring to here exactly? Mercurial actually has a "command server" mode that provides an API over a socket/pipe, and one of the main reasons why it was added is that it doesn't count as "combining" in the context of the GPL, so that other programs can use Mercurial through the command server without any GPL problems. The suggested solution is to add an HTTP server mode to ksc, which (presumably) would take high-level requests of the form "compile the following spec file(s)" and return the compiled output. This is relatively similar to Mercurial's command server mode, and almost certainly doesn't count as "intimate" communication as the FSF calls it, so it won't count as "combining" under the GPL. |
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
https://www.mercurial-scm.org/wiki/CommandServer#Licensing
|
|
My not-a-lawer interpretation:
FSF and Mercurial devs (read https://www.mercurial-scm.org/pipermail/mercurial/2011-March/037593.html mentioned in Mercurial license FAQ, it makes the main dev position very clear) clearly belong to the kind of copyright trolls. So do (under |
None of this applies to the hypothetical ksc HTTP interface, as I already said above.
I assume that the ksc HTTP interface won't allow callers to "export new functionality" (i. e. to load extra code into ksc or to implement complex callbacks), so this is also irrelevant here. |
How would it take multi-file (importing not modules in the stdlib) requests and return structured info about exceptions without what can be considered by copyright trolls as
If I understand right, the quote means not plugins, but forking Mercurial, implementing some API in the server subsystem in order to expose some functionality via the API, and then using this API in own code. So I understand that the quote as equivalent of the statement "only some blessed authors of Mercurial decide if they consider that some API exposed via the server is viral or not, and by default they consider (and authorize orgs like SFLC and SFC to consider) all the API exposed that way as viral, but for all the API present in the upstream they have already considered tat that API are not". |
|
My general feeling (I am not a lawyer) is that the GPL is intended to prevent tight integration allowing someone to provide an interface that presents a GPL code as proprietary. What is the difference between compiling against a static library, a dynamic library, or creating a IPC service that allow you to preform all the same functionality of making use of a GPL product? If they all provide the same functionality (with the only difference being technology under the hood), then they would all be equally violating of the GPL license. Some would argue that the IPC gets around it because the IPC code that is exporting the GPL product is GPL and thus the derived work is not the full code that uses the IPC, but that really is a dodge of the intent of GPL. Consider from https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
This means that regardless of whether you do direct linking, use pipes or sockets, or even skip the direct communication and use JSON communication with serialized objects passed through a CLI (exchanging complex internal data structures via files), if the communication makes the two products an integral piece of the same code then it is considered "linking" which is prohibited. They list anything that ends up in the same memory address as definitely linking, but that was not meant to limit the larger extent. Thus JNI is vs HTTP is really immaterial as they are just different communication protocols (though as JNI is usually in the same memory space so it hits the linked clause more clearly). I can in principle make JNI communicate through ZeroMQ and google protocol buffers, and the user of the library can't tell the difference would that some how make it okay which still using JNI? If @KOLANICH chose Py4J which uses socket IPC rather than JPype which uses direct JNI but both allow the exact some level of class, field, and method communication to a Java library would that some how not violate the spirit of the GPL? If it is distinction without a difference (both provide full access to Python), then I would say they both violate. If you wish to allow anything above the system exception then do so explicitly as per the instructions. https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs Simply add an exception to your version stating explicitly what you want it to be able to do. If you don't mind communicating with other open source codes (even with incompatible licenses) so long as code is not being distributed as part of proprietary license, you can add that exception if you are the author. If you just want to propagate the GPL viral license that is also your choice as an author. Again my unsolicited opinion, just making it difficult to use your software forcing pipes or sockets or other technological implementation (CLI/serialized objects) just raises the burden of using the library and ultimately invites some other group to replicate your work to avoid the restriction which fragments the community and reduces the value of your software to the world. I recently replicated the work of some other library simply because the authors maintenance cycle was interfering with my own project and his license choice precluded inclusion in an Apache project. Ultimately I am not sure if that helps or hurts the community but is was the only thing I could do to stop people from being directed to install an old buggy version which was clearly a negative. If this library is designed to allow intimate communications via serialized objects then it should just add an exception that allows the same level of communications directly with the restrictions that you wish to impose. That would make your intent clear rather than depending on the vagueness of the generic GPL license. That said relicensing is a bit extreme as adding a simple exception clause would do. |
I have nearly finished the part of kaitaiStructCompile.py using JPype, but found there are licensing issues.
The problem is that the relevant part of the lib taps into ksc. I have thought about some ways to avoid this like moving the module linking the lib into a separate-installable plugin discovered via setuptools entry_points and choosen in runtime, while the alternative plugin has Unlicense license, but according to FSF faq (though it may have a biased view, but I'm not a lawer and obviously don't want to hire a one) this means that kaitaiStructCompile. is also required to be licensed under GPL.
Lurking for some clarification, found a stack(overflow|exchange) post (unfortunately I have closed it and couldn't refind) having a checklist and describing that from legal PoV (even though the post was "not a legal advise") it doesn't matter at all if one's program links against the GPLed lib, or includes it, if the program is nonfunctional without that lib it is a derivative work, and surely this applies to kaitaiStructCompile.py since there is no another Kaitai Struct. One may argue that this is nonsense since an iOS app is non-functional without apple proprietary products too, but I'm not a lawer.
So it seems there is no legal way to circumvent GPL here other than recreate KSC from scratch, and I guess that creating a dummy implementation having the same interface and doing nothing is not the solution since (again I'm not a lawer) from the court point of view it may look like the whole point of doing this is copyright violation.
Since this kaitaiStructCompile.py is itself a plugin to setuptools, which is meant to be explicitly enabled by its users, this means that their setup.py is also have to be GPLed, which is obviously unsuitable.
So, I guess we need to change the license of the compiler, and lgpl is not an option because despite linking the tool is still non-functional without ksc, so the same arguments hit as in gpl.
The text was updated successfully, but these errors were encountered: