search

papyros / qml-material

:book: Material Design implemented in QtQuick
GNU Lesser General Public License v2.1
2.56k stars 476 forks source link

Question about License #122

Closed naguirre closed 9 years ago

naguirre commented 9 years ago

Hi,

I would like to know if it's possible to use qml-material in a closed source application that would be sold on Android or iOS market ? Does the LGPLv2+ in case of QML permit this kind of use ?

ricardomv commented 9 years ago

I think the case here is the same as java basically you have to share the changes you made to the library (if any) and include source code for the library.

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.

When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.

The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

but IANAL and you should wait for the project owner to answer @iBeliever

naguirre commented 9 years ago

@iBeliever any idea ?

iBelieve commented 9 years ago

@naguirre I'm not a lawyer, so I'm not 100% on the answer to your question.

However, we're using the same license as the open-source version of Qt, so it should be fine. In terms of complying with the license, you need to make any modifications available under the same or another compatible license. I belive you also have to include a link to our project along with the name of the LGPL license (in your About or Help section of the app), so users can get the source if they are interested in it.

You also need to allow users to swap out and modify our library in your app, and reverse-engineer your code to make any of their modifications to our library work with your code (as per the link @ricardomv shared).

ricardomv commented 9 years ago

@naguirre can this be closed?

iBelieve commented 9 years ago

I'm closing this since there hasn't been any recent activity on it. @naguirre, if you still have a question, please re-open this ticket and I'll try to answer your questions.

koloboid commented 9 years ago

Hello. As we know, Qt Indie has own commecial licence, escpecially to be compatible with Apple's AppStore. So, what you think - does Qml-Material applicable to use in iOS apps, with sharing on AppStore? AFAIK, applications contains GPL'ed code with no commercial alternative has moderated by Apple. May be Qml-Material needs something like Qt's commercial?

iBelieve commented 9 years ago

@koloboid That concern was brought up by another person as well. I chose the LGPL because I want to make sure that we are able to bring back any changes made public by anyone who uses the library. I did not know at the time that there were concerns with the app store. I am not a lawyer, and cannot offer legal advice, but it does seem like there are potential issues with using an LGPL library in an app published in the iOS app store.

So, we have two options: offer a paid commercial license in addition to the LGPL license (which would give us a nice source of income to continue developing the project), or switch to a more open license like Apache (which unfortunately doesn't require that modifications are published for us to use if we want). Either way, we'd have to reach out to the 23 or so people who have contributed to the project, and get their permission to use a different license.

koloboid commented 9 years ago

@iBeliever thanks for reply. I'm absolutely agree with LGPL. Personally, I'm preparing some pull requests with my changes and proposals to this project, and I'm voting for dual-licensing option with commercial edition (like Qt Indie Mobile), specially for sick markets and maybe to hire some people for all Papyros project. It would be nice.

marco-piccolino commented 9 years ago

As long as license fees are kept lightweight, a commercial license could indeed help the project to be sustainable, or at least cover part of the expenses for running it. However, keep in mind that having two licenses means having two different codebases, because of different license information and, possibly, features. That would also possibly require to have two different Qt modules for import and managing more infrastructure to deal with payments, support etc.

A more liberal license (Apache, MIT) would remove this issue. Of corse in that case contributing back would be left to the bona fide of developers.

mobius3 commented 9 years ago

You can make modifications to LGPL with a clause of your own, allowing its specific use for app store. GCC has a clause like that allowing for static linking without making your project compliant to LGPL.

Em ter, 5 de mai de 2015 às 07:18, Marco Piccolino notifications@github.com escreveu:

As long as license fees are kept lightweight, a commercial license could indeed help the project to be sustainable, or at least cover part of the expenses for running it. However, keep in mind that having two licenses means having two different codebases, because of different license information and, possibly, features. That would also possibly require to have two different Qt modules for import and managing more infrastructure to deal with payments, support etc.

A more liberal license (Apache, MIT) would remove this issue. Of corse in that case contributing back would be left to the bona fide of developers.

— Reply to this email directly or view it on GitHub https://github.com/papyros/qml-material/issues/122#issuecomment-99020178 .

koloboid commented 9 years ago

@mobius3 you are taking about http://www.gnu.org/licenses/gcc-exception.html ? In this case we need to create incompatibility list between LGPL and ToS, and then compose exception. I think it's more complicated than dual-licensing. The final word must be from @iBeliever, I believe ))

malwoden commented 9 years ago

Am I correct in thinking that to distribute a closed source app that depends on Qml-Material the app would need to do one of the following;

  1. build a qml plugin/dynamic library (i.e. a windows dll) containing the complete Qml-Material library (Qt itself does this).
  2. Add the unpacked qml-material library along side the app and call addImportPath.

I believe either of these would fulfil the linking requirements or the LGPL?