Ipross

IPR issues in open
source software
Carlo Daffara
Conecta

Some initial definitions: IPR, Free/Libre Open source
●

software
● Intellectual property (IP) are legal property rights over

creations of the mind, both artistic and commercial, and
the corresponding fields of law. Under intellectual
property law, owners are granted certain exclusive rights
to a variety of intangible assets, such as musical,
literary, and artistic works; ideas, discoveries and
inventions; and words, phrases, symbols, and designs.
Common types of intellectual property include
copyrights, trademarks, patents, industrial design rights
and trade secrets.
● The majority of intellectual property rights provide
creators of original works economic incentive to develop
and share ideas through a form of temporary monopoly.

IPR issues in open source software

Open source software: software that is distributed under
●

a license that comply with the OSD definition:

Derived Works: The license must allow modifications
●

and derived works, and must allow them to be
distributed under the same terms as the license of the
original software.
● Integrity of The Author's Source Code

● No Discrimination Against Persons or Groups

● No Discrimination Against Fields of Endeavour

● Distribution of License

● License Must Not Be Specific to a Product

● License Must Not Restrict Other Software

● License Must Be Technology-Neutral


Free software has a similar definition, and in fact OSS
●

and FS may be considered as legally similar (but with
different ethical backgrounds)
● It may seem that OSS and IPR are mutually exclusive,

as usually IPR is “protective” and is a barrier against
external leverage of an intellectual resource
● The opposite is true: licenses are grounded in copyright,

and are strongly enforced
● There are 4 main area of interest in the research
community related to OSS and IPR:
● Legal basis for OSS IPR (licensing)

● Business basis of OSS IPR (business models and

competition barriers)
● External IPR in OSS (compliance)

● Patents, standards and OSS


There are more than 50 licenses identified as quot;open
●

sourcequot; or quot;free softwarequot;; those can be classified in a
very simple way as:
● quot;provide creditquot;: use, modification, redistribution are

allowed, but credit to the original author is due, if
redistributed. Examples: BSD license, Apache License
v2.
● quot;provide fixesquot;: use, modification, redistribution are

allowed, but source code for any changes must be
provided to the original author, if redistributed.
Examples: Mozilla-style licenses (Mozilla Public
License).
● quot;provide allquot;: use, modification, redistribution are
allowed, but source code of any derived product must
be provided, if redistributed. Example: GPL.


OSS licenses have been enforced several times, in the
●

USA and in Germany, and several commercial
companies settled OSS licensing issues out-of-court...
● … this means that licenses should be considered valid

for all purposes
● Different kind of licenses apply to different kind of digital

artefacts – for example, Creative Commons licenses are
used for documentation, images, non-code contributions
● Very similar to the classification presented: do as you

like, share-alike, etc.
● Warning: CC does have a “non-commercial” license

(unlike the OSS definition)


Why should I worry about OSS? Two reasons:
●


Why should I release something that is protected under
●

an OSS license, and thus losing my protection?
● Many potential advantages: R&D sharing, market
dissemination, alternative business models
● R&D efficiency is among the most studied aspect:

“The total software stack includes 10.5 million lines of code
(product and development tools), which is split into 85% coming
directly from OSS, and 15% either modified or developed by
Nokia. In source code lines the respective amounts are 8.9 Million
lines of OSS code and 1.6 million lines of Nokia developed
software. Out of the 15% created by Nokia, 50% are made
available to the community as modifications to components or
totally new components, leaving roughly 7.5% of the software
stack closed. (…) Based on the COCOMO model we can estimate
the value of the utilized OSS to be $228,000,000, including both
product software and tools.”


Apple: “Based on the COCOMO model the total cost of
●

internally developing the OSS included in the Darwin
core and the used development tools would be
$350,000,000.”
● Long-term advantage: the R&D may shift effort to
higher-levels (differentiating) and not waste time
reinventing the wheel


Is it true also for exogenous business models?
●

Economic theory tells us that in a commodity market, in
absence of strong exclusionary protection the price
lowers to reach the marginal cost of production
● But is software a commodity?


OSS Vendor Vendor Number of Sale condition Freeriding protection
Business model example covered
products
Dual licensing MySQL single or few integration of the product with non-OSS license choice
components in externally distributed
products

Open Core Zimbra single or few Need for the proprietary additions or need license choice, segmentation on features
of support
Product specialists Alfresco single or few Value perceived by user must be higher license choice
than the cost of going to an unsupported
recompilation (eg. CentOS); usually
mission-critical environments, need of
support or lack of internal expertise

Platfrom Providers RedHat many Value perceived by user must be higher license choice, copyrighted and
than the cost of going to an unsupported trademarked elements included in the
recompilation (eg. CentOS); usually product
mission-critical environments, need of
support or lack of internal expertise

Software Selection Navica many Complex requirements, many areas or Selection documents are usually
strict vertical requirements to match, proprietary; selection requires human
possibly large company size intervention (non-replicable)

Aggregate support OpenLogic many Large number of managed projects, use Inherent in the non-transferability of
providers in mission-critical infrastructure support contracts
Legal certification and Palamida many Potential legal risk Inherent in the non-transferability of
insurance certification and insurance

Training and documentation Gbdirect many Lack of internal experts (or too high cost Training material are usually non-public,
for creation of internal skills), complex trainers are inherently non-replicable
configuration and setup of OSS product

R&D cost sharing Eclipse single or few Significant R&D costs, higher than the license choice
cost of management of the shared
community

Indirect revenues Firefox single or few There should be an external source of license choice, copyrighted and
revenue linked to adoption (eg. trademarked elements included in the
Ecommerce sales of related products, product
search engine back-payments, etc.)
Usually linked to high adoption numbers

Exactly as it is important for companies that sell systems
●

(packages, devices, …) that contain code to be sure that
OSS is properly included, OSS projects must check that
code is properly vetted
● Most projects have a strict and complex IPR compliance

process


Last part: patents
●

● Software patents are among the most controversial
areas both in terms of legislation, legal practice and
market
● Problems: very low quality of issued patents, unclear

legislation (are software patents allowed or not?),
“submarine patents”, patent trolls
● It is actually IMPOSSIBLE to know if a specific software

infringes on someone else patent
● Microsoft has patented the “Pageup/Pagedown”
functionality in 2008 (US7415666); IBM the “system and
method for providing reservations for restroom use” that
patented the idea of queueing for the bathroom
● OSS is especially vulnerable, as the code is open for

inspection


Some licenses explicitly mention SW patents: if code is
●

released, all hidden patents are given for free use as
well
● Microsoft avoided this: it paid another company to
release code, thus retaining the right to sue, and in the
Novell case reworded the agreement as a “covenant not
to sue” and not a licensing agreement
● The community responded with the GPLv3, but the

problem is still there
● Some companies pooled their patents together in a

“nuclear arsenal” to protect Linux-based systems
● The problem of patents is also appearing in the
formulation of international standards: many companies
are pushing for ISO standards that due to embedded
patents are not implementable in open source


Sometimes it is possible to find patent-free alternatives,
●

or standards for which the patents are offered in an
OSS-compatible way
● It is debatable whether patents are really needed in

standards: companies are obviously interested in the
large potential market for IPR licensing
● A common view is that standards are costly to develop,

and in absence of IPR licensing and protection the costs
could not be recovered
● This contrasts with the approach used by groups like

W3C that allow for IPR on standards but only within a F-
RAND framework
● Is it true that interface standards compress pricing?


Thanks

Carlo Daffara
cdaffara@conecta.it

Ipross

Recommandé

Recommandé

Contenu connexe

Similaire à Ipross

Similaire à Ipross (20)

Plus de Carlo Daffara

Plus de Carlo Daffara (20)

Dernier

Dernier (20)

Ipross