Any plans for an MIT license?

[nomnomab]

Hey there! 👋

I have been tinkering with this library for a bit and it's really enjoyable! I just have some concerns with actually using it in work/personal projects due to the LGPL 3.0 license in a Unity project.

With Unity the library is installed either from NuGetForUnity (which we do not use), or manually dragging in the library dll + dependency dlls. This works fine for PC. However, from what I have been reading in various places, such as this, it seems that LGPL 3.0 cannot be built for non-PC platforms due to them embedding the library directly into the executable. Please correct me if I am wrong though!

Alongside this if the project is using IL2CPP, instead of Mono, it essentially takes all the managed DLLs, puts them into a single C++ project, and compiles them all together. Which makes replacing this lib impossible in the final build.

Are there any plans to swap to MIT in the future, or any major reason it is LGPL 3.0 currently?

It is also still a bit hazy on what would have to be included in the built game if we had to fork the codebase to change something, or really just including it in general depending on the installation method. Although, in either case this wouldn't matter for non-PC platforms (as far as I have read at least).

I look forward to your thoughts!

[PeturDarri]

+1

It looks like the Mozilla Public License 2.0 is perfect for this. It has the same requirement of distributing modifications under the same license, but without the re-linking requirement of LGPL 3.0, which as mentioned, is difficult to uphold in Unity IL2CPP and arguably of little value for the average gamer.

[friflo]

In general I want to avoid changing the license too often. Changed it from AGPL to LGPL some months ago.

I will consider changing to MPL 2.0. The reason is to avoid the obstacles in a project that statically links the library as describes by @nomnomab.
Maybe there are more comments on this topic. So changing the license will consider additional comments.

[Danon5]

I agree that the current license is a fairly large roadblock for console development within Unity. MPL 2.0 seems like a good alternative to keep improvements or modifications to the library publicly available, while still allowing projects to ship to more restrictive platforms where users might be unable to access / replace the original DLL.

[DruidOwl]

Hello there too!

I vote for MPL-2.0.
It's definitely better than LGPL both for this project and for its users as it won't hinder the wider adoption of the engine.

I'm currently at the early stage of developing an indie game and in the past few days I've actually tested 11 open source .NET ECS frameworks. I've come to the conclusion that this one is the most convenient, has simple and clear but powerful API, excellent speed, fitting my needs etc. Everything is good but there is one thing...
The license.
Among the frameworks I've tested so far there are only MIT licenses, one Apache 2.0 and this one LGPL 3.0. While I'm willing to start building the game upon Friflo.Engine.ECS, I'm also afraid and concerned of being forced to switch to something else when the time comes to release. The earlier the better.

IMHO: It's hard to impossible to strictly comply with LGPL (especially v3.0) nowadays. Embedding, packing, recompiling and code signing is everywhere. It's unlikely that an end user will proceed with and could benefit from relinking specific game tooling modules, probably breaking the integration between the game and the modules rendering the game not-working. But LGPL 3.0 requires the relinked result to still be working. So while LGPL allows producing even commercial combined work, it's difficult to even open source authors not to violate the license terms on some platforms as mentioned by others. That's the reason for all the concerns around LGPL-ed libraries.

I've even signed up to GitHub to express my opinion on this matter )

UPD: I see it's more complicated, since Friflo.Engine.ECS has these dependencies, all being LGPL 3.0:

Friflo.Json.Fliox
  Friflo.Json.Burst
  Friflo.Json.Fliox.Annotation

Though I don't know what the author's plans are for them.

[friflo]

I checked the MPL 2.0.
Its "file-level" copyleft is not very useful.
New files added to a modified library are not covered by the MPL license.
As a result these new files may not be added to a published modified project.
The resulting project will simply not compile.

I check alternatives ...

Friflo.Json.Burst & Friflo.Json.Fliox.Annotation are only used for JSON serialization.
If static linking is required those dependencies could be be removed in a fork if JSON serialization is not required.

[friflo]

As in the last steps to publish an official 3.0.0 release the license is changed to MIT.
Commit Changed license to MIT

[DruidOwl]

This is great news! Thank you!