Legal Cred for an Open-Source Project

I am not a lawyer. The information here is not, not is it intended to be, legal advice. 

Many open source projects unfortunately don’t concern themselves with presenting a clear legal perspective, which could be costing them community!

An open source project must present legal credibility to be considered seriously by a commercial enterprise.

I recently attended the iTech 2017 convention in Calgary, where the luncheon keynote was Digital Transformation Leaders Are Few and Far Between from Snehanshu Shah, SAP Global VP Customer Innovation. Shah purported that leading companies in digital transformation will use next-generation technology to continuously improve core infrastructure, while quickly incorporating new technologies for competitive edge, and that technologists who can apply inexpensive technology to solve these business problems will have value. Open-source software is now a proven development model with communities of essentially independent developers, collaborating in a non-competitive environment and sharing the development labor. It is inevitable that the business transformation spoke of by Shah will be aided by open-source software technologies, driving down the cost of infrastructure and providing sources of competitive advantage in a digital age.

It is in the nature of a young open-source project team to organise itself loosely. This should not be surprising, considering project members are typically volunteer developers donating their time to scratch their own personal itch, and more interested in writing code then in documentation or project process. A mantra of the open-source community is Talk is cheap. Show me the code. However, this is not to disparage project teams because it is hard to have value without working code.

Unfortunately though, this behavior is in contrast with a commercial enterprise’s typical need for security and stability to operate in the best interests of its owners. An enterprise must be absolutely confident that their adoption of a particular open-source software application cannot be jeopardized later, for example through misunderstanding or lack of appreciation for legal concepts by the project team, or a falling-out within the team leading to a disagreement over code ownership. A commercial enterprise requires confidence of longevity.

Ownership (Copyright)

The fundamental aspect of credibility is clear ownership of source code and other assets. Major projects often require contributors to sign a Copyright Assignment Agreement (CAA) or a Contributor License Agreement (CLA), which for all intensive purposes transfers ownership of the contribution to the project. However, this requires creation of a legal entity to assign or license contributor rights to, which is often beyond the need or ability of a smaller project team.

Simpler approaches are possible. For example, the Maestro project includes a legal statement in one of the project’s source code files – in the README.md file. The statement specifies the license under which the software can be used, that contributors retain individual copyright to their work as recorded in the repository commit log, and that contributions are accepted with the assumption they were provided under the terms of the same license. The legal statement was committed to the project repository before any contributor contributions were accepted. This approach was deemed sufficient considering the project potential and risks, and ultimately a business decision.

License

The second-most fundamental aspect of credibility is the license, and the license terms that control use of the software. To have value, the license must be be legally binding and enforceable. Well understood and even legally tested licenses exist, but many open-source developers still write their own license, based on how they would like their software to be used. For example, Anuko Time Tracker, a popular web-based timesheet system, uses its own Liberal Freeware License, which appears to address the same concerns as more established and tested licenses such as the BSD, MIT, and Apache licenses. To an enterprise, not using a well-known and understood license can easily prevent an application from being considered further. Enterprises must be concerned with potential liability, and a well known and tested license will provide greater credibility. 

Permissive vs Copyleft

The anticipated use of the software must of course be compatible with the terms of the license, but also potential future use should be considered. There are two basic types of open-source licenses, permissive and copyleft. The two have very different goals and different implications for a commercial enterprise.

The goal of a permissive license is to encourage use through as few restrictions as possible, while the goal of a copyleft license is to ensure source code remains available even if modified by a third party. Commercial enterprises generally prefer a permissive license to a copyleft  license because it reduces risk of the license constrain the business at some point in the future. 

The original copyleft license was the GNU GPL, which required that source code be provided to everyone the application was distributed to. When remotely served web applications became popular, it was realized that GPL-licensed web applications hosted remotely did not have to make source code available, because the application wasn’t being distributed according to the GPL. This was against the philosophy of the copyleft community and became known as The ASP Loophole. As a result, the GNU Affero General Public License (AGPL) has become the popular copyleft license for web applications, requiring that source code be available to anyone who accesses the application. However, having to make source available should not be the greatest concern to a commercial enterprise for a copyleft license. The greatest concern should be whether the copyleft license could constrain future business direction or opportunities because of how the license extends itself to integrated – or integrating – applications to also apply to the end result. 

To explore this using an example, first assume an engineering department within a commercial enterprise is trying to improve project management, and starts using Anuko Time Tracker as an electronic timesheet system to record time spent by employees on projects and tasks. If use of  Time Tracker proves successful, the enterprise may expand use to other departments as well. Eventually the enterprise may make minor customizations as well as provide access to contract staff for entering their time, and to clients for reviewing their project’s dashboard. Assuming Time Tracker continues to be successful, the enterprise may want to integrate it with other internal systems, such as a vacation database or ERP system.

Because Time Tracker  uses the permissive Liberal Freeware License, there will be no practical constraint on how the enterprise can use, modify and integrate Time Tracker –  ever. However, if Time Tracker had been licensed using the AGPL, not only would customizations have to be shared with clients, subcontractors, and possibly competitors, but integrations with other applications may be impossible due to incompatible licensing. While it may be possible to perform an integration without the copyleft license becoming “viral” (a popular metaphor, implying that a copyleft license “infects” everything it touches), careful review of both the specific licenses and of the software architectures involved will be necessary to establish business viability.

In Conclusion

If you want to attract enterprise users to your open-source software project, then remove obstacles from their path. It doesn’t matter what you think, it’s what they think. Perception may not be reality, but it’s perception that matters. Make it easy for outsiders to understand the legal position of your project, and what the implications and options are.  

There is a plethora of legal advice on the internet, some useful, some less useful, and some absolutely wrong. Laws are specific to a jurisdiction, and much will simply not even apply to you. There are also subtleties and implications that only an expert can competently advise on. If it’s important, seek professional guidance!

For more anecdotal information, TWIT.tv‘s FLOSS Weekly podcast interviewed several project teams that had to deal with legal issues.

  • Roberto Rosario had to develop Mayan EDMS in a way that would permit GPL licensing although he was working as an employee of the Porto Rico government, and also deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.

 

Remember, if it’s important, seek professional guidance!

Open Source Software – Copyright, Trademark and License

I am an engineer, not a lawyer, and this post is not professional advice. Legal documents can be complicated and interpretation may depend on jurisdiction, context and domain. You should consult with a lawyer if the risks and consequences are important to you.

Open source software is a concept that enables software development and support to be shared by a typically non-competitive community. An open source project is more than just code, it is also a community motivated by common goals and bound together by the relationships formed by working collaboratively.

Open source projects use one or more forms of intellectual property (IP) rights protection to protect itself against being taken advantage of. These are copyright, trademark and license. Copyright protects ownership of the software source code, trademark protects the project name and image, and a license protects the project community from liability.

Copyright

Copyright is a legal concept that gives the author of an original work exclusive rights to their work. The copyright for a line of code is generally held by its author (developer), unless it is assigned to someone else. Assignment may be implicit, such as when an employee creates code for an employer (“works for hire”), or explicitly through a formal agreement, such as a Contributor License Agreement (CLA) or Copyright Assignment Agreement (CAA).

Open source projects generally follow one of two options:

  1. Contributors retain individual copyright to their contribution. Author of have an inherent copyright to the code they write, but to limit liability, some projects require contributors to submit a Contributor License Agreement (CLA), which states they have the legal right to provide their work to the project and any conditions they impose (e.g. the license).
  2. Contributors assign their copyright to a legal entity used by the project for that purpose, using either a Contributor License Agreement (CLA) or a Copyright Assignment Agreement (CAA).

Open source projects most commonly follow Option 1, in particular ad hoc projects. As a side-effect, it makes re-licensing almost impossible as it would require explicit consent from all copyright owners. Option 2 is most common when the project uses multiple licenses for different users (e.g. an open source license for some and a proprietary license and revenue opportunity for others), or if the project doesn’t want to preclude potential re-licensing in the future.

Trademark

Trademark law will provide practical protection of the project’s name, so long as the project uses the name in a way that can be trademarked, generally some type of logo. An individual (e.g. the project founder) or a legal organization owns the trademark (which preferably should be registered), and allows for its fair use by creating a Trademark and Logo Policy (e.g. the Drupal Trademark and Logo Policy).

A Trademark and Logo Policy clarifies rights over the use of the project’s identity. Your name and logo are important to your community, and may want to create T-shirts, booth displays at trade shows and conferences, support material for clients, etc., that incorporate the project name and logo. The Trademark and Logo Policy controls their use to the benefit of the project as a whole, and provides a background from which abusers can be legally instructed to stop.

License

Generally, the simpler the better but some projects use different licenses for different things, such as the GPL for code and a Creative Commons license for documentation.

Use a permissive license (e.g. the BSD, Apache or MIT license) if you want the software to be usable by as many people as possible. Use a copy-left license (e.g. GPL or AGPL) if you want to enforce users giving back. Commercial users may be wary of copy-left code in general, as it requires more thorough consideration to ensure the copy-left license won’t be applied to more code than intended once it is integrated.

Recommendations

1. Include a License and Copyright statement in the project source code (e.g. in a README file), and also state prominently on the project website. State the license for the code, and who owns the copyright. Describe any legal requirements for submissions, such as whether a CLA or CAA must be submitted first, and terms assumed to apply to submissions (such as the same license terms as the project). Explicitly say whether the license covers Plug-ins or other extensions.

The GPL is generally understood to apply to Plug-ins, but being explicit will avoid potential misunderstanding or disagreement, clarify the intent of the project and even encourage development (and save you from having to repeatedly answer the question).

2. Include a Trademark and Logo Policy statement in the project souce code (e.g. in a README file), and also state prominently on the project website. State who owns the trademark and/or logo, whether it is registered, and describe what is, and isn’t, considered fair use.

3. Publish a list of open source dependencies (the open source projects that your project depends on), including the license each uses. Make it easy for potential users to evaluate the implications. Ensure each included project identifies its own license in your repository. If needed, work with subordinate projects to help improve their legal clarity as it will benefit both of you.

Related Information

Bob Jacobsen had to regain control over the open source model railroad controller software he had written to clear his name professionally. See FLOSS Weekly Episode 117 and Java Model Railroad Interface (JMRI) in Wikipedia.

Roberto Rosario had to develop Mayan EDMS in a way that would permit GPL licensing when he was as an employee of the Porto Rico government, and also had to deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.