Nov 07 2010

AndEngine and the LGPL – clarification!

Category: AndEngineNicolas Gramlich @ 23:53

Hello Community,

as the license-questions keeps popping up again and again let me clarify about AndEngine and the LGPL:

While AndEngine itself is licensed under the LGPL, you do NOT have to make your actual game-code available under the LGPL! The only thing you have to make available upon request are the changes you made to the Engine itself (which usually are none to very few!).

So I repeat here:
You do NOT have to make your actual game-code available under the LGPL!

This statement is official!

Best Regards,
Nicolas

13 Responses to “AndEngine and the LGPL – clarification!”

  1. Alocaly says:

    Hum…

    The LGPL licence implies that the user can change the library( to fix a bug for instance, or use a newer version ), and reinject the new fixed library in any application using this library.
    How can a user using an application based on AndEngine do that without the sources ?

    Basically, LGPL says that you don’t have to provide the sources of the application if it is linked dynamically to the library.
    And dynamic linking is not possible with Android !

  2. badlogic says:

    What Alocaly said. I fell into the same LGPL trap with my lib. LGPL is basically useless on Android. Switch to Apache 2, it has nearly the same feature set as LGPL.

  3. Ben C says:

    I have to agree that I see some issues with using the LGPL which are outlined on the android source site as to why they choose Apache 2.0 over LGPL.

    Why Apache Software License?

    We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.

    Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, but we don’t believe it’s possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don’t believe it is our place to force them to do so. Using LGPL libraries would often force them to do so.

    Here are some of our specific concerns:

    LGPL (in simplified terms) requires either: shipping of source to the application; a written offer for source; or linking the LGPL-ed library dynamically and allowing users to manually upgrade or replace the library. Since Android software is typically shipped in the form of a static system image, complying with these requirements ends up restricting OEMs’ designs. (For instance, it’s difficult for a user to replace a library on read-only flash storage.)
    LGPL requires allowance of customer modification and reverse engineering for debugging those modifications. Most device makers do not want to have to be bound by these terms, so to minimize the burden on these companies we minimize usage of LGPL software in userspace.
    Historically, LGPL libraries have been the source of a large number of compliance problems for downstream device makers and application developers. Educating engineers on these issues is difficult and slow-going, unfortunately. It’s critical to Android’s success that it be as easy as possible for device makers to comply with the licenses. Given the difficulties with complying with LGPL in the past, it is most prudent to simply not use LGPL libraries if we can avoid it.

    The issues discussed above are our reasons for preferring ASL2.0 for our own code. They aren’t criticisms of LGPL or other licenses. We do feel strongly on this topic, even to the point where we’ve gone out of our way to make sure as much code as possible is ASL2.0. However, we love all free and open source licenses, and respect others’ opinions and preferences. We’ve simply decided that ASL2.0 is the right license for our goals.

  4. Android 2D Game Engines — fanitis.com says:

    [...] with your projects, and you don’t have to release your source code, as explicitly stated in a blog post from the developer. It’s quite easy to use and provides loads of functionality which will [...]

  5. bond says:

    Is that Lesser GPL or Library GPL?

  6. dave says:

    What on Earth are you people talking about? The author of software owns the copyrights, and determines the use of said software. A license can ***NEVER*** inhibit the author from allowing more generous conditions of use. Arguments about what LGPL may or may not allow are completely irrelevant when the author has explicitly described legal use of his/her software.

    If you release your software under LGPL, you can, at any time you wish, permit freer use of your code. What you cannot do, as author, is release software under some universal open-source license, and then at a later date, restrict the use of the same software in some way. As author, all you can do is fork, and take a more restrictive control of the new fork.

    The real problem with these licenses is the philosophy behind them. GPL is designed to be a poison pill for those who would use such software to make money, so one should not be surprised when LGPL is described as still having the taste of poison. If one truly wishes to let people make any use of one’s software without restriction, GPL licenses should be avoided as a matter of principle.

    The concept of “is it dynamically or statically linked?” has never been tested in law, and if it were, would not give a good result for the GPL movement. Therefore, if one wishes to distribute libraries that only the author can change, free distribution of CLOSED-SOURCE libraries should be considered. If not, TRADEMARK the name of your library, and only allow those that use the library unmodified to reference your trademark.

    The ‘BAD BOYS’ already make fortunes by illegally using software against their community licenses, and nothing will stop them. Therefore, it is usually the community itself that is harmed by foolish use of the wrong open-source, or free distribution licenses. If you release your source for a small library, and someone can make money from the code, they’ll simply rewrite it if they must, and no license can prevent this. Otherwise, surely, as this type of software author, you want as many people using your code (and spreading your name) as possible, Restrictive licenses for free libraries usually ensure an every diminishing user-base, and success for competing libraries with less restrictive options.

  7. Alfons says:

    I have few apps on the Android Market and I now I wanted to start to write new game. As in many games I have to invest money in sound, graphics and code. AndEngine looks cool and I would like to use it but since it is LGPL I will have to find another framework. I bought one book about AndEngine and I like examples but there is no way to invest time and money in something that is linked with LGPL.

    I know that author said that our games should not be released under LGPL but AndEngine is LGPL and if a game becomes great hit big companies that have money and lawyers can always find the way to make your app LGPL.

    • Nicolas Gramlich says:

      AndEngine is moving to Apache v2 within the next week.

      • Alfons says:

        That is great news. I believe that this will dramatically increase usage of AndEngine. It is really great engine. Probably as good as Cocos2D on iOS and definitely there is nothing better on the Android OS.

        Now I will start to work on my game not only on iOS version but also on Android version. Thank you!

      • Dan says:

        Has this happened?

  8. Alfons says:

    Any changes in AndEngine license?

  9. Alfons says:

    It looks that it is time to start with another framework like libgdx or Cocos2d for Android that is not that good but is not LGPL. Bye bye AndEngine!

  10. Alfons says:

    Looks like libgDX is better and Cocos2d-x works on iOS, Android and Windows. Cool and it is not LGPL.

Leave a Reply