Savant Build Tool: License Management

Brian Pontarelli
  • By Brian Pontarelli
  • Technology
  • November 11, 2014

Magnify Glass on LicensesIn our first blog post, we briefly touched on the concept of licenses in Savant. Project licenses are a concept that is often overlooked in software development, but is extremely important. The legal nature of software licenses, both open and closed, can impact how a library, tool or product is used and deployed.

Most build tools allow projects to define their license, but it is often a free form text field in the project definition file. This causes a number of problems. First, these are impossible to parse reliably. Second, it is usually optional. This means that with most build tools it is impossible to correctly determine what licenses your software is currently using. Any lawyers reading this are probably starting to sweat and shift uncomfortably in their chairs.

Savant is built and maintained by Inversoft. Inversoft has a number of products that are commercially licensed. All of our products are on-premise and therefore downloaded by our customers and installed on their servers. This means that we need to be extremely meticulous about our use of open source licenses. If we were to use a library that was licensed under the GPL, it could have drastic ramifications on our products.

To solve this problem, we added a strict licensing system to Savant. Savant projects must define all of their licenses using one of the allowed license Strings. Savant doesn’t support every open source and closed source license, but it does support the most commonly used licenses. We are adding new licenses as we move forward.

This allows Savant to calculate every license your project is using and provide validation. It can also output all of your licenses into a directory so that you can ship those licenses with your project’s releases. You no longer need to copy and paste license files around. Savant handles all of that for you.

Savant also understands that some projects are dual licensed and allows a project to define multiple licenses.

Finally, some licenses are intended to be used as templates and that each project must fill out the template and can optionally remove and add sections to their license. Savant handles these cases using text files inside the project to define the license text. You can also override standard licenses such as Apache V2.0 with custom text if necessary.

Let’s take a look at how licenses are defined for a Savant project:

This project is dual licensed under the Apache V2.0 and BSD licenses. If we were to run Savant at this point, it would spit out this error message:

This is Savant letting us know that the BSD license requires custom license text per project. To fix this issue, we can create a file called license-BSD.txt in the root of our project. Savant will load this file and store it for later use.

When your project is released, Savant will add the license information, including your custom license text from the license-BSD.txt file to the artifact meta-data file. The AMD (artifact meta-data) file is how Savant manages artifact dependencies and provides its dependency management features.

Some projects need to ship all of their licenses in the release bundle. This is true for any on-premise software. The Dependency Plugin provides a method that allows you to output all of your dependencies licenses. Here is an example of using this method:

This will output all of the project’s licenses to the given output directory.

This is a brief overview of how Savant currently manages licenses. We have illustrated how you define your project’s license(s) and also how you can output the licenses your project uses using the Dependency Plugin. In future releases, we plan to add a license audit tool as well as more control over the license output mechanism.

Stay tuned for our next blog on Savant plugins.

 

Tags:
Savant