Maybe LGPL is bad for Android Libraries.
Hello Rosemoe and contributors,
First, thank you for all your hard work on Sora Editor it’s truly appreciated!
I wanted to share some thoughts on why I feel the LGPL may not be the best fit for an Android Java library. The license requires either dynamic linking or providing users with a way to replace the library in the combined work, and this can be particularly challenging on Android for the following reasons:
-
Android apps bundle all their libraries into a single file, often inside
classes.dex. Once everything is packaged into an APK, it’s not straightforward for users to extract and swap out individual libraries. -
Most Android apps use tools like R8 to obfuscate and optimize the code. While this improves performance and reduces APK size, it changes method names and class structures, making it nearly impossible to replace a specific library without access to the original source and build process.
-
While Android does support dynamic linking with native
.sofiles, that’s not how Java or Kotlin libraries are typically used. For most Android apps, dynamic linking is simply impractical.
Additionally, most Android users lack the technical expertise to replace a library within an APK. The LGPL assumes a level of technical ability that isn’t common among users, which can create unnecessary hurdles.
Considering these challenges, licenses like MIT or Apache 2.0 might be more suitable for Android development. These licenses don’t impose strict requirements like dynamic linking or library replaceability, making them a better fit for the way Android apps are built and distributed.
Of course, I completely understand that this decision is ultimately up to you and the contributors. Changing a project’s license is a significant step and requires agreement from everyone who has contributed to the codebase.
Thank you for your time, and I’m looking forward to seeing the project continue to grow and thrive!
For reference, here’s a similar issue, And this stackoverflow question.
Best regards,
MohammedKHC
Looks like an AI generated content to me. Because it confused between LGPL 2.1 and 3.0. LGPL-2.1 has the following terms for combining an LGPL-2.1 licensed library with an work:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) ...
This effectively allows any Android app to pack this library as DEX by simply including the license file in the APK (with explicit notice if required by the library) without any R8 optimization (which you can do by editing the proguard file). It is NOT necessary for a developer to ensure that the distributed APK will work with a modified library or not. However, if the app has specific terms and condition, it cannot contain any terms that prevents reverse engineering of the app.
@MuntashirAkon
You spotted me :), some of it was Ai generated. I actually edited it and summarized it.
Although I still believe that it would be nice if the license is changed. Also I saw from git history that the license was Apache 2.0 on version 0.5.0, so I think it will be great if it went back to it. Also after changing the license from Apache 2.0, I don't know if Rosemoe discussed the license change with the contributions, If he didn't then maybe this is a bad thing because according to my information you can't change the license of the project without getting agreement from all of the contributions. See the license file change on this commit
Also, I fully understand that I cannot force my opinion on Rosemoe and the contributions.
Have a nice day!
Also after changing the license from Apache 2.0, I don't know if Rosemoe discussed the license change with the contributions, If he didn't then maybe this is a bad thing because according to my information you can't change the license of the project without getting agreement from all of the contributions.
Changing license from permissive to copyleft usually does not require an explicit consent from the contributors. Changing copyleft to permissive, however, does require explicit consent. So, it may no longer be possible to actually revert the license now.
@Rosemoe Can you please think about this again?
Unfortunately complying with lgpl is very hard for my application, it uses removable dynamic feature modules so I can't just tell the user to reverse enginer the app as the needed modules at install time will be removed. (My app stores needed executables inside a dynamic feature modules and then extracts it and after that delete the feature module)
and it's supposed to be paid, So if I give everyone the entire code he will be able to just copy the app and distribute it to everyone.
If you don't want to change the license can i at least buy a proprietary license for your code. And of course ask every contributor if he is fine with it.
Best regards.
Unfortunately complying with lgpl is very hard for my application, it uses removable dynamic feature modules so I can't just tell the user to reverse enginer the app as the needed modules at install time will be removed. (My app stores needed executables inside a dynamic feature modules and then extracts it and after that delete the feature module)
If you're providing Sora Editor as a dynamic feature, it still complies with LGPL-2.1 license.
I think that actually it doesn't, As the user can't replace it. Because dynamic feature modules are installed at /data/app.
On Tue, Feb 18, 2025, 5:12 PM Muntashir Al-Islam @.***> wrote:
Unfortunately complying with lgpl is very hard for my application, it uses removable dynamic feature modules so I can't just tell the user to reverse enginer the app as the needed modules at install time will be removed. (My app stores needed executables inside a dynamic feature modules and then extracts it and after that delete the feature module)
If you're providing Sora Editor as a dynamic feature, it still complies with LGPL-2.1 license.
— Reply to this email directly, view it on GitHub https://github.com/Rosemoe/sora-editor/issues/630#issuecomment-2666002808, or unsubscribe https://github.com/notifications/unsubscribe-auth/BKJ46C573KJFUMAUZBS6PZT2QNEVDAVCNFSM6AAAAABSJLFHNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRWGAYDEOBQHA . You are receiving this because you authored the thread.Message ID: @.***> [image: MuntashirAkon]MuntashirAkon left a comment (Rosemoe/sora-editor#630) https://github.com/Rosemoe/sora-editor/issues/630#issuecomment-2666002808
Unfortunately complying with lgpl is very hard for my application, it uses removable dynamic feature modules so I can't just tell the user to reverse enginer the app as the needed modules at install time will be removed. (My app stores needed executables inside a dynamic feature modules and then extracts it and after that delete the feature module)
If you're providing Sora Editor as a dynamic feature, it still complies with LGPL-2.1 license.
— Reply to this email directly, view it on GitHub https://github.com/Rosemoe/sora-editor/issues/630#issuecomment-2666002808, or unsubscribe https://github.com/notifications/unsubscribe-auth/BKJ46C573KJFUMAUZBS6PZT2QNEVDAVCNFSM6AAAAABSJLFHNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRWGAYDEOBQHA . You are receiving this because you authored the thread.Message ID: @.***>
I think that actually it doesn't, As the user can't replace it. Because dynamic feature modules are installed at /data/app.
Dynamic features are separate APK files and falls under clause 5. They don't create a combined executable but the DEX file (if present) is loaded dynamically using the DEX classloader, a Java-style classloader that can handle DEX. It complies with the terms.
This doesn't seem right. Android's situation differs greatly from the LGPL's intended use. On a typical desktop OS, libraries can be separate JAR files within a ZIP. The user could extract this ZIP and run the application. If they wanted to, they could then replace a library JAR. This isn't possible on Android. Even with dynamic feature modules, apps can't modify themselves, nor can users easily replace libraries.
@Rosemoe, please consider changing the license. This project has huge potential, especially for those without PCs. I need to be certain I'm compliant.
BTW @MuntashirAkon thanks very much for your time. But i believe feature modules aren't compatible with LGPL, as they don't allow users to modify the library. Thus taking the freedom from the user And I believe Gnu's GPL and LGPL are all about freedom.
i believe feature modules aren't compatible with LGPL, as they don't allow users to modify the library. Thus taking the freedom from the user
Who says they do not allow modifications? You can make them static feature by modifying the manifest of the split, then modify the contents of the split, self-sign all the splits along with base APK and install all of them using a split APK installer. They are compatible with LGPL-2.1 license. You only have to include the license with your feature and cannot perform any R8 optimizations on the library. You only need to provide source code for the sora editor if you intend to modify it.