Licensing Clarifications
Version 1.2 (October 4, 2006)
Introduction
Thinking Stone is a UK company that specialises in development of web application firewall technologies and related software tools. Our main goal is to make web application firewall technologies accessible to everyone. We are pursuing this goal by using a dual licensing scheme for our web application firewall software.
Why we choose dual licensing
We choose dual licensing because it allows us to satisfy groups with diverse interests. The open source licence exists to make our web application firewall technologies available to the end users, and to allow a community to form and thrive. Our commercial licences (and the corresponding support services) are designed to work for organisations that want to use rock-solid software and benefit from having access to reliable support. Commercial licensing is also aimed toward those organisations that want to build upon our technologies but don't want to share their work with the community. Most importantly, the revenue stream generated by commercial licensing allows us to continue to exist and develop our technologies.
ModSecurity for Apache Community Edition
Since ModSecurity for Apache is licensed under GPLv2 anyone is free to build upon it, provided the terms of the licence are complied with. In short, this means the modifications and the new parts must also be released under a GPLv2 licence (dual licensing is not allowed). The requirement to "give back" is the very reason we chose to use GPLv2. Please respect the spirit in which the licence is given.
If you do not believe the terms of GPLv2 are aligned with your business goals we will be happy to arrange a commercial licence that is better suited to your requirements.
We are providing the following answers to frequently asked questions:
- ModSecurity and Apache use different licences but this does not affect you as the end user. You are perfectly within
your rights to combine ModSecurity and Apache for your own use. We want you to use it.
- However, it is not possible to combine ModSecurity licensed under GPLv2 with the Apache web server and distribute the combination. There is an incompatibility between GPLv2 and
the Apache licences that is triggered when distribution takes place. (For more information see http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses.)
- We are happy for you to build your product around ModSecurity licensed under GPLv2. If you choose to do so you must license your product too under GPLv2 and make the complete source code freely available for download on your web site.
- Please respect our trademarks. We are making our software available under an open source licence but we are not giving you rights to use our trademarks. Please refer to the "Thinking Stone Trademark Usage Guidelines" document for more information.
- Some companies believe they can simply create an user interface for ModSecurity, keep the user interface proprietary, and still use the GPLv2 version of ModSecurity. This is not the case. Graphical user interfaces are the integral part of your product ("work based on Program", as defined in the licence) and thus subject to GPLv2 too. (Whether or not you choose to modify the ModSecurity source code is not relevant.)
- We do not want to "force" you to use GPLv2 for parts of your software that are clearly not related to ModSecurity. There is a simple test to determine if this is the case. Remove ModSecurity from your product. If what remains continues to be 100% operational then you do not need to apply GPLv2 to it. If there are parts of your product that are no longer functioning then they are obviously integrated with ModSecurity and you must apply GPLv2 to them.
Do note that, if you choose to create a product that is part proprietary, you must also ensure the GPLv2 parts of the product are fully usable when the proprietary parts are removed. In other words, the GPLv2 parts must not rely on the proprietary parts.
ModSecurity Rule Language
ModSecurity Rule Language is a programming language designed to analyse HTTP traffic and act on it. With the interests of the end-users in mind, we are happy for third parties to provide their own implementations of the rule language, provided they respect the following terms:
- Third-party implementations must specify (in the documentation and the configuration files) that they are providing an independent implementation of the ModSecurity Rule Language:
This product implements a subset of the ModSecurity Rule Language, which
is developed by Thinking Stone Ltd (http://www.thinkingstone.com).
Or:
This product provides a complete implementation of the ModSecurity Rule
Language , which is developed by Thinking Stone Ltd
(http://www.thinkingstone.com).
- Implementations must implement either a complete rule language as documented in the user manual or only a subset. If they choose to implement only a subset of the language then they must document exactly what is implemented and what isn't. The implemented parts must behave in exactly the same manner as documented in the ModSecurity User Guide. Implementations that fully support a specific version of the language can merely point to the corresponding documentation file on the ModSecurity web site. Further documentation is not required.
- Third parties must not extend the ModSecurity Rule Language with features that are not available in ModSecurity. However, if you come up with a feature you believe might be of interest, do contact us. We would be happy to collaborate with you to include it in the ModSecurity Rule Language.
Should you have any questions and require further clarifications please contact us at contact@thinkingstone.com.
|