UE5 plugin and JSBSim license/legal clarity + Dynamic Library info

[gallonmate]

Edit2 June/19/2022: All licenses are good & compatible with current version of the UE plugin's usage of JSBSim. Be mindful of JSBSim's open source nature, it's license And the authors/licenses for each aircraft/engine used

Licenses:
JSBSim has a LGPL-2.1 license
Unreal Engine 5 has a EULA, which does not allow LGPL works in UE5 packaged products, except if the LGPL work is dynamically linked.

JSBSim in general can be used with UE5, if it is dynamically linked.
The issue is the UE5 plugin is also currently in the JSBSim repository and thus falls under the LGPL 2.1 license. Meaning the UE5 Plugin itself is now LGPL.

While this is not an issue for single users who wish to build UE5 based projects at home, business, or schools, etc. It is an issue if that user wants to share/distribute their packaged UE5 build containing the plugin.

In summary a UE5 packaged product could not be distributed with the current UE5 plugin.
If someone wanted to distribute a UE5 package/product then the UE5 plugin would need a license separately from JSBSim and it would need to be a license that fits the UE5 EULA, such as MIT, BSD, Apache, etc.

Edit: While the user themselves might not be in violation of the LGPL license if they provided source code of their UE5 project, they would still be in violation of the UE5 EULA which prevents LGPL licensed works in a distributed UE5 packaged.

[bcoconni]

I'm no lawyer but AFAICT the license that applies to a source file is enforced by the file content itself (i.e. the license is generally mentioned at the header of the file). This is the reason why the applicable license should be written in each single file. I'm pretty sure that the GitHub repository which hosts the source code does not enforce any license on the content of the repo, it is just an indication of the applicable license.

Regarding whether one could distribute the JSBSim UE5 plugin with an UE5 product, I'll let @AlbanBERGERET-Epic answer this question.

[gallonmate]

Correct, for the most part Alban would just need to add a license to his plugin that is compatible with Unreal Engine. I'd suggest Alban consider adding a MIT license in his Readme.
Snippet of the Unreal Engine license and relevant section:
https://www.unrealengine.com/en-US/eula/unreal

5. Other Restrictions on Your Use of the Licensed Technology
   a. Non-Compatible Licenses
   You may not, and may not permit others to, combine, Distribute, or otherwise use the Licensed Technology with any code or other content which is covered by a license that would directly or indirectly require that all or part of the Licensed Technology be governed under any terms other than those of this Agreement (those licenses, the “Non-Compatible Licenses”). This means, for example, that you may not combine the Licensed Technology with code or content that is licensed under any of the following licenses: GNU General Public License (GPL), Lesser GPL (LGPL) (unless you are merely dynamically linking a shared library), or Creative Commons Attribution-ShareAlike License.

But even adding a license to the plugin does not fully solve all potential license issues. The plugin (when distributed as software using JSBSim) will still need to meet the JSBSim LGPL license requirements.
Currently the plugin is statically linked and per the license it would need to meet the requirements:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work?

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

    (1) If you statically link against an LGPLed library, you must also provide your application in an 
    object (not necessarily source) format, so that a user has the opportunity to modify the library and 
    relink the application.

    (2) If you dynamically link against an LGPLed library already present on the user's computer, you 
    need not convey the library's source. On the other hand, if you yourself convey the executable
    LGPLed library along with your application, whether linked with statically or dynamically, you 
    must also convey the library's sources, in one of the ways for which the LGPL provides. 

The plugin in it's current static link format would require any Unreal Engine developer using the plugin to provide all of their project's source files upon request, because any changes to the library requires a re-compile of their Unreal Engine project. While for some devs this is not a problem but for other devs this is a problem, because for example if they are using non-open source 3d models, they cannot freely share those source files in most cases. This is the same reason the Alban cannot publicly share the entire "Antoinette Project", as it contains paid assets in the source files.

Changing the plugin to a dynamic link library would allow for greater general use of JSBSim with Unreal Engine. (This is something I would be willing to implement myself in the following months, using the plugin as a starting point but first Alban would need to provide a suitable license for his plugin, as first noted.)

[AlbanBERGERET-Epic]

Copy,
Let me check what I can do. I'll probably change to a DLL and add a copyright notice. I need to check internally first.
Thanks for pointing that out!

[AlbanBERGERET-Epic]

Hi @bcoconni and @gallonmate

I had a quick look at building JSBSim as a DLL, but the DLL file is generated without any import library (.lib).
There doesn't seem to be any dllexport or JSBSIM_API-like tags in the code.

Do you know if JSBSim has ever been compiled as a DLL?

That makes me think about something else, maybe silly. Is there a specific reason for using the LGPL License in JSBSim? It would be much easier if it was a truly open license...

[bcoconni]

That makes me think about something else, maybe silly. Is there a specific reason for using the LGPL License in JSBSim? It would be much easier if it was a truly open license...

We could argue on the meaning of a truly open license because I think that LGPL-like and GPL-like are the truly open licenses 😄

Changing the JSBSim license is not option because:

• As far as my contributions are concerned, I don't want to
• But even if I would, this would require asking all the contributors of JSBSim if they agree modifying the license of their contributions. I have already done that for the integration of the Simulink S-Function to JSBSim but given the amount of contributors to JSBSim (some of them never being heard of since they contributed) I don't want to go down that road again. Especially because this one is much steeper.

[bcoconni]

The only remaining option is therefore to compile JSBSim as a DLL as @gallonmate has explained in his #631 (comment) above.

[seanmcleod]

I agree with @bcoconni's comments.

[gallonmate]

Hopefully bcoconni or others can provide more direct help with JSBSim. In the mean time here are some references I found of JSB used as DLL
It's a little outdated as a repo and appears somewhat custom for their own application program: https://github.com/Outerra/jsbsim and forum link (appears general discussion,and not technical): https://forum.outerra.com/index.php?topic=1378.60)

And here's another very much outdated repo
https://github.com/ToninoTarsi/jsbsim-dll

[bcoconni]

Thanks for the references @gallonmate, this was very helpful in coding the PR #644.

[ghost]

Well. This is all unfortunate. I was planning on making my iteration/integration with a commercial project. Let me know if this license changes or anything.

[bcoconni]

Do you know if JSBSim has ever been compiled as a DLL?

FYI I have just created the PR #644 to allow JSBSim being compiled as a DLL. This is WIP at the moment but should be merged very soon.

[bcoconni]

The PR #644 has been merged. JSBSim can now be compiled as a DLL.

• The flag JSBSIM_EXPORT must be defined when compiling JSBSim as a DLL. It then must be undefined when linking an executable to the DLL of JSBSim.
• The flag JSBSIM_STATIC_LINK must be defined when compiling and linking with JSBSim as a static library.

CMake takes care of defining the correct flags depending on the CMake flag BUILD_SHARED_LIBS being set to ON or OFF. Default is BUILD_SHARED_LIBS=OFF i.e. CMake builds the static library by default.

The MSVC project files have not been updated yet (@seanmcleod ? Any chance ?)

Please note that I have tagged the classes exported to the DLL to the bare minimum for the GitHub Actions workflow to succeed. If you need access to other classes, please submit a PR or open an issue.

[seanmcleod]

The MSVC files have not been updated yet.

I'll take a look in the next day or so.

[bcoconni]

Thanks @seanmcleod ! 😊

[AlbanBERGERET-Epic]

Thanks @bcoconni
I'll also have a look in the next day or so about the UEReferenceApp using JSBSim as a DLL.

[bcoconni]

The PR #650 has just been merged. Thank you @AlbanBERGERET-Epic 👍

[bcoconni]

To everyone: the JSBSim plugin for UE can now be used safely for proprietary and open source applications since JSBSim can now be compiled as a DLL and @AlbanBERGERET-Epic updated the plugin to use the DLL.

Quoting @AlbanBERGERET-Epic's from PR #650:

• It's totally fine to use JSBSim in any commercial application as long as we link dynamically, so we use the DLL build.
• We don't need our contributions to be subject to the LGPL license.
• We provide the UE Reference App and the JSBSimFlightDynamic plugin as different packages, each of them as MIT license, so free to use and modify in any context. I created two separate license files for that very purpose.

I hope this will address all the concerns that were raised in this discussion 😄

Enjoy !

[gallonmate]

Thanks @AlbanBERGERET-Epic for the amazing plugin, thanks @bcoconni for the help/work in solving the DLL & all contributors to JSB. (And sorry about the concerns in the first place!)

[jamesford42]

To everyone: the JSBSim plugin for UE can now be used safely for proprietary and open source applications since JSBSim can now be compiled as a DLL and @AlbanBERGERET-Epic updated the plugin to use the DLL.

Quoting @AlbanBERGERET-Epic's from PR #650:

• It's totally fine to use JSBSim in any commercial application as long as we link dynamically, so we use the DLL build.
• We don't need our contributions to be subject to the LGPL license.
• We provide the UE Reference App and the JSBSimFlightDynamic plugin as different packages, each of them as MIT license, so free to use and modify in any context. I created two separate license files for that very purpose.

I hope this will address all the concerns that were raised in this discussion 😄

Enjoy !

Sooo just to clarify.. would an application/package containing jsbsim dlls actually be allowed on the unreal marketplace, though? Also, if the answer is different here depending on whether we're discussing the Plugin/Engine Marketplace and the Game Marketplace, that would be relevant to know.

[gallonmate]

@jamesford42 The jsbsim dll should be safe for the engine marketplace. Whether they approve the plugin or not is another story. The only thing I know that is prohibited by definition would be the standard jsbsim aircraft and engine files. Those xml files are GPL which would be considered a prohibited license for the marketplace. Although they might make an exception for them since those files are generally kept separate and not compiled into code or asset paks. But since it's possible a marketplace user could take those GPL xml files and do anything with them, the marketplace might deny those files on principal to avoid such issues in the first place. As for selling the game on the Epic Game Store, I looked over the guidelines and don't see any restrictions with licenses for a commercial game. The GPL restrictions are with the engine marketplace and the engine itself. The way the plugin currently is setup is safe for usage since it doesn't compile or combine jsbsim into the engine product. Although I'm not a lawyer nor a Epic Games employee.

[gallonmate]

Sorry to bring up the topic once again. After double checking the files, I realized many pieces of code are licensed as GPL, which is technically incompatible with JSBSim's license of LGPL. While LGPL can be used in GPL projects, GPL cannot be used in LGPL. The list of incompatible licensed files/code can be found with a search of the repo using the following search: license -lesser
But I am uncertain as to which code are actually used in a packaged JSBSim executable. A quick list which the following folders have GPL licenses in some of their files (not all folders listed)

• Tests (Are tests files used in the executable?)
• Aircraft (Some of the aircraft with incompatible license could be removed and then manually loaded at a later time by the users)
• Engine
• scr/simgear
• python

[bcoconni]

The list of incompatible licensed files/code can be found with a search of the repo using the following search: license -lesser

Your criterion is ill-designed: the LGPL used to be named the Library GNU Public License until LGPLv2.0 and it is named the Lesser GNU Public License since LGPLv2.1 has been issued (see the GNU licenses website).

As far as I could check all the files under src/simgear are LGPLv2.0 i.e. Library GNU Public License that's why your search criterion filters them out unduly.

[seanmcleod]

The UE plugin builds the JSBSim C++ source code into a dynamic library (DLL on Windows).

The Tests aren't built into the DLL, they're stand-alone tests that are run to test for regressions etc.

In terms of the Aircraft and Engine files none of them are explicitly required, the developer building a UE based application will decide which aircraft and engine models to include, so it's up to the developer to confirm that they only include/bundle aircraft and engine models that have a compatible license. Having said that given they're data files which aren't compiled into a binary I'm not sure if including data files which have a GPL license would even be an issue. The developer would be bundling them with or without modifications and the end user would have a copy of them to modify themselves, see what changes if any the developer made to them etc.

The python directory contains code to generate a separate python binding DLL (shared library) to expose a python interface to JSBSim, but this isn't required for the UE plug-in.

So the only potential issue I see is some of the source code in src/simgear. I haven't taken a look yet to see which and how many specific files in that directory have a GPL license.

[bcoconni]

In terms of the python bindings, it looks like there aren't that many people who have made changes, so it may be feasible to ask all of them if we could switch from GPLv3 to LGPL to be consistent with the C++ code?

Yes, correct. As far as I am concerned, I'm fine to switch to LGPL.
How about you @aarondewindt and @jgoppert ?

[jgoppert]

I'm fine with it as well.

[aarondewindt]

Fine by me.

[bcoconni]

Thanks guys !

Personnaly I could have lived with the Python module being GPL but if moving it to LGPL make some users be more comfortable then so be it !

The license of python/jsbsim.pxd and python/jsbsim.pyx.in have been updated to LGPL by the commit 711366b.

[agodemar]

Fine by me

[bcoconni]

By the way @gallonmate, I have reworded your "Edit 2" in the top comment of this discussion because it was untruthful:

• There are no "conflicts of license just for JSBSim" until proven otherwise. And you so far, you haven't proven anything but made false claims.
• JSBSim is not "supposedly" LGPL. The terms you are using are vague as JSBSim is made of a C++ library, a Python module, a MATLAB interface and now an UE plugin, all with a different licence. So there is no JSBSim being "supposedly" LGPL.

Please check your facts before writing false claims.
Thanks.

[gallonmate]

@bcoconni I apologize. This was was not my intention to sound that way. Thank you for the edit. In the future I will try to use better words for my discussion comments and I will research better.

Thank you @seanmcleod & @bcoconni for clarification on the different file usages.

After re-reading every license in the entire repo. I have no further question, except for one: Are the following files in Systems folder compiled with JSBSim?
systems/airship_added_mass
systems/visual-reference-point-extensions.xml
systems/airship-mooring.xml
systems/sperry-a2-autopilot.xml
systems/hydrodynamics.xml

[bcoconni]

After re-reading every license in the entire repo. I have no further question, except for one: Are the following files in Systems folder compiled with JSBSim? systems/airship_added_mass systems/visual-reference-point-extensions.xml systems/airship-mooring.xml systems/sperry-a2-autopilot.xml systems/hydrodynamics.xml

No, XML files are input files. They are not compiled in the library.

The rule of thumb is that the library is compiled from the source files under the src folder. The exact list of sources are detailed in the CMakeLists.txt files : they specify to CMake which files should be compiled to build the target libJSBSim.

[andgi]

These files are XML files so they are not included in the JSBSim binary.

However, if you construct a new aircraft for JSBSim and use one or more of these files as part of your aircraft the GPL v2+ license in them might require that your other aircraft XML files are also compatible with GPL v2+.