Ubucon 2013, licensing and packaging OSS

download Ubucon 2013, licensing and packaging OSS

If you can't read please download the document

description

As developers of open source and free software, we share our code freely with the world. It feels great. The problem is when someone points out that the code can't be used for some odd reason. Either because of missing license information or because the reported licenses are incompatible. If you're writing code then you shouldn't miss this talk. We'll be showing which licenses you should avoid mixing (for e.g Apache v2 inside GPL v2) and other tips to avoid a licensing headache. In the end we'll talk about the SPDX format introduced by the Linux Foundation and show practical examples.

Transcript of Ubucon 2013, licensing and packaging OSS

  • 1. Free Software/Open Source Licensing and Packaginghttp://triplecheck.dehttp://ubucon.deA presentation by Nuno Brito

2. Clarification When referring to Free Software, I mean software specifically under the licensing terms created by the Free Software Foundation such as GPL When referring Open Source, I am referring to any software where the source code is generically available to the public despite its licensing conditions. The term Open Source might include code licensed as Free Software but can also refer to code under any other licensing terms and conditions.Slide #2 3. Introduction If you look with some detail to the libraries of new software released on the market nowadays, around 90% of its libraries will likely be licensed under free and/or open source. These are good news. It means that people around the globe are collaborating together. This cooperative work is reusable by others in mass scale and will be available for the benefit of future generations. TripleCheck works to make this future possible.Slide #3 4. Problemshttp://www.gnu.org/licenses/license-list.html42% of these 77% projects contain applicable license terms that were not reported (http://zd.net/13Qrb5A) Slide #4 5. Challenge1.What licenses are applicable and compatible?2.Who decides them?3.How can these license terms be followed correctly? (compliance)Slide #5 6. Provenance? Software provenance is the act of reporting the origin and applicable licensing terms for a software artifact Provenance is needed to answer: which licenses are applicable? Easier task when software developers document which code snippets or libraries from other people were used in their workTo read more details: http://en.wikipedia.org/wiki/Provenance#Computers_and_lawSlide #6 7. IPR holder? When you write software, you become the IPR (Intellectual Property Rights) holder IPR holders are (typically) entitled to choose the license terms applicable to their work Exceptions to a free choice of license can apply: signing an contract where you waive this right (contributor agreements) third-party software restricting the choice of licenses (for e.g. GPL) Slide #7 8. Compatible? Some open source licenses are not compatible between themselves. For example, writing software under GPL version 2 restricts using code under Apache version 2 Where to find information about compatibility? http://www.tldrlegal.com/ http://choosealicense.com/ When in doubt, you're also welcome to ask us! :-)Slide #8 9. Compliance Knowing what you are using and documenting the items is already a good step. Proper software packaging is an even better step to help developers use your work and preserve your author rights Extra attention to Free Software licensing. Requirements include the need to document the build environment and make available the full source code, including config files Standards such as SPDX help to exchange information about which licenses are applicable to which files, more info at http://spdx.orgSlide #9 10. SPDX Development at the Linux Foundation since 2010 Possible formats RDF/XML Tag/Value Official tools and info at http://spdx.org Online tool at http://spdx.windriver.comSlide #10 11. Investigate Google Helps to find source code files. Pick on comments that are not common and use between the search terms to find exact matches. For e.g. @author Nuno Strangely obvious, abc license might help :-) Archive.org When a site is offline or changes, http://archive.org is a good resource to find the old pages Tools A good text editor like Notepad++ or Gedit Professional tools like Palamida for deep analysis of code against a database Slide #11 12. Investigate Authors When in doubt, might help to contact directly the authors to clarify the licensing details Logs, logs, logs.. Don't forget to write down the steps of your investigation and how the conclusions were reached Keep it simple, a plain text file helps Justification List the COTS used in your software Extra points if you explain how they are used within your software and mention their applicable licensesSlide #12 13. Packaging Header of source code files Applicable license Date of creation and author details Compressed files Include version number on zipped file name Be consistent on version releases Extra points if you keep available the old versions Long term storage Use durable storage services. For e.g. Sourceforge Providers such as GitHub can delete your account or projects when inactive for some years.Slide #13 14. Distribution Web site Detail applicable licenses, preferable on separate page available from the home page If licensing is fuzzy, add a FAQ detailing what is understood as permitted (or not) Extra points for short URL like http://abc.net/license Releases Include version number on zipped file name Be consistent on each version Extra points if you keep available the old versions Need help with this part? We volunteer to give feedback on your distribution Slide #14 15. Questions?Images from http://xkcd.com/225/ and http://blog.xkcd.com/2007/04/19/life-imitatesxkcd-part-ii-richard-stallman/Hey, you find more things to read at http://triplecheck.de :-)Slide #15