Free and Open Source Licenses
With SMF 2.0 released as BSD 3-clause, SMF has started on the route of a Free and Open Source project, meant to truly share the project to and with its community.
This guide is meant to help you choose for yourself, for your own software or documentation, customizations to SMF, tools, integrations, design, whatever you build on SMF, a license for your work.
In the following, I use the terms free software, open source, and free and open source, interchangeably.
Principles of Open Source licenses
Open Source has a very varied landscape today, however there are commonalities between them. Widely cited, are the principles distinctly common between all the variety of the particular movements, and licenses, and sharing for your work as Open Source.
- The freedom to use, study, share with others, modify and share your modifications.
For example, please see the OSI definition (Open Source Initiative).
Wikipedia entry: OSI approved licenses
Quick highlight: Your software is Open Source if it allows free redistribution, access to source code, derived works based on it, and sharing them with others.
You can specify conditions (licenses specify those conditions), but conditions are not contradicting these basic rights offered to users of your software. If your conditions are against these (and a few others), then your software is not Free and Open Source.
Open Source Licenses
There are 3 rough "categories" of Open Source licenses, depending on what kind of conditions you'd like to put on your work.
Permissive licenses.
(BSD-like licenses) Please see: wikipedia reference on permissive licenses.
Typically, these licenses allow users to use, change, and freely share the software and their changes to it, as long as proper attribution of the original author is kept in place. Give credit where it's due, and for the rest, allow users to freely do what they wish.
SMF 2.0 license is BSD 3-clause, a permissive license.
BSD requires users to keep in place the copyright notices, and to not use the name of the original developers and copyright holders to endorse or promote your modified distribution.
Weak copyleft licenses.
Typically, these licenses mean that the author is granting users the right to use, share, modify the software, and share their modifications to it, as long as they share the modified software under similar conditions as they have received it, so that the software itself (modified or not) will always remain Open Source.
The wiki content at Simple Machines site is licensed under CC-by-SA 3.0. CC-by-SA 3.0 license is not meant for software, though, it's written for content, like design elements, images, documentation, text. It's based on the same principles as weak copyleft: do what you wish with this work, as long as you respect proper attribution and share it, modified by you or not, as you received it: Attribution and Share-Alike.
While it's an example for the principle here, the license wouldn't be appropriate for software for at least two reasons:
- it doesn't specify what "adaptation" and "collection" could mean for software, meaning what kind of derivatives are covered by Share-Alike and which are merely additions to a "collection". Depending on how you define it, you could actually have a strong copyleft or a weak copyleft, and enforcing it legally is probably not possible.
- since it wasn't meant for software, it wasn't considered by OSI in its Open Source software licenses list and are not addressed by other license stewards for compatibility guidelines. (you wouldn't be able to integrate your software with GPL for example. If that's a good thing or a bad thing, it depends on your wishes for your code.)
For a software example, Mozilla Public License 1.1 (MPL). Software under MPL 1.1 means you are allowed to use, modify, share, and share your modified version, as long as when you share your modified version you distribute it under MPL 1.1 (or later) yourself, in addition to keeping intact the copyright notices of the initial developers and contributors. (and a few more conditions designed to protect from patent issues). MPL 1.1 assures you that your work will always be available to users (whether they received it directly from you or others, and whether it has been modified in the process or not) with your copyright, credit, and always with the right to do the same themselves - your users, directly or not, will always be free to share it at their turn. The software will remain Open Source. (it can't be taken by a company, modified, stripped from original licensing terms, and made available to users under more restrictive conditions than you specified yourself - ever.)
You are, however, allowed to build anything on it (external tools interacting with it, extensions to it, plugins, themes, whatever you wish), and license them in any way you want. This allows proprietary software to be build on the original software, to use it freely and extend it freely, but the original software, in modified form or not, will never to become proprietary itself.
Please see for further information: MPL FAQ.
Strong copyleft licenses.
Strong copylefted licenses are designed to make sure that if a piece of software is a derivative of your code, in a very strong sense (including plugins in some interpretations) the software as a whole must be distributed under your license, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available - under the same or a compatible license. This may mean that extensions of your work, such as plugins to your software, are also free and open source themselves. The most known license of this type is GPL. While there are more than one interpretation on how GPL should apply to software in PHP, generally the idea of a "viral" license is catching the meaning pretty well: give or take interpretations, software built on GPLed software is also at least compatible with GPL, if not GPL itself. (otherwise it's a license violation).
Particular cases for SMF
SMF mods, by their nature, are similar to patches to the main codebase, if they're written the traditional way, by modifying directly the source code. By that itself, mods are patching the main codebase, creating a directly derived software. Arguably, legally, SMF itself couldn't possibly have a license allowing for free patching in any way mods authors want (not only copylefted, but also including proprietary mods), unless this license preserved the right of mods authors to create custom-licensed and proprietary modifications of the code. SMF's goal is to be a Open Source project which will always preserve the right of mods/extensions authors to create any mods, including proprietary or closed licensed mods: which is why today SMF 2.0 has a permissive license.
You can license your mods anyway you wish, and make them do whatever you want them to do (as long as you don't use a mod to strip SMF's copyright notices from source files). This little guide is designed to help you choose an Open Source for your work.
SMF themes are in a similar situation: SMF themes imply modifying SMF template files to create the desired layout, and by the BSD license of the default themes, theme designers can, freely and legally, create themes of their own which they can license under any terms, including proprietary or commercial themes.
Same goes for themes again: you can license them anyway you want, and include your modified template files, in your themes (as long as you don't remove SMF's original copyright notices).
For a guide on how to license your mods and themes, please see:
