Simplify Open Source License Compliance
Creative, exciting applications of open source software can be found worldwide, and who better to share the details of new use cases than the practitioners themselves. In this blog series we’ll feature guests who told their open source stories during Practical Open Source Information (POSI) 2021, an online conference hosted by OSI. Check this channel for more practical open source stories.
Marc Jones is General Counsel at CivicActions, a professional services firm providing design, technology, consulting and training services to the government. He started his law career at Software Freedom Law Center and has advised various open source and free culture organizations over the past nine years. In other words, he has a lot of experience in the licensing of open source software and shared some of his top-level advice for anyone looking to open source a project. Here’s what he had to say:
At the start of the project, these are the basic things to consider:
- What will you name the project?
- Where will you publish the code?
Pick a unique name that will have longevity with the project. Down the road it will need to fit into a software distribution ecosystem, so it should not be too common a name, and it should certainly not infringe on any trademarks.
Marc advises making the project publicly available from day one. Giving it to third parties is the whole point of licensing and open sourcing a project. GitHub and GitLab are the most common places to publish code with distributed version control. Coordination of many file changes is what open source software platforms like Git are designed to do. Publishing here means copies can be shared, changes can be made to those copies, and suggestions can be made to those changes. It is this exchange of drafts and changes that makes the project open source.
After your project is named and you’ve chosen a repository in which to publish the code, it’s time to look at licensing options and important steps in setting it up. Marc shares nine popular OSI-approved licenses that lawyers and engineers are most familiar with. He also suggests considering whether you want a Copyleft license, which is designed to encourage users to produce and give back to the comments, or a Permissive license, which maximizes the number of people using the code with less restrictions on how they do it.
If the project was started with a third-party library, it’s wise to license your project under the same license that library uses. If you choose a different license, make sure the licenses are compatible, and be sure to update your LICENSE file with the library’s license. And don’t delete anything from the third-party code. Remember, this is a community: if the ecosystem in which your project lives prefers a certain license, Marc suggests staying aligned with that ecosystem and going with that license.
Finally, once you choose your license, add a copy to the LICENSE file and complete the README file, including a copyright statement and a clear statement of your inbound/outbound policies. These are basic set up procedures that are best not to be overlooked.
Watching Marc’s video will offer more details if you’re serious about open sourcing your project. You can do that below:
The previous blog in this series features an OSI board member talking about “How to talk to your boss about open source”. This concludes the blog series for the Practical Open Source Information (POSI) 2021 event–thank you for reading along! To keep up on industry news, events, and insights from open source thought leaders and more, sign up for OSI’s newsletter.