This document discusses open source software and free and open source licenses. It defines open source software as software made available under an OSI-approved license that allows users to freely adapt and distribute the software. It describes the main types of licenses as permissive versus copyleft and strong versus weak copyleft. It also provides examples of specific popular licenses and their characteristics. Finally, it discusses best practices for evaluating open source projects and licenses.

1. Introduction to Free and Open
Source Software
Sander van der Waal 14/3/2012

2. Agenda

Introduction

FOSS Licenses

Evaluating FOSS

3. What is OSS Watch?

Funded by Joint Information Systems Committee

4. What is OSS Watch?

Funded by Joint Information Systems Committee

We advise UK Higher Education and Further Education sector

5. What is OSS Watch?

Funded by Joint Information Systems Committee

We advise UK Higher Education and Further Education sector

We advise on the use and creation of free and open source software

6. What is OSS Watch?

Funded by Joint Information Systems Committee

We advise UK Higher Education and Further Education sector

We advise on the use and creation of free and open source software

We provide education, consultancy and training

7. What is OSS Watch?

Funded by Joint Information Systems Committee

We advise UK Higher Education and Further Education sector

We advise on the use and creation of free and open source software

We provide education, consultancy and training

We are non-advocacy

8. Who are these people?

(a) Eric Raymond and Richard Stallman

(b) Bill Gates and Eric Raymond

(c) Richard Stallman and Eric Raymond

(d) Bill Gates and Richard Stallman

9. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

10. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

11. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

Adaptation by giving users access to the software's source code

12. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

Adaptation by giving users access to the software's source code

These rights are transmitted via licensing

13. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

Adaptation by giving users access to the software's source code

These rights are transmitted via licensing

It is often available at minimal or no cost

14. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

Adaptation by giving users access to the software's source code

These rights are transmitted via licensing

It is often available at minimal or no cost

It is often maintained and developed by a community of interested parties
who may or may not be salaried for their work

15. What is (F)OSS?

(For OSS Watch) Software made available under an OSI-approved licence

Software that we have the rights to freely adapt and distribute

Adaptation by giving users access to the software's source code

These rights are transmitted via licensing

It is often available at minimal or no cost

It is often maintained and developed by a community of interested parties
who may or may not be salaried for their work

Some ethical and political differences in community

16. How does this work?

Releasing code developed in an institution will require sign-off

17. How does this work?

Releasing code developed in an institution will require sign-off

Consider the licensing of code you are reusing

18. How does this work?

Releasing code developed in an institution will require sign-off

Consider the licensing of code you are reusing

The following categories are broadly defined

19. How does this work?

Releasing code developed in an institution will require sign-off

Consider the licensing of code you are reusing

The following categories are broadly defined

Always read and understand your chosen licence!

20. Staying mainstream

The Open Source Initiative's list of 'Licenses that are popular and widely
used or with strong communities'

21. Staying mainstream

The Open Source Initiative's list of 'Licenses that are popular and widely
used or with strong communities'

Increasing the chances that your conditions will be understood

22. Staying mainstream

The Open Source Initiative's list of 'Licenses that are popular and widely
used or with strong communities'

Increasing the chances that your conditions will be understood

Apache License 2

BSD (2 and 3 clause versions)

GNU GPL (v2 and v3)

GNU LGPL (v2.1 and v3)

MIT License

Mozilla Public License 2.0

Common Development and Distribution License

Eclipse Public License

23. Don’t adapt the licence text
http://java.dzone.com/articles/jsonorg-license-literally-says

24. Permissive and copyleft

The main axis of variation between FOSS licences

25. Permissive and copyleft

The main axis of variation between FOSS licences

A distinction based on what happens to modified code

26. Permissive and copyleft

The main axis of variation between FOSS licences

A distinction based on what happens to modified code

Permissive licences seek to make conditions about just the code they
cover

27. Permissive and copyleft

The main axis of variation between FOSS licences

A distinction based on what happens to modified code

Permissive licences seek to make conditions about just the code they
cover

Copyleft licences also seek to make conditions about some or all works
based on the code they cover (modified version, larger works, derivative
works etc)

28. Permissive and copyleft

The main axis of variation between FOSS licences

A distinction based on what happens to modified code

Permissive licences seek to make conditions about just the code they
cover

Copyleft licences also seek to make conditions about some or all works
based on the code they cover (modified version, larger works, derivative
works etc)

Permissive licences allow reuse in closed source software

29. Strong and weak copyleft

Copyleft is further subdivided

30. Strong and weak copyleft

Copyleft is further subdivided

'Strong' copyleft licences impose no artificial limitations on which modified
works they seek to control

31. Strong and weak copyleft

Copyleft is further subdivided

'Strong' copyleft licences impose no artificial limitations on which modified
works they seek to control

'Weak' copyleft licences do, at various levels – file, library, module

32. Strong and weak copyleft

Copyleft is further subdivided

'Strong' copyleft licences impose no artificial limitations on which modified
works they seek to control

'Weak' copyleft licences do, at various levels – file, library, module

'Weak' copyleft attempts to strike a balance between the extremes of
permissive and strong copyleft, but in doing so introduces some additional
complexity

33. Permissive<->Copyleft

Apache License 2 - Permissive

BSD (2 and 3 clause versions) - Permissive

GNU GPL (v2 and v3) – Strong copyleft

GNU LGPL (v2.1 and v3) – Weak copyleft (library level)

MIT License - Permissive

Mozilla Public License 2.0 – Weak copyleft (file level)

Common Development and Distribution License – Weak copyleft (file
level)

Eclipse Public License – Weak copyleft (module level)

34. Permissive and copyleft

The main axis of variation between FOSS licences

A distinction based on what happens to modified code

Permissive licences seek to make conditions about just the code they
cover

Copyleft licences also seek to make conditions about some or all works
based on the code they cover (modified version, larger works, derivative
works etc)

Permissive licences allow reuse in closed source software

35. Strong and weak copyleft

Copyleft is further subdivided

'Strong' copyleft licences impose no artificial limitations on which modified
works they seek to control

'Weak' copyleft licences do, at various levels – file, library, module

'Weak' copyleft attempts to strike a balance between the extremes of
permissive and strong copyleft, but in doing so introduces some additional
complexity

36. Permissive<->Copyleft

Apache License 2 - Permissive

BSD (2 and 3 clause versions) - Permissive

GNU GPL (v2 and v3) – Strong copyleft

GNU LGPL (v2.1 and v3) – Weak copyleft (library level)

MIT License - Permissive

Mozilla Public License 2.0 – Weak copyleft (file level)

Common Development and Distribution License – Weak copyleft (file
level)

Eclipse Public License – Weak copyleft (module level)

37. Other distinctions

Patent retaliation clauses

38. Other distinctions

Patent retaliation clauses

Choice of jurisdiction

39. Other distinctions

Patent retaliation clauses

Choice of jurisdiction

Enhanced requirement to attribute (badges)

40. Other distinctions

Patent retaliation clauses

Choice of jurisdiction

Enhanced requirement to attribute (badges)

Network code copyleft (aka the privacy problem)

41. Other distinctions

Patent retaliation clauses

Choice of jurisdiction

Enhanced requirement to attribute (badges)

Network code copyleft (aka the privacy problem)

Specifying no promotion

43. How to choose a licence?

Consider options discussed

Use the licence differentiator tool http://oss.ly/licdif

Contact OSS Watch info@oss-watch.ac.uk

44. More than a licence..
“Open source is a development method for software that
harnesses the power of distributed peer review and
transparency of process.”
http://www.opensource.org

45. Open Development

Key attributes include:

User engagement

Transparency

Collaboration

Agility

46. Agility in Open Development

Many agile practices evolved from or alongside open development, e.g.

Collective code ownership

Incremental design and architecture

Real customer involvement

Revision Control

47. Agility in Open Development

Some Agile methods are not appropriate

e.g. Does not require co-location

Does allow anyone to participate

NOTE: this does not mean that anyone has the right to modify open source
code in the core repository

48. Platform for collaboration

Common tools used in open projects:

Mailing Lists / Forums for communication

Website / blog / wiki

Issue tracker

Version Control System (GIT, SVN, Mercurial)

Community development

49. The User’s Perspective

Overwhelming amount of projects available

More than 300,000 on SourceForge alone

How to tell if you should use it?

Will it be around 3 years from now?

Can I contribute?

Will development continue?

All to do with sustainability of software project

50. Evaluating open source projects

Informal techniques

Capability Maturity Model

Reuse Readiness Rating

QSOS (Qualification and Selection of Open Source software)

Openness Rating

Software Sustainability Maturity Model

51. Openness Rating

Assess projects along five axis:

Legal

Data Format and Standards

Knowledge

Governance

Market

Helps you consider issues relevant to you and your use case

52. Legal

Licence recognised as Free and Open Source?

Project dependencies documented?

Patent licence granted?

Who can view / adapt / redistribute the code?

53. Data Formats and Standards

Does the project rely on closed proprietary standards?

Is there a costs associated with any standards used?

Are standards approved by a recognised standards body?

W3C, IEEE, IETF, OASIS, or ISO

Is a standard project management process used

XP, SCRUMM, PRINCE 2?

Is unicode support through encoding like UTF-8?

54. Knowledge

Which publicly available communication mechanisms are used?

Are project decisions made in a non-public environment?

Who is able to access all (non-private) project knowledge?

Are there any financial barriers?

Are there technological barriers?

Who can contribute to project knowledge?

55. Governance

Is there a clear leadership in the project?

Are the structure and policies of the project clearly and publicly documented?

Are contributors required to sign a document stating they have the necessary
permissions to make their contributions?

Is the software release cycle predictable and consistent?

Is there an avenue and structure for recourse beyond the project maintainers?

56. Market

Are there any costs or barriers to setting up a business around the project?

What proportion of the core developers are from the one company, institution or
department?

How many contributors have some or all of the time they spend on the software
paid for?

Is the project applicable to more than one industry?

Which revenue models are available to a new business looking to build a revenue
stream around the project?

57. Openness Rating results
 Are there any costs or barriers to setting up a business around the project?

58. Software Sustainability Maturity Model
Combining different techniques:


Openness rating

Reuse Readiness Levels

Capability Maturity Model

Still under development – feedback welcomed!

Read more at http://oss.ly/ssmm

59. Summary

Open Source is much more than a licence; it’s a methodology

There are many FOSS licenses, but focus on those that are OSI-approved

Many techniques available for evaluating open source projects

Important areas to consider for selecting open source:

Legal, Open Data and Standards, Knowledge, Governance, and Market

Interested in applying the Openness Rating?

Contact OSS Watch at info@oss-watch.ac.uk

Learn more at http://www.oss-watch.ac.uk