Would you consider LGPL / MPL-2.0 / MIT / dual licensing for broader app adoption?

[otherguy]

Hi,

First of all, thank you for publishing this package — it looks like a very useful and lightweight approach.

I’d be interested in using CustomKeyboardKit, but I noticed that the current GPL-3.0 license makes it difficult to integrate into a typical iOS app distribution model.

Since this project is published as a reusable Swift package library rather than a standalone application, would you be open to considering a different license model, for example:

• LGPL-3.0
• MPL-2.0
• Apache-2.0 / MIT

or dual licensing (for example GPL-3.0 + commercial license, or GPL-3.0 + LGPL-3.0)

My concern is not commercial use in itself, but downstream compatibility. As I understand it, GPL-3.0 for a library generally requires applications that use it to be GPL-compatible as well, which can make adoption in many normal iOS/App Store scenarios difficult.

A weaker copyleft license such as LGPL or MPL-2.0 could still provide protection for the library itself while making it easier for more apps to adopt it.

I completely understand if GPL-3.0 was a deliberate choice — I just wanted to ask whether you might consider an alternative or additional license for library consumers.

Thanks again for sharing the project.

[paescebu]

@otherguy Done! :) 2.0.1 and onwards have the MIT license type.
Thanks for bringing this detail to my attention. There was no intention of blocking it's use like this.
MIT seems to be the right choice.

Thanks and have a nice day!

[otherguy]

@paescebu thank you for considering my request and the incredibly fast response! Really appreciate you being open to the change! Just upgraded to 2.0.1.

One thing worth mentioning: LGPL still has some friction for iOS apps distributed through the App Store, since SPM statically links and Apple's code signing prevents users from relinking against a modified library (which LGPL technically requires). Most iOS developers treat LGPL as a gray area for this reason.

If you're ever open to going fully permissive (MIT or Apache-2.0), it would remove the last barrier for adoption in closed-source iOS apps. Either way, LGPL is a big step in the right direction — thank you again for that!

[paescebu]

@paescebu thank you for considering my request and the incredibly fast response! Really appreciate you being open to the change! Just upgraded to 2.0.1.

One thing worth mentioning: LGPL still has some friction for iOS apps distributed through the App Store, since SPM statically links and Apple's code signing prevents users from relinking against a modified library (which LGPL technically requires). Most iOS developers treat LGPL as a gray area for this reason.

If you're ever open to going fully permissive (MIT or Apache-2.0), it would remove the last barrier for adoption in closed-source iOS apps. Either way, LGPL is a big step in the right direction — thank you again for that!

In fact, i realized myself in the same minute after i posted my reply. An thought Im quick enough with editing my previous reply 🤣
But you were faster.
MIT it is already for 2.0.1 :)
Also makes much more sense for Swift Packages with Swift source files. LPGL didn't suit that well.

All the best!

[otherguy]

@paescebu that's awesome!

I just used it for a custom calculator number pad in an expense tracking app.

Not sure if that app will ever make it to the App Store but if it does, it will be in part thanks to this project 🙂

Thank you again!

[paescebu]

@otherguy Perfect use case 🙂
Let me know once it's out!
Wanna see it in action :)

[otherguy]

Will do!