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.

1. Free Software/Open Source
Licensing and Packaging
http://triplecheck.de
http://ubucon.de
A 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. Problems
http://www.gnu.org/licenses/license-list.html
42% of these 77% projects contain applicable license
terms that were not reported (http://zd.net/13Qrb5A)
Slide #4

5. Challenge
1.
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 work
To read more details: http://en.wikipedia.org/wiki/Provenance#Computers_and_law
Slide #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.org
Slide #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.com
Slide #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 licenses
Slide #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