Simon Phipps

1222 points
Simon Phipps (smiling)
Southampton, UK

Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as President at OSI and a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!

Over a 30+ year career he has been involved at a strategic level in some of the world’s leading technology companies. He has worked in such hands-on roles as field engineer, programmer and systems analyst, as well as run a software publishing company. He worked with networking standards in the eighties, on the first commercial collaborative conferencing software in the nineties, and helped introduce both Java and XML at IBM.

In mid-2000 he joined Sun Microsystems where he helped pioneer Sun’s employee blogging, social media and community engagement programmes. In 2005 he was appointed Chief Open Source Officer at Sun Microsystems, coordinating Sun’s extensive participation in Free and Open Source software communities until he left in 2010. In that role he oversaw the conversion to Free software of the full Java platform and the rest of Sun’s broad software portfolio, all under OSI-approved Free licenses.

He takes an active interest in several Free and Open Source software organisations and also serves as a director of the UK's Open Rights Group, campaigning for digital rights. He was previously instrumental in the revival of the Open Source Initiative, serving as a director and as its President, a role to which he has now returned. A widely read thought-leader, he publishes regularly both on his own blog and in many other places such as IDG’s InfoWorld.

Authored Content

ACTA's back

Technology issues are now a matter for citizens of the internet and not just big corporations. Now that the US bills SOPA and PIPA have been put on ice, attention has returned…

Authored Comments

Things that create an uneven playing field always make open source communities unhappy. Separation of the interests of participants is right at the heart of software freedom. By giving themselves explicit preferential status, Facebook have very clearly violated this core principle of open source and free software.

I fear the headline (and to some extent the article) reflect the "attack of the compliance-industrial complex" to which Bradley alludes (I heard the term in a talk at FOSDEM so it's not mine!) As he states, there is no evidence the GPL is objectively declining, just that commercial use of open source is increasing. I think it's regrettable this is spun as a strike against the GPL rather than as a win for the whole open source movement.

An open source project is the “safe space” in which developers with an interest in a piece of software, for whatever reason, are able to collaborate over its evolution without the motivations of others impacting their own usage. The open source license the project uses defines and guarantees the things over which those developers need certainty. All give the right to use the code for any purpose, to share it with anyone, and to make whatever changes they want. Beyond those essential freedoms, different communities need different certainties.

Communities working on code that is normally used directly, alone and in its entirety – application software such as LibreOffice, for example – may well want their license to also guarantee reciprocal grants of the same rights to other developers. Most of the LibreOffice core developers work for companies that offer support, training, customisation and deployment. Because everyone who offers these services has to contribute their work as a license requirement, it’s much less likely that a freeloader will be able to undermine their business. The reciprocal license – in this case the Mozilla Public License v2 – is a key attribute expected by the community. Other projects such as GNOME and the Linux kernel use reciprocal licenses (the GPL in those cases) for similar reasons.

This is not true of every community though. For developers mixing ingredients from multiple origins – frameworks, components, libraries – reciprocal license requirements increase the uncertainty rather than decrease it. Their employer may be concerned about managing the different reciprocal duties of different licenses, such as the Eclipse Public License (EPL) and the GPL. The different expectations of the nature and rigor of proof of reciprocity by different communities may also be a concern. For these developers, it is much simpler to use non-reciprocal licenses for their code, especially if the code in question is not directly monetised.

So perhaps a better way to view the subject is to note that the open source world has grown enormously. The use and support of the GPL has also grown with it, but new strengths have also emerged related to corporate adoption of open source. The choices by various communities of the certainties they prefer to protect need respecting.