1. Open Source & Open Development
Sander van der Waal
sander.vanderwaal@oucs.ox.ac.uk

2. Agenda
 OSS Watch
 Open Source & Open Development
 Case studies of successful open source projects
 Break
 Copyright, policy, licensing and governance
 Business models for open source
 Case studies for commercial success with open source

3. OSS Watch – What we do
 Advise on all things open source
 Services
 Consultancies, events, presentations
 Project support – community development
 Software sustainability beyond funding
 Core services free to HE / FE in the UK

4. Find out more!
osswatch.jiscinvolve.org
newsletter.oss-watch.ac.uk
www.oss-watch.ac.uk

5. What is Free and Open Source Software?
 Software that the user has the right to adapt and distribute
 Access to the source code
 Often available at minimal or no cost
 Often maintained and developed by a community
 Increasingly high public profile and market share (Linux, Apache
httpd, Firefox, OpenOffice.org, Android (mostly))
 Basis of later open licences like Creative Commons and Open
Database License

6. Some History
Until the late 1970s most software thought to have little intrinsic value
Exchange of software and its source code normal (with licences that allowed
adaptation and redistribution)
Arrival of personal computers in the mid 1970s changed the perception of
software's value
Software became productized, source code kept private
Many developers, particularly within academic communities, felt that this
was detrimental to software quality

7. “The amount of royalties we have received
from sales to hobbyists makes the time spent
[on] Altair BASIC worth less than $2 an hour.
Why is this? As the majority of hobbyists
must be aware, most of you steal your
software. Hardware must be paid for, but
software is something to share. Who cares if
the people who worked on it get paid?”
Bill Gates Computer Notes 1976

8. “I consider that the golden rule requires that if I like a program I must
share it with other people who like it. Software sellers want to divide the
users and conquer them, making each user agree not to share with
others. I refuse to break solidarity with other users in this way…
So that I can continue to use computers without dishonor, I have decided
to put together a sufficient body of free software so that I will be able to
get along without any software that is not free.”
Richard Stallman, GNU Manifesto, 1985

9. The FSF's Four Freedoms
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your
needs (freedom 1). Access to the source code is a precondition for
this.
The freedom to redistribute copies so you can help your neighbor
(freedom 2).
 The freedom to improve the program, and release your
improvements to the public, so that the whole community benefits
(freedom 3). Access to the source code is a precondition for this.

10. “Linux is subversive. Who would have thought even five years ago (1991) that
a world-class operating system could coalesce as if by magic out of part-time
hacking by several thousand developers scattered all over the planet,
connected only by the tenuous strands of the Internet?”
Eric Raymond, The Cathedral and the Bazaar, 1996-7

11. Open Source Initiative
 In early 1998 Netscape decides to release the source code of its struggling
web browser to the world
 Raymond's apolitical, business-friendly explanation of the virtues of the
Free Software ought to have an advocacy group
 In February 1998 the Open Source Initiative is founded, with Raymond as
its first president.
 The term 'Open Source' begins to be widely used.
The OSI adapts the Debian Free Software Guidelines to define what it
means by ‘Open Source’
 The resulting Open Source Definition gives ten criteria for an ‘open
source’ licence

12. Open Source Definition
Freely Redistributable
Source Code Included
Derived Works Permitted
Integrity of Author’s Source Code (diffs and patches)
No Discrimination Against Persons or Groups
No Discrimination Against Fields of Endeavour
Distribution of Licence (no additional licences required)
D
Licence Must Not Be Specific to a Product (or distribution)
Licence Must Not Restrict Other Software
Licence Must Be Technology-Neutral (no 'click wrap')
L

13. Open Source Initiative
 Over seventy licences are accredited by the OSI as meeting these criteria
The most commonly used are the BSD (permissive) and the GPL (copyleft)
T
The sheer number of OSI-approved licences is officially considered a
problem
For practical purposes OSS Watch defines its remit with reference to the
OSI approved licence list

14. Words and Tensions
Many ‘Free Software’ supporters, including Richard Stallman, see the OSI
as a deliberate attempt to appropriate their movement while stripping it of its
political aims.
The language itself has become politicised
Whether one says ‘Free’ or ‘Open’ has become an indicator of which ‘side’
one supports
 The unwieldy phrase ‘Free and Open Source Software’ is used by those
who do not wish to take sides
Stallman also campaigns against use of the phrase ‘intellectual property’

15. Open development is…
“Open source is a development method for software that
harnesses the power of distributed peer review and
transparency of process.” - http://www.opensource.org/
 A way for distributed team members to collaboratively develop a shared
resource

16. Open development is…
 Particularly useful in distributed self selecting teams
 Very common in open source projects
 Key attributes include:
 User engagement
 Transparency
 Collaboration
 Agility

17. Open development is agile…
 Many agile practices evolved from or alongside open development, e.g.
 Collective code ownership
 Incremental design and architecture
 Real customer involvement
 Revision Control

18. Open development is Not agile…
 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

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

20. Open Development is managed
 Progression through project roles
 User -> Contributor -> Committer -> Maintainer
 Governance
 How are decisions made?
 How are conflicts resolved?
 How do you gain influence?
 IPR management

21. Case studies of successful
open source /
open development

22. TexGen
• Textile CAD modeller
• Developed at Nottingham’s Department of Mechanical,
Materials and Manufacturing
• Generate geometric models of textiles and their
composites

23. Why open source TexGen?
• People can download TexGen and use it for free
• Better level of both knowledge transfer and verification
• Encourage third-party use / citation
• Potential for collaboration
• IPR issues are simplified

24. Why not commercialise traditionally?
• Limited commercial value
• Commercial customers would expect support
• Small market - casual use does not occur
• All development has to be undertaken in-house
• Danger of inhibiting research collaborations

25. Results
• Over 5,000 downloads on SourceForge
• Collaborations with previously unknown partners
• Renewal of EPSRC's prestigious Platform Grant in 2009
• Investment from commercial companies such as Boeing
• In total approximately £1m research income

26. Lessons learned
• High ROI to open source code
• Excellent marketing
• Free publicity of research group’s expertise
• Opportunity to create new partnerships
• There’s no one single way of doing it
• Best application of open innovation in software
• Funders love it

27. Apache Wookie (incubating)…
 Server for uploading and deploying widgets
 Implementation of emerging W3C standard
 Extracted from larger EU project context as a discrete project
 A good fit with Apache Software Foundation
 Already some interest from outside the project

28. Networking opportunities
• ASF community
• Other interested projects
• Mobile apps/widgets community
• Android community
• W3C Social Web XG

29. New Partnerships

30. Results
• Very substantial value added by community
• Income generated for next 3 years: ~£700k from two FP7
projects
• Only actually core funded from Dec 09-Sep10 @ 0.2FTE
(around £12k)
• Stepping stone to Apache Rave (Incubating)

31. Rave: ecosystem of projects

32. Legal aspects of open source

33. Copyright...
is a form of 'intellectual property'
 is an unregistered right – it comes into existence at the same time that the
work is 'fixed'
protects the 'fixed' form of an idea, not the idea itself
protects literary and artistic material, music, films, sound recordings and
broadcasts, including software and multimedia
generally does not protect works that are 'insubstantial' – thus names and
t
titles are not protected (although a 'passing off' action may be a possibility)
gives the author exclusive economic and moral rights over the copyrighted
material

34. What exclusive economic rights do copyright owners have?
Making copies
Issuing copies to the public (publication, performing, broadcasting,
online distribution)
Renting or lending copies
Adapting the work

35. What exclusive moral rights do copyright owners have?
In the case of software, none. Unlike other creators of literary works,
software authors have no statutory protection against derogatory
treatment of their code or automatic right to be identified as the author of
their code

36. When does copyright in software expire under UK law?
For literary works including software:
70 years after the death of the author
 Calculating copyright expiry is made more complex by the fact
that the duration has changed over the last 20 years. Luckily in
the case of software its novelty and relatively short shelf-life
mitigate this.

37. What can I do with my copyright material?
Sell it (assign it) – transfer ownership of your rights
License it – grant use of your rights, possibly for a limited
period or within a limited geographical area.

38. A word about patents
Not at all the same thing
Generally OSS licensing of code is incompatible with the
exploitation of software patents embodied in the code in
question
European Patent Convention 1973 Article 52:
“(1) European patents shall be granted for any inventions which are susceptible of industrial
application, which are new and which involve an inventive step.
(2) The following in particular shall not be regarded as inventions within the meaning of paragraph 1:
...
(c) schemes, rules and methods for performing mental acts, playing games or doing business, and
programs for computers;”

39. A word about patents
In fact, over the last 20 years this exclusion has been rendered
moot by repeated approval of patents by the EPO and national
patent-granting bodies which are, in effect, for software.
Symbian’s recent win in the High Court against the Intellectual
Property Office seems to indicate that software patents are now
obtainable in the UK
Despite this, there seems to be a general reluctance to litigate
in support of these patents in Europe.

40. How FOSS Licensing Works...
What is a FOSS Licence?
 A licence to exercise rights normally reserved to the
author by copyright law
 Consistent with Open Source Definition (or Four
Freedoms)
 Either explicitly perpetual or practically so
 A licence which offers a grant of rights to anyone

41. How FOSS Licensing Works...
How does copyright law protect FOSS software?
No explicit communicated acceptance necessary
Copyright law effectively prevents copying, adaptation and
distribution of copyright material without a licence
FOSS licences provide an avenue to licensed use if the user
abides by the conditions
Without the licence, it is likely no permission exists, and
the author can take action for copyright infringement
Generally considered to work, but little case law

42. How FOSS Licensing Works...
How do FOSS Licences deal with patents?
Some licences (Apache 2, Nokia, Microsoft Reciprocal
Licence and many others) explicitly grant rights to licensor's
patents that are necessarily infringed by use or distribution
Even those that do not will grant implied licences (in some
jurisdictions) by permitting acts that would require a patent
licence
Some licences terminate their patent grants if the licensee
initiates patent infringement litigation against the licensor

43. Varieties of FOSS Licence: Permissive
 Allow inclusion in non-FOSS software
 Suitable where widest uptake is desirable
 Examples of permissive licences are:
 Modified BSD
 MIT
 Academic Free
 Apache Software Licence

44. Varieties of FOSS Licence: Copyleft
 Derivative works, if distributed, must use same licence
 Cannot be incorporated into non-FOSS products
 Suitable when desire is to legally enforce FOSS status
 Examples of copyleft licences:
 GNU General Public License
 Open Software License
 Common Development and Distribution License

45. Partial Copyleft
 Derivative works, if distributed, use same licence
May be incorporated into non-FOSS products
Suitable in order to keep a portion of the work FOSS
 compromise between full copyleft and permissive
Examples of weak or partial copyleft licences:
 GNU Lesser General Public License
 Mozilla Public License
 Eclipse Public License

46. Varieties of FOSS Licence: Badgeware
 Only one 'badgeware' OSI-approved licence
 Common Public Attribution License
 Adaptation of Mozilla Public License (partial copyleft)
 Derivative must prominently display original author's
details or organisation at runtime.

47. How to choose a licence?
Only considering popular licences?
Copyleft vs. Permissive?
How to deal with patents?
Jurisdiction?

49. Copyright Ownership Models
• Centralised ownership
• Copyright is owned by the project owner
• Contributors assign copyright to project owner
• Project owner releases under chosen FOSS licence
• Aggregated ownership
• Copyright owned by original authors
• Contributors license their code to project owner
• Project owner releases under chosen FOSS licence

50. Copyright Ownership Models
A Flawed Copyright Ownership model
•Distributed ownership
•Contributions individually licenced as FOSS
•Common in the academic world
•Collaboration Agreements
Don't use this model
•Legal action against infringers hard to coordinate
•Legal action against project requires coordination from
defendants
•Outbound licence changes require agreement from all

51. Contributor Agreements and Governance
• Contributor Licence Agreements (CLA) required
• Solve problems of distributed ownership
• Can be a barrier to contribution so keep them simple
• Well-run projects need a clear contribution policy
• what agreement is needed?
• who can commit?
• who decides what code is included in the release?
• And more..
• info@oss-watch.ac.uk

52. Employees, Academics and Contractors
• Who owns “internal” contributions?
• Employment contracts
• IP Policies
• Consultancy contracts
• Default position is that:
• Employers own employees work
• Contractors own their own work
• Academics often own their copyrighted work
• See contract and policies

53. An example policy: Oxford
• Release form from Research Services
• Straight-forward assessment of components written and used
• Sent to legal team
• Also sent to our technology transfer unit ISIS Innovation
• Departmental policy for Oxford University Computing
Services
• Staff members may contribute code to foundations
• Central registry of projects contributed to
• Contributor Licence Agreements may be signed if needed
• Example: Apache Software Foundation

54. Making sure your code is releasable
 Strongly consider obtaining contributor licence agreements
 Keep track of your inbound licences and what they oblige you to
d
do (licence compatibility)
 Keep track of the employment/consultancy agreements of
contributors, including all institutional regulations that they
import
 Keep track of funding conditions associated with contributors
 Use versioning system as a basis for this record-keeping
 Establish what (if any) patents might be obtainable in relation to
the work, and plan your code accordingly
 Assess your competition and your risk

55. Business models around open source

56. Business and Sustainability Models
 These are mostly not mutually exclusive, and will most often be used in
combination as appropriate – more accurately they are elements of business
models
 This is still an emerging area of business practice
 Some of the current success of FOSS software exploitation techniques
may be attributable to dissatisfaction with more traditional proprietary
techniques and their associated big-name vendors, rather than any innate
superiority
 It remains to be seen whether the current global financial difficulties will
help FOSS business or hinder it. Analysts are currently predicting both.

57. First - what you cannot / should not do
 Charge for licences for specific uses of your code, for example commercial
use (Open Source Definition point 6)
 Charge for licences in general (Possible but subject to low/zero-cost
competition from all recipients)
 Tweak an existing FOSS licence for your purposes and still call your
software Free Software or Open Source Software (Strong community
rejection of these practices)
 Silently incorporate FOSS software in your proprietary offering without
abiding by the licence conditions (detection is likely, and although legal
damages are unlikely, damage to reputation is certain)

58. Academic Community Development
 FOSS licensing permits a varied group of contributors to work on software
that addresses a particular problem domain.
 Institutions and their academics can gain public profile by contributing to
such projects and becoming associated with respected tools in specific areas
of research. It can also help ensure the continued existence of useful
solutions.
 Examples include BioImage Suite (biological image analysis software)
YARP (experimental robotics software) and The Versioning Machine
(software for aligning differing versions of xml-encoded texts).
 Recognition for work on academic tools is still, however, some way behind
more traditional forms of academic recognition for publication etc

59. Establishing a separate legal entity
 Adds to sustainability by isolating risks (IP infringement, event organisation,
damages from failure) from the parent institution
 Facilitates donation of money and simplifies tax issues
 Most research institutions are already well-practised in setting up spin-out
companies. In the case of sustaining FOSS projects some kind of not-for-
profit entity may be just as or even more appropriate
 Such an entity can still have an affiliated commercial entity engaged in
exploiting the software and the brands that it stewards

60. Moving into an external foundation
 The benefits of foundation status have led to the establishment of umbrella
foundations holding multiple FOSS projects.
 Examples include the Apache Software Foundation, which supports
Apache HTTP Server, Cocoon, Lucene, Software in the Public Interest,
which supports the Debian Linux distribution and PostgreSQL, and the
Software Freedom Conservancy, home to Samba, Busybox and Wine
 Entering an umbrella foundation can radically reduce running costs for
projects that receive financial donations, as the foundation will handle the
necessary book-keeping, as well as providing the risk management benefits
that come with separating legal responsibility for a project from your host
institution

61. 'Community Source' Foundations
 Where a number of separate institutions see a benefit in jointly developing
a piece of FOSS, they can adopt a model which has come to be known,
somewhat confusingly, as 'Community Source'
 Each institution contributes resources to developing the code, the
ownership of which rests in an external foundation
 In the initial phases the code may be unavailable outside the foundation,
although it will eventually be released under a FOSS licence
 Contributing resources to the foundation buys institutions early code
access and influence on the governance of the project and its functionality
 Mellon-funded projects Sakai and Kuali both began using this model

62. Consultancy
 Consultancy is another traditional technique for educational institutions
looking to financially exploit their resources
 A more traditional model might be to sell licences to a piece of research-
derived software and sell consultancy services and/or bespoke development
services alongside it
 Potentially a FOSS release of the software can improve uptake, given its
low cost of acquisition, and drive the market for associated consultancy and
development services more successfully than the traditional model

63. Internal Cost Reduction
 Institutions may be happy to sustain an internally-developed FOSS project
themselves if the project can demonstrate that it drives down the running
costs of that institution or solves an institutional problem
 Projects that reduce costs in one institution may have good potential, when
mature, to be deployed in others. This provides opportunities for paid
consultancy and/or provision of the software as a service (see below)

64. Provision of Paid Support /
Documentation
 Just because your code is freely available, it does not mean that the
documentation or your help needs to be (as with the consultancy and
bespoke development model)
 Support can be provided in time- or incident-limited bundles
 Support can be in the form of guaranteed performance on specific
hardware
 Documentation can take the form of paid access to a knowledge base of
previously resolved issues
 HOWEVER, in this case one is in competition with the software's user
base/community, who may be willing to provide peer support for free

65. Integration / Managed Upgrades
 Managing the integration of various FOSS technologies, with their varying
dependencies and release cycles, is a service that people are prepared to
pay for
 Similarly managing the deployment of upgrade patches can be a paid
service
 Bundles of tested, integrated FOSS software can be sold along with,
potentially, support agreements
 HOWEVER, close integration may trigger responsibilities in particularly
copyleft licences that could prevent integrated distribution – read the licences

66. Competitor Disruption
 Sometimes a FOSS alternative to a competitor's product can disrupt their
business model and provide competitive advantage (although this is almost
never the sole motivation behind the release or distribution)
 Examples (arguably) include Sun's OpenOffice.org, Google's bundling and
distribution of Microsoft-competing software such as OpenOffice.org, Firefox
and Chrome (the 'Google Pack'), Netscape Corporation's FOSS release of
Netscape Navigator

67. Software as a Service
 Increasingly consumers are becoming comfortable with so-called 'cloud'-
based software offerings – software that is accessed and used over the
internet, and which stores data remotely from the user
 SaaS can be a useful solution to the problem of institutionally developed
software that relies integrally on copyleft-licensed code
 Provision of service using copyleft software does not count as distribution,
and thus does not trigger copyleft's reciprocal licensing responsibilities
 HOWEVER – this is a known 'bug' in copyleft licensing, and licences such
as the GNU Affero GPL v3 are already in existence to 'fix' it.

68. Advertising / Referral
 Your software or accompanying web site may be able to direct network
traffic to an entity that is willing to pay for hits (although of course this
functionality can always be engineered out by technically apt users)
 This is Mozilla Foundation's main source of income
 Firefox's built-in search box directs queries to Google
 The vast majority of Mozilla Foundation's revenue ($132m in 2010)
comes from Google under this deal.
 Wordpress, the FOSS blogging software and hosting platform is partly
funding their parent company Automattic through this model

69. Training and Accreditation
 As well as support and consultancy, generalised training documents,
courses and qualifications may be viable products
 Control of an associated trademark enables the provision of 'X-Certified
Professional' style programmes
 Actual training and examination are readily out-sourced

70. Trademark Licensing / Merchandising
 Just because your code is available under a FOSS licence, you do not
have to permit universal use of your project's name and associated symbols
 Unlike copyright, trademarks are a registered form of IP, meaning that you
have to apply to relevant government agencies for ownership. However,
compared to patent application, trademark registration is relatively
inexpensive
 Owning your trademark facilitates the sale of associated merchandise and
accreditation and marks like “Powered by X” and “Using X technology”
 Can be a deterrent to forking if the brand is strong enough – the motivation
to increase personal reputation by providing functionality outside project “X” is
partially undermined by the inability to call the new project “Improved X”

71. Proprietary Versions and Components
 Sometimes referred to disparagingly as the 'Bait and Switch' model
 A FOSS edition of software is offered which lacks some of the functionality
of a paid edition, either throughout its code or in the form of missing
proprietary components
 While the existence of better-supported or hardware-accredited forms of
FOSS offerings is generally accepted by the FOSS community, proprietary
components and versions are less well-liked (although there is perhaps
growing acceptance as the community matures)
 HOWEVER, this is another example of competing with the community. The
FOSS model means that anyone can produce freely available versions of
your paid functionality, given enough time and expertise

72. Dual Licensing
 Provided that you have the necessary ownership or sub-licensing rights
over your project's code, you can provide it under differing licences
 In the classic case, these would be a copyleft licence and a paid
proprietary licence
 Customers who wish to build software product incorporating your code and
who do not wish to use the copyleft licence must pay for the proprietary
licence
 This is therefore most suitable for code which is readily susceptible to
inclusion within commercial software products, for example database
backends

73. Case studies

74. Example: Cranfield University
 Library developed a survey tool based on Plone
 Released as open source in 2006
 Development has occurred internationally
 Africa, North America, India and Europe
 Eg. a major contribution from a South African company
 Cranfield recognised within Plone community
 Get development effort back
 Ability to provide consultancy services

75. Moodle at ULCC
-
A Shared Service
Success
www.ulcc.ac.uk

76. Facts & Figures
www.ulcc.ac.uk

77. # of Moodle / Mahara Instances
www.ulcc.ac.uk

78. # of Moodle / Mahara customers &
instances 2011
www.ulcc.ac.uk

79. # Registered Moodle users
www.ulcc.ac.uk

80. Moodle Activity*
*Moodle activity is defined as any form of accessing, uploading and editing content by a registers ULCC Moodle user
www.ulcc.ac.uk

81. Average Activity (Activity per
user)
*Moodle activity is defined as any form of accessing, uploading and editing content by a registers ULCC Moodle user
www.ulcc.ac.uk

82. ULCC’s Personalised Learning
Framework
www.ulcc.ac.uk

83. Personlised Learning Framework
Assessmen
t
Portfolio VLE
PLP
Portal
www.ulcc.ac.uk

84. ULCC’s e-Learning portfolio
www.ulcc.ac.uk

85. ULCC’s e-Learning portfolio
www.ulcc.ac.uk

86. The wider ecosystem
www.ulcc.ac.uk

87. ULCC’s e-Learning Service
• Hosting Levels (1-7) and support that fit your requirements
• PRINCE2 project management support for transition of VLE
• 24/7 customer support
• Integration with your existing IT systems (SITS, Agresso, Talis, etc.)
• Individual and bespoke staff training to maximise VLE usage
• Pro-active management of software upgrades
• Active customer community to share best practice and experience
www.ulcc.ac.uk

88. Our Customers
www.ulcc.ac.uk

89. Partners/ Affiliates
www.ulcc.ac.uk

90. ULCC’s successful open source strategy
 Share code and expertise with Moodle community
 Build reputation in Moodle development
 Successful service model
 Now recognised team
 Hosted MoodleMoot 2010 and 2011

91. Do get in touch:
info@oss-watch.ac.uk
http://www.oss-watch.ac.uk
@osswatch