-
I have a question regarding Skip's licensing requirements. As I understand it, Skip is licensed under the LGPL v3. The license has the following stipulation under Section 4 ("Combined Works"):
The FAQ for "Can I use Skip in a closed-source commercial app?" on the Skip web site says:
Assuming that they've not made any changes to LGPL'd Skip code itself, how are closed-source developers using Skip's LGPL-licensed libraries supposed to comply with the requirements under (d) in the LGPL? The FSF's FAQ on this says:
I'm not sure if Skip is statically or dynamically linked, off-hand, but in either case it is 1) being combined with proprietary/closed code and distributed, and 2) isn't already present on the user's computer. In either case - static or dynamic linking - it's not clear how to permit a user to "recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work." They just have a binary that they install from the App Store or Google Play. There is no functionality for modifying the library or relinking anything. I'd love to use (and pay for!) Skip - and want to make sure to comply with the expectations of the license - but I do worry about the LGPL being used as the license as it seems like it could open developers up to some degree of legal liability. Some guidance on this would be much appreciated. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
We certainly do expect people to be using Skip's LGPL libraries in closed-source programs. Libraries like WebKit and JavaScript core are LGPL, and they are used ubiquitously throughout both iOS and Android apps, both system-included and user-created (for example, every React Native app ships with a copy of JavaScriptCore on Android, where it is not included by the system). You are correct that the re-linking requirement could be deemed troublesome, not just because of practical complexities involved (which are different on iOS and Android), but also because there is no way to re-link any app on either platform to a new library version and still retain the original app's code signature, which somewhat defeats the spirit of the clause. Our general feeling is that if it hasn't been a problem for Apple or Google or any of the thousands of apps that use WebKit and JavaScriptCore, then it shouldn't be a problem for Skip. That being said, one possibility could be to add a linking exception clause to the Skip runtime libraries along the lines of this. Would such an exception to the license allay your concerns? |
Beta Was this translation helpful? Give feedback.
-
I'm honestly puzzled - what are you gaining by using LGPL for your framework libraries as opposed to one of the many OSS licenses which would allow unrestrained reuse? I'm in serious doubt about using or recommending skip because of the LGPL libraries you force upon users of the tech. I've had clients for whom this would be a deal breaker and will continue to call out the LGPL licensing as a potential issue in any discussions. As a very experienced cross-platform dev and having worked on multiple code-generators during my career, I'm extremely impressed with what you've accomplished with skip. I like the architecture and will give it a try for one of my personal apps. |
Beta Was this translation helpful? Give feedback.
-
We've added a note about Skip's LGPL linking exception to each of the project READMEs (e.g., SkipUI). This should put to rest any concerns over distribution to the various app stores. |
Beta Was this translation helpful? Give feedback.
We've added a note about Skip's LGPL linking exception to each of the project READMEs (e.g., SkipUI). This should put to rest any concerns over distribution to the various app stores.