Don't laugh. Just this week someone asked a discussion list what license he should use for his project, and he got lots of "legal" advice. Someone asked me my opinion. I said my opinion is he should ask a lawyer. Some things are just obvious.
Brendan also explains things like the difference between a license and a contract, the difference in risk assessement when a company decides to use open as opposed to closed software. Nowadays, most companies do use some Open Source code, even if they don't always know it, and he addresses that issue too -- how to get the cooperation of your engineers. Obviously, if you license software that you are forbidden to ever redistribute, you won't be looking at risks regarding distribution with the same eyes as you would if you plan to modify some code and redistribute it. On the other hand, you don't have to keep track of license acquisition and compliance the way you would with closed source software. There are risks for a company no matter which kind of code it uses, business being business, and it's prudent to know the risks clearly. So he explains all that and touches on dual licensing as well. Often folks don't realize that if they want to use GPL code, and they don't want to release their own code that way, they can approach the author and negotiate specific license terms just for that. It doesn't hurt to ask. He also explains, in that context, how dual licensing works.
And then he discusses strong and weak licenses and compatibility issues that come up when you wish to use code under two different licenses, and he provides some case studies from his own practice at Open Source Law, which will give you an idea of the kinds of problems lawyers in this area get hired to fix. Brendan has been at this for over a decade, according to his bio on LinuxWorld's speakers' page, which says Open Source Law specializes "in information technology and intellectual property law, with a special focus on open source and related technologies. Brendan has over 10 years of experience acting for a range of clients, both vendors and customers. Brendan is a director and founding member of Open Source Industry Australia Limited, a past president of the NSW Society for Computers and the Law, and a member of the editorial panel of the Internet Law Bulletin. He is recognised as a leading expert on the legal and business implications of open source."
Principles – Motivations of Copyright Law
is a legislative monopoly, created (in Australia) by the Copyright
Act 1968 (Cth). The purpose of the Copyright Act is to
provide an incentive for the creation and distribution of works1
the subject of copyright. It does this by granting monopoly rights
to perform certain acts (such as reproduction), thereby permitting
the vendor of a work to sell that work above the marginal cost of
production of that work.
such, copyright is a form of industry development scheme or
Government subsidy aimed at promoting a particular end (ie the
production and distribution of works). In 1984 this subsidy, which
traditionally covered books and music, was extended to also cover
software. Prior to 1984 it was legal to make electronic
reproductions of software.2
operates by prohibiting numerous categories of action in respect of
a copyright work. These prohibitions are, subject to some
exceptions, absolute prohibitions and are independent of the means
by which a person acquired possession of a work in respect of which
the actions are carried out. In the absence of a permission from
the copyright holder, there is an absolute prohibition on
exercising any of the rights comprised in copyright in respect of
example, if a person buys both a screwdriver and some software from
someone, they may do what they like with the screwdriver, including
modifying it, improving it, renting it to others etc. However, the
scope of actions that they can undertake with the software is
strictly limited (subject to some qualifications3)
to those things over which they have been granted permission from
(ie licensed by) the holder of copyright in the software. This
typically does not extend to modification, improvements, renting
etc. Often this permission (ie the licence terms) only applies to
the execution of the software in restrictive circumstances (such as
tied to particular hardware, or particular classes of hardware, a
limit on concurrent users etc).
consequences of copyright infringement are broad and include a
requirement to pay damages or an account of profits, and there may
be criminal penalties attached to an infringement. An infringement
can also result in the seizure of equipment used in the course of
carrying out the infringement.
Principles – Comments on Contract v Licence
is a great deal of confusion in the area of open source licensing
arising from a fundamental misunderstanding of the different roles
of contracts and licences. It is all too common to see these
concepts identified in the context of open source. A contract is
“a legally binding promise or agreement,”4
while a licence is a permission to do something. In the context of
software licensing, a licence is a permission to do something which
would otherwise be prohibited by copyright law (such as the
reproduction of the software). A contract may include a licence,
and a licence may form part of a contract. However, one does not
imply the other.
example, it is a trespass to enter onto someone's land without
their permission. That said, people enter onto other's land all
the time without those entries being trespasses – when you
receive visitors, or when you walk into a shop are examples. This
is because the owner or lessee of the land has either expressly
(such as inviting someone) or by implication (shopkeepers)
permitted them to come onto the land. If there was a big sign out
the front of land5
which states that anyone wearing a red hat can enter onto the land
then, as a consequence, anyone wearing a red hat could enter the
land without committing a trespass. If they do not comply with the
conditions of the licence (by not wearing a hat, or wearing a blue
hat), then they will commit a trespass if they enter the land
because they have not met the preconditions to be entitled to the
permission. In none of these circumstances is there a need for the
exchange of promises (which traditionally characterises a contract)
to occur with the entrant.
same principles underly open source licensing. As mentioned above,
the Copyright Act 1968 (Cth) absolutely prohibits certain
activities including the reproduction of software. Open source
licences effectively exempt the permitted activities from copyright
infringement, subject to compliance with certain conditions (which
are different depending upon the licence). A failure to comply
with the conditions in the licence will mean that the activities
are no longer exempted from infringement of copyright. If the
activity in question results in an infringement of copyright, then
the copyright owner will have an action against the person engaging
in the activity.
Model Licensing (Closed Source)
old model of the exploitation of copyright for software involved
granting licences in respect of the software in such a way as to
prevent effective ownership of the software by buyers. The example
given in paragraph 1.4 above demonstrates this in that, even though
the purchaser buys both items, there are substantial restrictions
on the use of the software, with no analogous restrictions on the
use of the screwdriver. It is this lack of ownership rights under
the old model which is used by vendors of works to secure an above
the old model of copyright exploitation has worked to establish or
entrench market power in those sectors of the economy where it
operates. That entrenchment appears to occur through the control
of distribution channels. Not only does this practice raise the
price of software to the end user, it also creates substantial
costs for new entrants seeking access to those channels, thereby
reducing competition, with a compound effect on price. Further,
the non-purchase costs of the old model (ie closed source) are
comparatively high and introduce non-trivial transaction costs into
every transaction in respect of the copyright work. These costs
include the costs involved in finding and negotiating a licence and
the costs of administering the licence to ensure that activities
remain within the bounds prescribed by the licence terms.
transaction costs have the effect of excluding from a work a
spectrum of possible improvements (that is, those for which the
benefits are less than the transaction costs involved in inclusion)
and of preventing the maximal exploitation of the work (again, if
the licence fees plus the transaction costs involved in acquiring
and administering the exploitation of the work exceed the benefit
from doing so, then the work will not be acquired).
Source as a New Model
source licensing is a customer driven market reaction to the high
transaction costs and anti-competitive effects that the old model
has produced. It effectively says that, through judicious use of
copyright, customers can acquire software with rights analogous to
ownership. In the example above, if the software is open source
software, the person acquiring the software would have
property-like rights over the use of the software in a manner
analogous to the rights they have over the screwdriver.
fundamental difference therefore between the old, closed source,
model and the new, open source, model is that under a closed source
licence, a customer acquires very restricted rights in relation to
the software, whereas under an open source licence, a customer
acquires very broad rights analogous to ownership of the copy they
way of looking at this is that open source licensing attempts to
treat software as a form of property, while the old model of
licensing attempts to prevent such treatment. That is, open source
is a form of deregulation of the software industry. Open source
uses copyright to effect that deregulation.
Open Source Misconceptions
Open Source is Pro-Copyright
open source licence is a licence over copyright granted by the
copyright owner of a work which has certain characteristics
(discussed further below). As a licence, it is only meaningful in
the presence of the copyright regime. Open source licences are
explicitly dependent upon the continued existence of copyright for
their efficacy. As open source would not exist without copyright
it is incorrect to assert that open source is opposed to copyright.
Complement of Commercial is Non Commercial, not Open Source
corollary of section 4 above is that open source is a particular
model for the commercialisation of software. It is a different
model, but not a non commercial one. That said, there exists open
source software which is made available on a non-commercial basis,
just as there is closed source software which is made available on
a non-commercial basis.
Complement of Open is Closed, not Proprietary
corollary of paragraph 5.1 above is that the copyright in open
source software is owned by someone, otherwise there is no basis on
which a licence can be granted. As such to oppose the terms
“proprietary” and “open source” software implies that the
copyright in open source software is not owned by someone. This is
incorrect. That said, this use of “proprietary software” is,
unfortunately, widespread. If anything, the complement of
proprietary software is public domain software. That is, software
over which copyright does not exist or is not asserted.
Characteristics of Free Software and Open Source Definitions
important concepts in this area are the definition of open source
software and the definition of “free software”. These concepts
are related, but distinct.
source software is software which meets the requirements of the
open source definition (sometimes referred to as the OSD). The
open source definition is maintained by an organisation called the
Open Source Initiative. The definition includes the following 10
Redistribution – the code must be able to be redistributed
without payment of a royalty;
Code – the source code of the software must be made available;
Derived Works – recipients must be permitted to modify the
software and distribute modifications;
of The Author's Source Code – licence may include some
Discrimination Against Persons or Groups;
Discrimination Against Fields of Endeavour;
of Licence – licence applies automatically to recipients;
Must Not Be Specific to a Product;
Must Not Restrict Other Software;
Must Be Technology-Neutral.
open source definition is available from:
http://www.opensource.org/docs/definition.php. The definition
includes more detail on each of these elements.
free software definition is comprised of the following “four
The freedom to run the program, for any purpose (freedom 0);
freedom to study how the program works, and adapt it to your needs
freedom to redistribute copies so you can help your neighbour
(freedom 2); and
freedom to improve the program, and release your improvements to
the public, so that the whole community benefits (freedom 3).
the licensing terms for software meet these conditions it is said
to be “free software”. Note that the definition of free
software does not require that the software actually be without
cost. To repeat an oft quoted analogy, the “free” in free
software is “free as in speech not free as in beer”. I would
add here, “free as in market, not free as in beer”. The free
software definition is maintained by the Free Software Foundation
It must be kept in mind that these are technical definitions of the
respective terms and it is not at all easy to deduce what the
practical impacts of the application of these definitions from an
abstract study of them.
v Weak Licensing
of the characteristics of open source licences is that they must
“permit” the source code of modifications to the
software to be licensed under an open source licence. The
practical consequences of this permission are unclear. For
example, a permission to license under a specific open source
licence, is not a permission to license on any other basis. Some
open source licences go further, not only permitting, but requiring
that modifications of the software or other, related, software be
licensed under an open source licence, typically under the terms of
the same licence. Where a licence has this characteristic, and
especially so where it attaches to other software, it is said to be
a “strong” licence. That said, strong licensing should be
considered as a spectrum, rather than as two discrete states. If
the licence also requires that source code be distributed in
conjunction with binary code, that will have practical
consequences, thus increasing the strength of the licence. If the
licence permits licensing under a different licence, that licence
must also have an open source licensing requirement for the first
licence to be considered a strong licence. The strong licensing
requirement may be subject to a trigger condition (such as
distribution of the modification). A licence which does not have
these characteristics is known as a “weak” licence.
GNU General Public License (GPL) is the best known, and perhaps the
most widely implemented of the strong licences. It requires that
if modifications to GPLed software are published or distributed,
they must be licensed under the terms of the GPL. It further
requires that works which: (a) include as part of them a
modification of software licensed under the GPL; and (b) which are
distributed must also be licensed under the GPL and that access to
the source code of the software must also be provided. In this way
the GPL may also attach to the distribution of the whole of a work
which includes GPLed code rather (rather than being restricted to
the modification per se). The GPL is the licence which covers the
Linux kernel. The Mozilla Public License (MPL) is another example
of a strong licence. At least one version of the MPL (version 1.1)
permits the nomination of an alternative licence for modifications.
Where the GPL is nominated the MPL will be an example of a strong
licence which permits licensing under different licensing
best known example of a weak licence is the Berkely Software
Distribution License (BSD). Common wisdom is that the BSD licence
permits the software to be modified and for those modifications to
be licensed on a different basis, including under a closed source
licence. One of the requirements of the BSD licence
(“Redistributions ... must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution”) can be read as requiring the BSD to attach to
modifications. However, the absence of an express requirement in
the BSD licence to distribute the source code of software in
conjunction with a binary substantially weakens the licence. The
BSD licence underlies the BSD family of operating systems (eg
FreeBSD, NetBSD, OpenBSD).
text of each of the licences mentioned above is available from:
of the consequences of strong licensing is that care must be
exercised when combining source code from two or more different
projects which are licensed under different licences. To take the
examples above, if two software products, one of which is licensed
under the MPL, the other under the GPL are combined the resulting
product must be licensed consistently with the requirements of both
the MPL and the GPL. If the requirements of these licences are per
se inconsistent then there is no legal basis on which the
output product can be licensed. Compatibility between two licences
refers to whether or not software licensed under those licences may
be combined to produce a work which can be licensed consistently
with the requirements of both licences. Typically it is important
to know whether a licence is “GPL compatible” so that software
the subject of it can be combined with software the subject of the
Free Software Foundation has a page setting out the compatibility
of various licences with the GPL here:
fact that a person has granted a permission in a specific form does
not mean that that person cannot grant further permissions in other
forms. For example, saying someone can come into your yard and use
your pool on Mondays and Wednesdays if they bring a towel doesn't
prevent you from also permitting them to do so on Fridays and
Sundays if they bring a beach ball.
same issues underlie the concept of dual licensing. Under a dual
licence, a software vendor grants a licence over software on the
terms of an open source licence. They will also make it known that
if someone wants to acquire the software under different terms,
then they are prepared to allow that as well. Typically, the
acquirer of the software will want to avoid some aspect of the open
source licence and will pay a premium to do so.
common candidate for a dual licensing is the GPL (see discussion in
section 7). As discussed above, the GPL is a strong licence
because it requires that modifications to the software which are
published or distributed must also be licensed under the terms of
the GPL. So a person might not want to use some code the subject of
the GPL to incorporate into their own software because then that
combination would need to be licensed under the GPL. By offering
the code under a dual licence scheme the dual licence vendor may
charge other vendors to allow them to include the software in their
own products under a licence other than the GPL. Dual licensing is
therefore unlikely to work effectively with a weak licence.
of Dual Licensing
database software vendor MySQL (http://www.mysql.com/) uses a dual
licence model for the distribution of its namesake database product
MySQL. Most of MySQL was licensed under the GPL, although some
parts were licensed under a licence called the Lesser GPL (LGPL).
However, a few years ago they chose to use the GPL for those
components as well. MySQL claims to have one of the largest
installed bases for database software in the world. For more
details about MySQL's licensing see:
open office suite OpenOffice.org also used a dual licence structure
for the version 1 code tree, with the software licensed under the
GNU Lesser GPL (LGPL) and the Sun Industry Standards Source Licence
(SISSL). For the version 2 code tree, only the LGPL has been used.
Risks Relating to Open Source Can be Categorised
open source risks are very similar, or identical, to risks
experienced in relation to closed source, although the greater
freedom afforded by open source means that an organisation may play
a different role in relation to the software and therefore is
exposed to different categories of risk. For example, an acquirer
of software under a closed source licence is usually prohibited
from distributing that software so risks associated with
distribution will not arise in practice. However, under an open
source licence that acquirer will be free to distribute that
software if they choose to and, as a result, may be exposed to
risks related to that distribution.
Source risks can be broadly separated into three categories:
one might expect, acquisition and supply risks have obvious
meanings. Acquisition risks relate to the risks which are involved
in the acquisition of software from a third party. Supply risks
relate to the risks involved in the supply of software, whether
your own or someone else's, to a third party. Interlinked risks
are risks which involve an element of both of these aspects – for
example, the acquisition of some software for the purpose of
modification and on supply of the software as modified.
of How Risks can be Addressed
source risks are addressed through proactive action and risk
management plans. Those plans involve steps such as: the
identification and classification of the risk, an assessment of the
likelihood of the risk occurring and of the consequences if it does
occur and taking proactive steps to prevent or address the
occurrence of the risk.
measures include the adoption of policies to be followed when
acquiring open source software, including the conduct of a due
diligence check in much the same way as a credit check would be
carried out on a closed source vendor. Where the open source
software is acquired under a contract, they can also include
contractual provisions which address specific aspects of the risks.
addition, establishing a process to identify and restrict the
likely uses of open source software also assists in addressing
risks. For example, by restricting activities in relation to open
source software to acquisition and use automatically excludes
supply and interlinked related risks. The policy may require
special permission to be sought if the relevant employee proposes
to have the organisation engage in (eg) a supply of open source
software. A policy position might include different due diligence
processes to be followed depending on whether the proposed
activities included acquisition, supply or interlinked aspects
effects of open source licences can occur immediately on the
occurrence of a trigger condition (such as, the distribution of a
modification to the software). The most important aspect of risk
management in this area is therefore a proactive approach to open
source acquisition and use.
- Wrapping Things Up
are several dozen open source licences approved by the Open Source
Initiative. Of these, one, the GNU GPL, accounts for roughly two
thirds of all projects on the Sourceforge software repository. We
conclude this paper with an overview of two of the best known
licences – the GNU GPL and the BSD licence and provide a number
of short case studies of open source related matters that OSL has
been involved with. These case studies give some insight into the
breadth of issues which can arise and some of the means of
General Public License
GNU General Public License (GPL) is the licence of choice of the
GNU Project (www.gnu.org) and of the Free Software Foundation
(www.fsf.org – note, this is the same site as www.gnu.org). This
paper relates to version 2 of the licence, available from:
GPL grants broad usage rights. Where a person is granted a GPL
over software, they may copy and distribute the source code of the
software verbatim (clause 1) subject to the following:
must include an appropriate copyright notice;
intact all notices referring to the GPL and the absence of a
other recipients of the program a copy of the GPL;
licensee may also copy and distribute the object code of the
software provided that they comply with the qualifications set out
in paragraph 14.2(a)-(c) above and simultaneously distribute or
provide effective access to the source code (the licence sets out
specific options in relation to the distribution of the source
code) (clause 3).
GPL also includes an express disclaimer of warranties and an
exclusion of liability.
GPL permits the making of changes to the software and does not
require the distribution of changes made. However, if you do
distribute those changes, and they are “derived from” the
software, you must distribute those changes on the terms of the
GPL. This makes the GPL a strong licence. It is not clear from
the wording of the licence, but this licensing requirement is
unlikely to apply to “internal” distributions within the
BSD (Berkeley Software Distribution) Licence was originally
included with the distribution of the Berkeley Unix in the early
90s. There are two versions of the BSD licence, distinguished by
“the advertising clause”. The advertising clause was removed
from the standard BSD licence in 1999. The BSD licence
template is available from:
BSD licence permits “redistribution and use in source and binary
forms, with or without modification” provided that:
notices are retained;
licence conditions form part of the distribution (for
distributions of binary code, the conditions may be set out in
documentation or other materials provided with the distribution);
advertising materials mentioning features or use of the software
must display a specific acknowledgement. The pro forma
acknowledgement refers to the University of California, Berkeley,
although other people who adopt the old style BSD licence insert
their own details. This requirement is only present in “old”
(ie pre 22 July 1999) BSD licences and licences which take their
pedigree from old BSD licences;
use is made of the University of California to endorse or promote
products derived from the licensed product.
BSD licence also includes a generic disclaimer which attempts to
exclude all liability resulting from use of the software.
Department of Commerce – Linux Panel Contract
Department of Commerce was in the last stages before issuing a tender
for Linux related goods and services. While they had arrived at a
policy approach on a number of important issues, they were unsure of
how to modify their standard terms and conditions to accommodate open
source and their desired policy approach.
negotiations subsequent to the submission of tenders they were faced
with pushback to some clauses from a tenderer.
revised their standard terms to:
(a) create a rigorous definition of “open source software”;
(b) make specific adjustments relevant to the use of open source
software (eg no need for escrow agreement if source is provided);
(c) ensured that closed source components were permitted, but were
given treatment different to that of open source components (eg
negotiations we identified that tenderer's response did not properly
understand the operation of the clauses (or were using open source as
a smoke screen to avoid obligations).
successfully negotiated Linux contracts with a number of tenderers.
Protected client against muddy thinking on open source issues.
Department of Commerce – Open Source Issues Advice
client wanted to properly understand the open source legal landscape
and issues which they may encounter in respect of open source.
detailed advice covering, among other things:
for identifying existing open source usage and licences;
of effect of open source licences accounting for 95% of projects
against agreed measure;
of risk categories for open source;
examples of risks in each category;
on managing these risks;
of business models for commercialisation of open source software;
related issues for open source;
open source policy.
will form the basis of an open source information resource for the
whole of NSW State Government.
Source Friendly Contracting Agreement
client wished to engage contractors to do specific work involving the
use of open source. Contractors baulked at standard terms,
considering that they may be inconsistent with the licensing
requirements imposed upon them through the use of open source
standard contract to make it open source friendly. The contract
included specific provisions to ensure that the use of open source
was subject to the informed consent of the customer, with optional
clauses for the open source licence back of material if agreed or
required. The contract also included a specific procedure for
identifying open source inputs. We also helped highlight to
contractors that there is no inconsistency between IP ownership
clauses (vesting IP in the customer) and open source licences.
contract used for open source related projects.
client was interested to know what consequences were involved in the
adoption of a specific licence for software that they were planning
to release. They had heard a lot about the GPL and were wondering
about how the use of the GPL would constrain them in the future. The
client was concerned that the presence of a GPL version would
undermine the revenue stream for the product.
reviewed the licence terms and their application to the particular
circumstances. As the client would own all of the copyright in all
of the relevant material the client would need to honour its existing
licences in respect of third parties, but was not bound by the
requirements of the GPL in respect of future modification or
client ultimately settled on a delayed licensing approach, with the
release of a GPL version “lagged” behind a closed source version
(by two versions).
or versioned releases can lead to difficulties in maintaining two
code bases which may have a tendency to diverge. The model also
requires careful treatment of community contributions, as special
care is needed for the inclusion of those contributions under the
closed version of the product.
client wished to include a number of packages licensed under
different licences into a single installer package which could be
downloaded as a single file and installed with a single click on a
target computer. One of the packages was licensed under the terms of
analysis the archive document was a work which included the whole of
a work the subject of the GPL – and therefore the archive needed to
be licensed under the terms of the GPL. On a conservative reading,
this meant that other packages in the archive may need to have GPL
disclosing the identity of the client, we initiated informal contacts
with the relevant project owners about the executable archive
approach and whether, if it was caught by the licence, they would be
willing to make an exception. The project owners were not willing to
make such an exception.
client chose to adopt a conservative approach and separated out
differently licensed components for end users to acquire separately.
discount the possibility of a direct approach to the relevant
copyright owner. In this case it was not successful.
important in all open source cases to be proactive not reactive.
There is no negotiation process as it is ordinarily understood, and
there is not necessarily any continuing client relationship or any
interdependency between licensee and copyright owner. There is
little or no opportunity to correct a mistake after the fact.
Compatibility – Archiving
somewhat worrying corollary of the licence compatibility study
presented above is that if an organisation is running backups and
those backups include GPLed software and those backups are sent to a
third party for off site storage, then the archive tapes may be
required to be licensed under the terms of the GPL! This of course
depends on a number of variables including the manner of storage.
However, the risk is there.
raised this with Eben Moglen of the Free Software Foundation shortly
after Linux.Conf.Au in 2005.
understand there are provisions in GPL v 3 which address this.
paranoid may care to have their backup procedures reviewed by legal.
Technology Project – Dealing with Government Grant.
client was a University technology commercialisation arm. They were
in the process of developing a specific product which used open
source inputs. The funding grant for the work imposed specific
requirements on the licensing of work outputs, including the
licensing of third party components. The grant conditions were
technically inconsistent with the terms of the third party input.
The project also had a third party collaborator which would be
providing (non open source) inputs.
identified the issues raised by the grant terms, highlighted the
inconsistencies and argued that the objectives of the grantor would
be fulfilled through the substitution of the open source licence
terms in favour of the grant terms. Grantor was satisfied that its
interests were adequately protected. Renegotiated the grant terms.
We also advised on appropriate terms for the provision of input from
the third party collaborator.
terms were successfully changed to permit the use of open source
Hardware Vendor – Preinstalled Open Source
client is involved in the production of computer systems. They had,
over some period of time, received customer feedback to the effect
that the preloading of a specific configuration of open source
packages would be desirable. The customer's head office/IP section
was concerned about what would need to be included in contractual
provisions, and what risks would be involved.
(a) provided a briefing to the CEO on issues including suggested
(b) provided an overview of what competitors are doing in the market;
(c) commented on the availability of insurance and the pricing of
(d) provided a menu of legal conditions that could be used when
providing this package. It was important that the terms be able to
be interfaced with existing contracts and should appropriately
in the process of being taken to market.
market may have different contractual requirements of the provision
of open source compared to the provision of closed source. Not
recognising this may result in incorrectly costing a product, or
making promises which cannot be fulfilled.
Corporate – Adoption of Open Source Package
client wished to implement well known and long standing open source
code in a product, but were concerned about risk. The licence terms
for this code were non standard but probably open source compliant.
supported the client in making an informed decision on the
(a) identifying the appropriate licence terms;
(b) determining whether the licence terms were sufficiently broad;
(c) providing guidance on evaluating the bona fides and credentials
of both the package and the person or project from which the package
weighed risks, decided to adopt package.
the same process can be used when adopting open source packages.
an open source acquisition policy is a quick and easy first step to
take on addressing open source within your organization.
Corporate – Use of Open Source against Infringing Competitor
has reason to believe a competitor is infringing an open source
package in the competitor's product.
identify means of determining infringement;
possible consequences (one of which is nuclear);
an overview of the process of bringing the infringer to account.
disclosure at present.
an open source licence can result in the issue of an injunction
restraining the distribution of the product; the award of substantial
damages; the disclosure of the infringer's IP and criminal sanctions.
Clients – Multiple Issues
most organisations are already using open source software in some
form or another. Unfortunately, a common process for open source to
enter an organisation is as follows (and all of this probably
occurred several years ago):
(a) an engineer wants certain functionality which is provided by an
open source product;
(b) the engineer puts in a requisition to buy a closed source
(c) requisition is rejected or takes too long to approve;
(d) the engineer notices that open source has $0 acquisition costs,
so not covered by acquisition policy;
(e) the engineer raises the issue of open source informally with
(f) manager is mildly to violently opposed, may or may not consult
legal, forbids use of open source;
(g) (optional) lawyer provides fire and brimstone advice to the
effect that open source is responsible for third world poverty and
will make you go blind;
(h) the engineer considers this, and especially the lawyer's
response, as irrational;
(i) the engineer acquires open source anyway, satisfies need, no one
is any the wiser.
method of acquiring open source immediately places the engineer on a
siege footing. Should management raise open source in the future,
the engineer must deny all knowledge. When legal asks the engineer
about open source they will avoid the issue or prevaricate. When
legal issues an edict that all open source needs to be approved by
legal, the engineer interprets this as a blanket prohibition (which
it may or may not be).
engineer rejects management and legal's recommendation (or direction)
is not entirely clear. However, we can speculate that it is a
combination of some of the following factors:
(a) the typical engineer's formidable self confidence;
(b) their refusal to accept arguments from authority (rather than
(c) the comparative unimportance of the software being acquired;
(d) the comparative expense of the closed source alternative;
(e) the need for some result to be achieved quickly;
(f) the lawyer's advice was, all things considered, excessive, over
the top, uninformed and, in some places, bordering on the hysterical.
What's more it was inconsistent with the engineer's own knowledge of
open source and appeared purely reactionary;
(g) the engineer placed their trust in one or more unqualified domain
specialists (see below)
prohibitions unsupported by reasoning may be counterproductive in the
long run. This has probably already happened within your
common occurrence (and something of a corollary of the acquisition
scenario identified above) is that knowledge of open source licensing
and the possible consequences are provided from within the
engineering section – by engineers. The basis of this advice is
comments by other engineers, and commentary available over the
internet. In the great majority of cases this commentary is by
another engineer or by some other person who has no qualifications as
a lawyer, and, in fact has nothing even remotely resembling legal
engineer probably has a functional knowledge of the open source
landscape and are well aware of other, similar, deployments which
appear to be working well. They don't pay particular attention to
the specific circumstances which are involved, and may not be aware
of critical differences (licence wise) between those and their own
implementation. As such, when presented with the opinion of a lawyer
to which says (effectively) that open source is evil, it is easy for
the engineer to dismiss the view as uninformed (going on what is
reported in the media it would not surprise me if they were in
value of the bush lawyering which is present in the open source
community is roughly equivalent to that in other areas (although is
perhaps more prevalent), which is to say, it is not very valuable.
Some common misconceptions include:
BSD permits me to license the
code under my own license
GPL requires me to distribute my
Using contractors to work on
“internal” open source projects is no problem
these circumstances it is important to be part of the solution,
rather than part of the problem. When faced with these circumstances
(a) provided training to engineers, by way of presentation with an
emphasis on practical risks (and judicious use of the views of
specific unqualified domain specialists or organisations with moral
weight within the open source community);
(b) put together an acquisition policy for open source;
(c) helped to audit and identify existing open source usage;
(d) provided guidance on what to consider to make informed decisions
on open source acquisitions.
good thing about engineers is that they are amenable to persuasion by
reasoned argument and exposition of the real (not just theoretical)
risks. It is important to make it clear that open source
acquisitions will be treated roughly equivalently to closed source
acquisitions. This is not all that hard as the issues are largely
the same, but the risks have been internalised in the case of closed
adopted more responsible approach to open source usage.
call your lawyer to plan your network topology.
call your technicians to give you legal advice.
often receive inquiries from businesses who want to get involved in
open source, and want to do the right thing, but are not clear on
what is right and what is wrong in the circumstances. That is, there
is a desire to comply with both the letter and the spirit of the law.
queries can often be resolved with a short phone call. OSL maintains
contacts with many leading figures in the open source industry, both
within Australia and overseas. We are able to put people in contact
with peers who may have an informed view and to make informal
contacts on a client's behalf.
Known Organisation – Non Open Source Touted as Open Source
third party (not a client!) chose to use the term “open source”
in a marketing campaign in respect of a licensing initiative. This
was motivated by the fact that a key component of the initiative was
the use of software licensed under terms which were not OSI approved,
but were claimed by their vendor to be compliant with the open source
definition. The marketing material clearly signalled a problem to
the open source community as it referred to open source in one
breath, then described a discriminatory licensing regime in the next
(open source licences cannot be discriminatory).
outcomes were easily foreseeable. Had we been asked, we would have
told them to:
market the initiative as open source; or
the vendor to have their licence OSI approved.
immediately came under fire from a number of directions, and could
not justify their material. They had to keep their head down until
things blew over. Now, no one mentions the war.
well be that the licence for the software met the open source
definition. However, this was not immediately obvious and you don't
want to have to put yourself in the position of having to argue the
subtle definitional issues involved in a public forum.
cautious about claims to openness. Insist on an OSI Approved
open source community is wary of imposters. If unsure, find an
appropriate sounding board to consult about open source related
initiatives prior to announcing them.
Info on Infringements