-
-
Notifications
You must be signed in to change notification settings - Fork 373
projectM Licensing
On this page, you find information about how to adhere to the license terms when using projectM in your application in relation to the licensing model the application will be released under.
projectM was developed as free and open-source software from the beginning, to provide a free-for-all reimplementation of the (at the time it was started) closed-source Milkdrop WinAmp plug-in.
To keep the source code available for everyone and prevent closed-source forks, but still enable developers to integrate projectM into closed-source applications, the GNU Lesser General Public License (LGPL) was chosen.
You can find a copy of the license in projectM's source code, which is currently using version 2.1 of the LGPL.
It doesn't matter what kind of application you write (e.g. a standalone app, a plug-in for a third-party software or another library) as long as it consumes/calls the projectM API or uses/calls any code in the projectM source tree, it needs to adhere to the licensing terms to be legally used.
If in doubt, consult a legal expert specialized on open-source licensing. The projectM team can help with some simple cases, but we cannot give legal advice. GNU also provides an FAQ on (L)GPL licenses where you might get the required answers.
It is not possible to buy a commercial/closed-source license for projectM.
This is the license under which you release your own code/application that is using projectM.
This is the easiest case. As your application is already using the same general licensing terms, users will always have access to the source code of both your application and projectM and thus can freely edit and (re)build the application.
Only under this licensing model it is possible (but not advisable) to copy the projectM sources directly into your application sources.
For modifications to projectM sources, please see the chapter below.
Most other open-source licenses allow users to freely edit the application sources and build closed-source applications from it. In such cases, the application developer must make sure that
- either the modified sources are guaranteed to be available to anyone needing to relink/rebuild the application and/or projectM,
- or link projectM as a shared/dynamic library and publish any API changes that would prevent replacing the library with one only built from the projectM sources.
In the first case, the application's license must contain such a term, in addition to the license originally used. If in doubt, either consult a legal expert or treat your application the same as a closed-source one.
You should not copy projectM code directly into your application sources, as it would make it impossible to separately build projectM. Better use it as a Git submodule or a separate library in your build system.
If your application is proprietary and closed-source, you must only link projectM as a shared library, making it possible for users to replace the projectM library with another copy.
On most embedded and mobile platforms, this will probably be hard to achieve due to code signing, limited application package access and so on. It's then impossible to use projectM in such environments unless you also put your application under a GPL-compatible license.
In addition to this, you also need to make a copy of the exact projectM sources used for building your application available for anyone asking, even if you did not make changes to them:
- The application or accompanying documentation must clearly state that projectM is used in your application.
- You must provide information how the user can obtain a copy of the sources.
- It is not sufficient to only provide a link to projectM's official GitHub repository. You need to keep a copy of the code used for each application release.
One way of doing it would be creating an archive of the sources, put these on your application/company website and provide the download link somewhere in the application. Another valid way is telling users to ask you via e-mail and send them either a link or the source package in return.
You must not copy projectM code directly into your application sources, as it would make it impossible to separately build projectM. You can still use it as a Git submodule if it is linked dynamically, but to make sure it can be built separately, it is advisable to do the same and only use the public headers and shared library to build and link projectM with your project.
Since projectM is open source, you are free and welcome to make any modifications you want to the projectM sources. You are not required to commit your (possibly very application-specific) changes back into the official repository, but you need to make the changes available to the public and also tell users of your application that they need to use your modified projectM sources to build their own versions of the library.
The easiest way would be forking projectM into another public Git repository (GitHub, GitLab etc.) and make your changed there. This way, users have both easy access to the sources and can also possibly contribute to it.
At a minimum, you need to provide an archive with the source code used to build each of your application releases and make it available either on your website, an FTP server, e-mail. You can even send it via snail mail on physical mediums.