3 ms·

I thought the LGPL required you to allow the user to update the library to a newer version (usually accomplished by making it a dynamically linked shared librar

• aaronblohowiak 16y ago
  I meant to upvote you, and missed the up arrow. Sorry.
• deleted 16y ago
  [deleted]
• _delirium 16y ago
  The LGPL doesn't require in-place modifiability, just that a user could build a working binary from a newer version of the LGPL'd library and your binary, along with appropriate dev tools and assuming no interfaces have changed. For statically linked C code, the LGPL suggests providing a linkable object file (.o) that the user can use to relink against newer versions of the library. I think that's already the case with Java apps by default, though, because a user can just dump new versions of the library's .jars in to your app, overwriting the old version. Even if you've slurped everything up into one big .jar, they can still extract the new .class files into the .jar, overwriting the old ones. Then they sign the app with their own key and install it on their phone. In practice though most LGPL-software authors don't even seem aware of this clause (I wasn't until recently) and aren't inclined to enforce it. A bunch of LGPL game libraries, like Ogre3d, have explicitly added a "you can statically link with no hassles" exception, to formalize that understanding. Might be a good idea here?
  • theBobMcCormick 16y ago
    I think it'd be a good idea to explicitly state it, but you know, it's up to you.