A key aspect for a FLOSS project to be successful is to choose the correct licensing scheme. There are tons of license you can choose from, a good starting point would OSI's Licenses & Standards page. Take some time to review some of them, as each one defines duties and benefits that you as an author, your contributors, and the users of your code have access to. When in doubt please contact someone that's knowledgeable in the subject, for example you can reach out to the OSI directly, or ask at the mailing list/forum of a popular project which may have a licensing scheme similar to the one you may be looking at. There's also the option to join a software foundation such as The Apache Software Foundation, The Eclipse Foundation, The Software Freedom Conservancy, among others. Not only can they explain to you the benefits of their preferred license and why it would be a good idea for your project to choose it but also can help you with legal counsel should you need it.
Once you've chosen a license it's very likely that you have to include a hard copy in your project sources. The recommended way to do this is to paste the plain text of the license in a file named LICENSE at the root of your sources. This make its very easy to find at first glance. Also, GitHub will be able to recognize the license and list it appropriately if you happen to host your project on GitHub. Most licenses require a hard copy to be included with the binaries and/or artifacts produced by the project. If you happen to use Gradle as your build tool then it's a matter of updating the configuration of the jar task found in your project. For example, in the BootstrapFX project (which is setup as a multi module gradle build) I make sure to include a copy of the license file when the binary JAR for the core project is generated, like so
jar {
metaInf {
from(rootProject.files('.')) {
include 'LICENSE*'
}
}
}
If you happen to define multiple versions of the license (such as Markdown, Asciidoc, or other) then this piece of code will include all of them. Any other additional license files would be included as well. Another item you must keep in mind is making sure that source files define a license header that matches the license's restriction. In the case of BootstrapFX the chosen license is MIT. You can see that GitHub shows detailed information about that license and its terms here. Using Gradle as a build tool you can configure a plugin that can verify and format all source files with the appropriate header. Simply apply the hierynomus/license plugin and configure it to match your requirements. The plugin allows you to define the header using a template, whose format follows the Groovy StringTemplate engine, in other words, you can define variables using the ${} notation, such as
Copyright (c) ${year} Andres Almiray
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
The next step is to actually configure the plugin, like this for example
apply plugin: 'com.github.hierynomus.license'
license {
header = rootProject.file('config/HEADER')
strictCheck = true
ignoreFailures = false
mapping {
java = 'SLASHSTAR_STYLE'
fxml = 'XML_STYLE'
}
ext.year = '2015-2017'
exclude '**/*.png'
exclude '**/*.scss'
}
This configuration will make sure that a license header check task is running during a full build or when the check task is invoked. The build will result in a failure if any of the source files is missing the correct header. Sadly the plugin can't check the headers of the main Gradle build file, nor any other Gradle file; I'm afraid it's up to you to manually update those files.
An added benefit of applying this plugin results in the capability of generating a license report for all your compile and runtime dependencies. This is a great boon for projects that must ensure certain dependencies are excluded given the licensing terms that govern them. For example, if a dependency is listed as GPL it means that your codebase must adhere to GPL too; some people are OK with this, others are not. Invoking gradle downloadLicense will generate XML and HTML reports matching artifacts to licenses, and licenses to artifacts; thus giving you an option to further process the data in any way you deem necessary.
If you happen to be using Maven as your build tool then you have access to the apache-rat plugin which gives you the capabilities to verify and format license headers; unfortunately no possibility to create a license report for all dependencies is available.
Many FLOSS developers work with a honor system in mind; none get into this business trying to stab people in the back, that doesn't mean there aren't people out there that will try to stab you and take away what you and the community have built. This is the primary reason for choosing the right license. You can also make sure that every contributor agrees on the licensing terms before accepting their code in your project, a CLA (Contributor License Agreement) is often used to achieve this goal. If your project is hosted at the ASF or the EF then you're already covered, as every contributor has to sign the CLA before pushing contributions. But what about projects that do not belong to any of these foundations? You may need to setup your own CLA scheme, complete with hard copies of signed documents. This can get tiresome and difficult to manage as the community grows, it would be great if some of the paperwork could be automated. Which brings us to the next online service named CLAHub.
CLAHub hooks into a GitHub repository and checks contributions (usually sent as Pull Requests but online edits will work too) to figure out if the author has signed an online CLA. If he has not then redirects (or provides a link) that the user can follow to read the CLA and either approve or reject the terms. If the terms of the CLA are approved by the user then the contribution will proceed and the PR may be merged. If the terms are not accepted then the PR is marked as failed. Once the CLA is electronically accepted any further contributions from the same user will pass this check more quickly as CLAHub keeps track of who has accepted the terms. CLAHub follows a template approach allowing you to define any kind of terms and conditions, also what personal data is required for the user in order to accept the terms (usually name, email address, and GitHub username are enough).
Disclaimer: I’m in no way related to CLAHub. I merely provide information on this service based on its open usage. I'm a member of the ASF and the EF software foundations.
