One of the most frequent questions I receive not only from engineers, but from other lawyers is “we are thinking of making a project available under an open source license – what do we need to know?” Since I get this question a lot, I’ll share with you the list of information I usually collect from clients to help them assess whether an open source license is right for them, which one they should use, how they should communicate licensing info to others, and whether they should consider creating codes of conduct, contributor guidelines, or contributor agreements (or DCOs) for their projects:
Outbound Open source checklist
Background Info
- What is the name of your project and the first version that will be publicly released?
- Please describe what your project does and the format in which it is made available. (Will you be providing just source or binaries, too? Will it be packaged as a virtual machine, container, etc.?)
- Where do you plan to make the open source project available? (ex.: Github, NPM, rubygems.org, etc.)
- Does the project have any use outside the context of using it in conjunction with other Company products or services?
- Do you have any reason to believe that there are Company patents on the technology you want to open source?
Technical Info
- Does Security see any issues in open sourcing the proposed project? Have you ensured there are no keys or credentials in the source code?
- Does your project contain any code licensed from a vendor (whether for free or for fee)?
- Does your project contain any integrations with any third-party products or services?
- Does the project have any “phone home” features? If so, please identify with specificity the data collected and why.
- Please submit an open source code scan of the project and its dependencies (including transitive dependencies) for review.
- The scan needs to be done before a main license can be chosen for the project because the main license of the project should be compatible with the licenses of the third-party code the project uses or pulls in. For example, if you want to license something out as GPL 2, you can’t include Apache 2.0 dependencies and vice versa.
- You will need to remove dependencies/components under commercial licenses or under licenses that are incompatible with the chosen license for the project as a whole.
Goals
- Explain why you want to open source this project. What are you trying to accomplish? Why is this preferable over a proprietary license or a proprietary license that gives access to source code?
License
- Have you thought about the sort of license you’d like to release this under? If so, what is it and why?
- If the project is used by a competitor or a provided as a service by a big cloud services provider, does that pose issues for the business?
- Can you foresee any reasons why you might later regret open sourcing this project?
- Do you expect proprietary Company products to incorporate this code in the future?
- Do you expect that this project might grow into something you might want to commercially license in the future?
Developer/User Expectations
- Do you intend to grow a community around this project or are you just looking for an easy way to get code into the hands of existing customers and partners? If you want to grow a community:
- Who will be responsible for managing the community?
- Are you committing to responding to pull requests and issues on a prompt basis?
- Are you going to provide any formal support for users of the project?
Once this information is collected, I can provide clients with more specific guidance with respect to marking their source code, providing licensing info in their chosen distribution channels, how to set up a contributor agreement intake process (if necessary), how to set user/developer expectations appropriately, and how to attribute third party open source packages used in the project. However, sometimes we all discover that the necessary ingredients for creating an open source project aren’t there and we can walk through alternatives or the steps necessary to be ready in the future. I hope you find this useful!
