Workshop on OSS with TT perspectives Meeting of the TT Network Board and Steering Committee Friday...

Workshop on OSS with TT perspectives

Meeting of the TT Network Board and Steering Committee

Friday 10 December 2010

Bernard DENIS

OutlineWorkshop content and contributorsNecessary measuresChoosing a licenseIndustry perspective and commercialization optionsFinancing maintenance and supportAvailable tools

OSS workshop with TT perspective


Workshop content and contributorsNecessary measuresChoosing a licenseIndustry perspective and commercialization optionsFinancing maintenance and supportAvailable tools

Workshop content and contributors OSS Policies OSS in academia Experience, needs and expectations

Industry experience in using OSS

OSS licenses

Doing business with OSS

WIPO, INRIA, CERNCERN/BE, GEANT, GEANT4, ROOT, IN2P3, GSIMorgan Stanley, NTNU, Ernst & Young,

Blumbach & Zinngrebe, DLA PiperBlumbach & Zinngrebe, DLA Piper, OSS watch


Necessary measures - general

Efficient and centralized governance: Decision making (including the license scheme) Maintain coherence Democratic versus dictatorship



Anticipate the end at the start How the software will be used and disseminated

Need to maintain a clear legal status Ownership Nature (first, derived, composed) Contract affecting the status of SW

SW audit at the beginning and during the project



Raise awareness on: IPR license ownership issue (employment contract,

collaboration agreements, …)

Make legal advise available (as opposed to opinion)



Good development practices: Track and record external code integrated Identify all contributors Strict “header” (copyright statement) management

(in-house and external software) Encourage modular software Common development environment (e.g. Forge)


Necessary measures - TT

Need a clear transfer scheme/strategy on the case by case basis

Clear legal status Proper packaging Need for quality Support for user should be available


Necessary measures

Have a OSS policy but keep it simple!


Choosing a license - options

Making software available using permissive license (BSD) Free but no so free (integration and maintain it

yourself) “as-is” but also quality Developer-oriented Do not contain patent provisions (except Apache)



Making software available using a non-permissive license (copyleft) (GPL) Feedback, bug fixes, comment, translation

(reciprocity) Quality (reputation) Not-industry friendly(?)



Making software available under semi-permissive license (LGPL): Many user from industry providing interesting

feedbacks (but rarely code contribution) User oriented/quality



Use existing license Choosing the type of license when

collaborating on software development At the beginning, when the transfer scheme is

clear At the end, depending on the code included

Note: the legal issues have an impact on the technical issues e.g. there is an architectural impact of using GPL software


Choosing a license - limitationsCan you start with OSS and then impose restrictions? Depends on the license If GPL no further restrictions

a can be imposed. GPL license does not allow the modification of the license itself.

Under OSS it is not possible to limit the purpose of use of a software.

It is however possible to have a non-commercial license with limits on the use based on a OSS license (except GPL)

Note: when the sofwtare is out, there is no way to step back


Choosing a license - liabilityCan you be liable for OSS used for medical applications? Yes, you may be liable because the license

exclusion clause may not be valid in the EU. GPLv3 allows to amend the license on this specific point (use exclusion of EUPL)

This risk should not be a reason not to do OSS. For medical applications, you should use a good liability clause (no more OSS!)


Industry perspective and commercialisation options

Commercialisation options: Using different license fee depending on the user

(academic or commercial) Dual license (difficulty when many contributors) Software as a Service (SaaS) Use of GPL SW for internal purpose Multi-licensing business (user segmentation) Open-core licensing


Motivations Possibility to have high quality software and

collaboration with a community of motivated developers

Learning effect and reputation gain in the developers’ community

Lower costs and faster time to market Note: Importance of active and supportive

community (permissive license)



Other issues/comments: “GPL is a challenge… “ <> “No GPL here!” Different of OSS adoption level: from open

innovation up to community building Legal uncertainty, many stories around



Financing maintenance and support

Goodwill of developers Provide remunerated service Generate interest by releasing early to attract

funding Create a foundation/trust for long term and

big projects (also used to manage the copyright issues, licensing and marketing)


Available tools

Free software directory and toolshttp://www.ohloh.net

Tool to analyse source and reprots its licensinghttp://www.fossology.org


http://www.ohloh.net/

http://www.fossology.org/

http://www.fossology.org/

Concluding remark

Permissive Non-permissive (open) (viral)


Industry-friendly Truly-open

BSD, Apache,CeCILL

LGPL GPL, EUPL


Thank you!

Workshop on OSS with TT perspectives Meeting of the TT Network Board and Steering Committee Friday...

Documents

Transcript of Workshop on OSS with TT perspectives Meeting of the TT Network Board and Steering Committee Friday...