Questions About Open Source? Talk to our Digital Innovations Team
By Daniel Dardani
Open Source Software (OSS) and Open Source Licensing (OSL) have become integral parts of how software research and development is performed and shared with the world. As such, these two sides of one coin have enjoyed increased popularity of late, extending even beyond the traditional world of software programming. All researchers and, to some extent, the business and entrepreneurial community are abuzz with talk of open source with its opportunities for crowd-sourced software development, faster adoption, and wider utilization. However, despite its growing popularity, there is still much confusion over its core concepts, best practices, and strategies for effective deployment. The goal of this post is to provide a brief introduction to some basic open source concepts and tactics. For more hands on help with questions about open source, including how to leverage it with your own research projects at Duke, please contact the Digital Innovations Team at Duke’s Office for Translation and Commercialization (OTC). We are here and ready to help.
What’s in a name anyway?
A common and early misconception surrounding open source starts with the very term itself. All too often, OSS and OSL are used interchangeably – but incorrectly – to refer to any software made publicly or freely available under any terms. This is certainly not the case. In reality, OSS and OSL refer to software governed under a specific suite of approved license templates, certified by the Open Source Initiative (OSI), rather than a catch all term for shared software. In fact, freeware and public domain code are not considered open source. On top of this, open source, as its name implies, is relegated to just software matters. Public sharing of other copyrightable media (compilations of data, expressive writings, lists of instructions, user tutorials and manuals) must be dealt with by other tools, such as Creative Commons, since open source by definition was created with only software in mind and other forms of copyrighted works are largely outside its purview. To be technically accurate, a researcher, who claims to want to make their software available under “open source,” is really requesting that their software be licensed for distribution under one of the OSI-approved (and trademark branded) software license agreement templates.
Which license to choose? The devil is in the details
Now that we understand open source is a non-generic term of licensing options for making software broadly available, it is natural to ask which license is best for you. A second common misconception assumes open source licenses are all essentially equal. They are not. While they all subscribe in some part to OSI’s higher mission and are guided in principles by the Open Source Definition (OSD), they can and do vary widely in both form and function. From very open and permissive licenses, such as the BSD License and MIT License, to the very tightly regulated and more restrictive GNU GPL license, choosing the right OSL will affect how a researcher’s software is ultimately used, further added to, and subsequently redistributed by others downstream. The Digital Innovations Team at OTC is available to counsel the Duke community on questions regarding OSL selection.
Open Source works because of IP, not in lieu of it
A mistaken belief by some is that open source is antithetical to the intellectual property ecosphere when in fact the opposite is true. At its core, OSLs are copyright licenses. They rely on copyright law in order to work rather than subvert it. This is because copyright protection exists in software, extending to both source code and executable code. OSLs are simply copyright agreement contracts where all the terms and conditions are published and well understood by both parties in advance. In certain exceptional situations, a copyright may be insufficient and a patent may be needed to protect the functional aspects of an algorithm outside a specific reduction in a certain computer language. In those cases, special consideration is required since a patent by nature seeks to exclude others from making, using, and selling while open source encourages wholesale use, reuse, and distribution. Despite these orthogonal aims, patents and open source can co-exist and be leveraged for strategic means such as for raising awareness of a novel and innovative software tool within the research community while reserving commercial licensing rights for companies wanting to exploit the patented algorithm. Nowadays, many OSLs contain patent-specific clauses to address the overlap and mixing of patent and software IP. Any Duke researcher who needs help with a potential software patent and OSS issue should come talk to the Digital Innovations team at OTC.
How OTC can add value
The Digital Innovations team at OTC stands ready to help the Duke community with all of its open source questions. We add value by reviewing, identifying, and resolving any third party copyright issues before they can impact the release and distribution of your code. Third party code issues arise when your software contains, uses, builds on, embeds, or even just links to other copyrighted software from a third party. OTC will also ensure that any industrial sponsorship/corporate funded IP obligations attached to your Duke research will be addressed before the software should be publicly released.
Whether you want to publish code to Github, start a company around your software, or explore patent and software hybrid licensing options, we encourage you to first submit an invention disclosure to OTC to begin the process. OTC will then work with you to identify your short and long term goals and advise you on the best steps to get there. We look forward to working with you.
Daniel Dardani is Duke OTC’s new Director of Physical Sciences and Digital Innovations Licensing and Corporate Alliances. He can be contacted at daniel.dardani@duke.edu