Pull requests, commits, code reviews, and issues—these are the beating heart of open source projects. Without these transactions of code patches and technical discussion, the Concept to Clinic challenge wouldn't exist.
But it also wouldn't exist without the concept of free and open source (FOSS) software itself.
Today we want to highlight one of the less glamorous aspects of open source, but an aspect that goes to the heart of what "open source" actually means: licenses.
Software licenses: choose your own adventure¶
The choice between MIT, BSD, Apache, GPLv2, AGPL, LGPL can be daunting. These are not the most friendly or inviting acronyms, and none of the actual documents are what you might call "thrilling and plot driven." Most software developers are also not lawyers, so some developers view licenses as a necessary evil at best, old-fashioned gobbledygook at worst, or even decide to ignore licenses completely.
While some are vocal about free software and have strong preferences for which license to use on their projects, others are much less interested. After all it's not like the Free Software police burst in and put you in handcuffs if you use some code from a repository without a license. But (lack of) enforcement is not the point.
Licenses are important because they make explicit the agreement between individual and community, between end user and contributor, between contributors and corporations, so we should care about selecting the right licenses for our projects and about ensuring that the way we use software respects the license under which the code was released.
Not just a concern for hobbyists¶
That was a lofty argument for being explicit about licenses and about complying with license terms, but for any formal organization—from the largest corporation to the smallest non-profit—employees spend a lot of time and resources worrying about compliance and legal liability. Software licenses matter to these people.
What many hobbyists don't realize about professional software development is that free software is often viewed with suspicion rather than excitement by non-developers. This is particularly true in larger, more established companies who have staff specifically concerned with legal compliance. It gets even more fraught in companies that work in heavily regulated industries such as healthcare or banking.
Instead of a cool piece of technology or a time saving asset, free software is often treated as a liability. Common questions from managers would include:
- What if we need support?
- What if we adopt the technology and they decide to start charging money for this?
- Can we trust the software quality?
These are reasonable questions to ask, and they also have pretty satisfying answers when the open source model is explained. But the biggest question non-developers tend to worry about is this:
How do we know if we are legally allowed to use this software?
This is where the legal language of rights and obligations embodied in OSS licenses is important. The generally recognized OSS licenses use well understood and standard legal terms of art to very clearly lay out permissions and responsibilities.
Although there hasn't been much case law in the United States, these licenses are at least well characterized enough that organizations know the tradeoffs involved when they use packages released under, for example, the GPLv3 as opposed to BSD licenses.
Dependencies all the way down¶
Bearing in mind that a medium or large project can have tens or hundreds of other dependencies, each of which have dependencies of their own and so forth recursively, and given that organizations generally need to see a well known license in order to use each individual package, the next question is obvious:
How do we keep track of all the licenses that govern our use of free software?
In some organizations, a large spreadsheet or central tracker is used and reviewed periodically. Other organizations only evaluate software licences when a new dependency is added. In both cases, there is a review process to determine what licenses are attached to proposed libraries. Traditionally, this involved several stages:
- Every time a package was added to the project, engineers would have to remember to check its license.
- Then they would have to decide whether the license was compatible or not. If they were lucky, there would have been a preordained list of acceptable licenses but in reality it usually means that non-experts are interpreting what it means to "distribute" software.
- Finally, they would need to manually investigate all of that new dependency's respective dependencies recursively until everyone is so tired of the process that they give up on writing software and decide to become vegetable farmers.
If only there was some type of machine that could traverse graph structures recursively and execute a repetitive checking operation more efficiently than a human developer...
Enter FOSSA¶
For this project, we wanted contributors to be able to focus on writing code, but we needed the licenses to stay compliant. Concept to Clinic is an open source project, but the same desire holds for virtually every professional software development project.
Thankfully, a colleague recommended FOSSA which is a service that can "continuously scan and comply with open source licenses without slowing down development."
In addition to automatically figuring out the whole dependency tree, FOSSA guesses each dependency's license and flags possible conflicts and automatically notifies maintainers who can manually review and resolve any issues. They also do deep code scanning, where they check inside files for code released under a different license than the project.
We're grateful to Kevin and the rest of the FOSSA team for sponsoring the Concept to Clinic project. Head over to fossa.io and check them out!
