The document discusses the importance of preparing source code for distribution with a focus on license compliance and the risks of using non-original code. It highlights the need for proper documentation, including copyright headers and third-party licenses, to avoid potential legal issues related to intellectual property. Tools and methods for ensuring code cleanliness and compliance, such as using .about and .spdx files, are also described.

1. Preparing your source code for distribu3on
www.triplecheck.net

2. About the presenter
Nuno Brito
l Former licensing coordinator, European Space Agency (contractor)
l Master of So?ware Engineering (Carnegie Mellon University, 2009)
l Volunteer at Free So?ware Founda3on, hHp://fsf.org/licensing/
team and Linux Founda3on, hHp://spdx.org
About TripleCheck
Tools for license compliance and plagiarism detec3on

3. The problem
Average software is built with >78% non-original code
- Copyleft and open source infringements
- Plagiarism by accident (or intentional)
- Intellectual property theft (contract breach)
Are you really sure your code is yours?
Google's chief Java architect:
“It's likely I copied Sun code found in Android, I'm sorry if I did”
Google vs Oracle court case, July 2016

4. Happens too easily

5. Happens too o?en

6. License compliance life-cycle
Zip file for end-
users
Your source
code
List 3rd party
components
Solve component
conflicts
Find non-original
code snippets
Solve non original code
snippets
Prepare zip file for
distribu3on
Collect 3rd party
code
Create
documenta3on

7. Keeping your so?ware clean?
Applicable licenses?
Intellectual Property?
Licensing quality?

8. Making sure your code is clean
Your source code
• Headers have your copyright and license?
• Are 3rd party code snippets iden3fied?
Third-party code
• Are the requirements for each license being followed?
DocumentaBon
• Are you describing how the system is compiled and installed?
• Is each 3rd party component listed and jus3fied?
• Is your list up to date?

9. Source code headers?
Depends on project. Default is short and readable.
Example
// Copyright (c) 2016 ACME Ltd.
// License: Apache-2.0
For heavy cases:

10. Using .ABOUT files
These are text files placed on the same folder where you have
each third-part library. Originally used by Android.
What it describes:
• Declared license
• Which files are the license applicable
• Details such as author and URL
How can it be created?
• Manually, using a sample and a text editor
• Automa3cally, hHp://triplecheck.net/components/

11. Using .SPDX files
A standardized way to list the files and respec3ve licenses
that are inside a package (e.g. Zip file), see hHp://spdx.org
What it describes:
• Declared license
• Which files are the license applicable
• Details such as author and URL
How can it be created?
• Automa3cally, hHp://triplecheck.net/download/

12. Standardiza3on
Without clarity, we can’t automate nor understand what is meant.
Specify without ambiguity the licenses and 3rd party so?ware you use.
Include version number
• Different versions may have different licenses
• Not adding a version forces end-users to inves3gate
Use standard license names, don't invent new ones
• Use the iden3fiers from hHp://spdx.org/licenses
• Make it easy for everyone to understand

13. Include with each project
LICENSE
• Full legal terms for declared licenses
README
• Describe the project and list licenses in readable text
AUTHOR
• Lists the authors and company that wrote the so?ware

14. Discovering authors in your code?
Some3mes it is not clear to list who exactly contributed code your
projects but this can also be automated.
From git, you can list the contributors with the following syntax:
git log --format='%aN <%aE>' | sort -f | uniq
source: hHps://github.com/rust-lang/rust/issues/5037

15. Is your code clean?
nuno.brito@triplecheck.net
twiHer: @nn81
@xkcd