Licensing and use in closed source projects.

[Isolyth]

Hi! I'm a hobbyist developer looking to use the ECS in my game, however, the AGPL license used for the software is not compatible with the game being closed source, and would require the game to be open source, which is sadly nonviable for a commercial project. Are there any plans to change the license of the ECS (and, since the ECS requires it) Fliox itself to allow for its use in closed source projects?

[friflo]

It seems I did understand AGPL wrong.

What I now read on several places is:
If you link "derived work" (a game) to an AGPL library the derived work must be AGPL also.
This is not what I want.

What I want is:

• Allow use in closed source / commercial software. Especially when using the library as binary - *.dll
• In case of distributing the library with modified sources these changes shall be made available.
  E.g as a fork on GitHub.

Is guess LGPL is what I want. Do you agree?

[Isolyth]

I'm pretty sure LGPL would work, as it allows for closed source programs (such as a hypothetical game) to link the library and use it without needing the game itself to be open source. I asked Claude (AI chatbot similar to ChatGPT) about it and it said that the LGPL would permit this.

[friflo]

Changed the project license to LGPL v3.0 - before AGPL v3.0.

Published all nuget packages using the new license.

I also looked at other licenses which are more permissive than LGPL.
Maybe I switch to one of them in future.

For future changes I want to avoid changing from a permissive to a more restrictive one.
So I choosed LGPL for now.

See: https://en.m.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses

[pkra8]

@friflo
Just so you know, LGPL is still problematic.

For ex. as mentioned here, no one that works for larger companies will touch code with this license:
https://www.quora.com/Can-I-use-LGPL-in-commercial-software

Here is example how to properly load and use library as dynamically linked :
https://stackoverflow.com/questions/72700743/c-sharp-load-dll-at-runtime
Using your library requires user to go hoops such as this:

using System.Reflection;
class Program
{
    static void Main (string[] args)
    {
        Assembly assembly = Assembly.LoadFrom("/path/to/lib.dll");
        Type MyClass = example.GetType("lib.MyClass");

        MyClass.GetMethods[0].Invoke();
        Console.ReadLine();
    }
}

Further explanations on how (in terms of complying with license) LGPL libraries can be used is here:
https://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking

Can you please reconsider reposting as MIT? I understand that you don't want your hard work to get used by someone that will do small modifications and resell it, but quite honestly lgpl is major turn off for adoption. Keep in mind that reflection has a runtime performance cost.

[friflo]

@pkra8

I agree with your conclusions partly.

"For ex. as mentioned here, no one that works for larger companies will touch code with this license"

I guess this is often the case in larger companies.
But its mainly the result of excessive caution and the fear of dealing with licenses other than MIT.
So this ECS project does not address larger companies. They don't contribute in any way. E.g. feedback or a simple star.
This project addresses passionated C# developers. It's also the reason that projects like this exist.

"Here is example how to properly load and use library as dynamically linked"

There are mainly two types of dynamic linking in C# .NET.

1. Load-time dynamic linking - Is used whenever you include a nuget package in your project. E.g. the nuget package of this library.
2. Run-time dynamic linking - Is rarely used and is the topic of your stack overflow link.

"Using your library requires user to go hoops such as this: ..."

This conclusion is simply wrong.
This library is published as nuget package. Applications are using it as <PackageReference> in their projects.
This type of integration is "Load-time dynamic linking"

"Keep in mind that reflection has a runtime performance cost."

That is correct in itself.
But it is not applicable in the context you are framing it.

Your statements did not convince my to change to MIT license.
At least not now.

[pkra8]

Ah thanks for having better insight and explaining what I didn't know. After testing it does confirm what you are saying - project using nuget packages outputs a lot of .dll files which means I can safely swap to your library from another i've used with no licensing issue.
Always good to learn something new, and hopefully this exchange will prove useful to someone else being unnecessarily scared of LGPL.

[friflo]

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