Acht misverstanden over GPLv3

Het blijft wachten op de definitieve tekst van GPL versie 3. Over een maand zou er een nieuwe concepttekst moeten komen, maar wanneer de definitieve versie er is, blijft een open vraag.

Dat heeft als vervelend bijeffect dat mensen gaan speculeren over wat er allemaal in zal komen en wat dat voor consequenties kan hebben. Ondertussen zijn er dus al aardig wat misverstanden en ruzietjes ontstaan.

Bruce Byfield zet in IT Manager’s Journal de misverstanden op een rijtje en legt uit wat er wel en niet klopt:

Some of these misunderstandings are due to the lengthy and public revision process for GPLv3, which offers plenty of opportunity for rumors and misreadings. Others may be due to the extensive rewriting of several key sections of GPLv3, notably the language on patents and TiVoization, during the process, so that people are concerned about issues from earlier drafts that the current one corrects or addresses. Still others seem due to willful misunderstandings by opponents of free and open source software. Perhaps, too, the fact that GPLv3 is more obviously a legal document in structure and content than GPLv2 adds to the confusion. But, whatever the origins of the misunderstandings, many have gained currency in both the media and some parts of the free and open source software community.

In 2006 deed hij hetzelfde voor GPL versie 2. Het is ergens wel zorgwekkend dat een concepttekst al minstens zo veel misverstanden heeft opgeleverd als een 15 jaar oude eerdere versie.

Arnoud

Sun pleit voor betaalde open source

Sun pleit voor betaalde open source, zo meldt Computable.

Softwareontwikkelaar Sun heeft moeite met de manier waarop andere bedrijven gratis open source verder ontwikkelen en er vervolgens veel geld aan verdienen. Daarom stelt de onderneming voor om open-sourceontwikkelaars te betalen voor de codes.

Bedrijven doen mee aan open source omdat het kosten bespaart en het zo mogelijk is om te focusseren op de differentiators. Dat kun je zien als “veel mensen werken gratis aan open source en bedrijven profiteren daarvan”. Maar dan negeer je natuurlijk wel het feit dat die bedrijven ook weer bijdragen aan open source.

Hoe Sun het betalingsmodel ziet, is nog niet duidelijk. Licentievergoedingen zitten er niet in, dat is strijdig met het hele model van open source. Je zou kunnen denken aan een eenmalig bedrag (een premie of bounty) voor het ontwikkelen van bepaalde features, of een vergoeding voor ondersteuning.

Arnoud

Zeven redenen waarom Microsoft van open source houdt

Met zo’n titel krijg je natuurlijk de volle aandacht van iedereen die denkt dat Microsoft er op uit is om open source te vuur en te zwaard te bestrijden. William Hurley schrijft:

I know popular opinion has Microsoft cursing open source at every turn, but what do the facts indicate? Do they really despise something they clearly benefit from? I don’t think so—the folks in Redmond aren’t that short-sighted. In fact, I’ll give you seven reasons I think Bill and Co. love open source:

Lees verder op Seven Reasons Microsoft Loves Open Source.

Arnoud

Uitkijken met GPLv3 – is deze geschreven voor juristen of programmeurs?

IPcentral Weblog komt met een top 10 van redenen waarom software-ontwikkelaars moeten uitkijken met GPLv3. Het meeste is redelijk kort door de bocht, maar er zit wel een waar woord in item 1 (“De formuleringen uit GPLv3 zijn lastig te begrijpen”):

A license should clearly inform people what they can and cannot do. GPLv3 does neither. Lawyers assume that they could understand it if only they were software engineers, and engineers assume that the lawyers grasp it. Both are wrong.

Dat verklaart waarom juristen zo veel praten over dynamisch en linken (alsof dat de enige manieren zijn om software te combineren) en programmeurs lijken te denken dat het vast wel goed zit omdat er zo veel lange zinnen in staan, en het door een hoogleraar rechten opgesteld is.

Arnoud

‘Open source collaboration’: de innovatie van nu?

Zojuist gevonden op Livre: ‘Open source collaboration’: de innovatie van nu?.

Als we vandaag de dag het woord innovatie in de mond nemen, bedoelen we in veel gevallen een verbetering van een al bestaand product. Daar is niets mis mee, zolang we maar erkennen dat innovaties wat anders zijn. Dan heb je het over bijvoorbeeld ‘open source collaboration’, een innovatie die de grondslag onder het bestaande bedrijfs- en productiemodel wegslaat. ‘Open source collaboration’ biedt het eerste industriële model dat écht gebaseerd is op technologie, waarbij de innovatie niet zit in het product, maar in de methode van ontwikkeling. Geert-Jan van Bussel praat ons bij en legt gelijk uit welke rol de Gates Foundation speelt in de ontwikkeling van ‘open source collaboration’.

En inderdaad, open source is niet alleen maar software, maar een ontwikkelmodel. Bedrijven doen mee aan open source omdat het hun business vooruit helpt.

Arnoud

Open source praktijkgids (in Programma’s > Open source software @ iusmentis.com)

Nieuw op Iusmentis: Open source praktijkgids

Open source is een verzamelnaam voor alle soorten software waarvan de broncode vrijelijk ter beschikking gesteld wordt. Iedereen mag aanvullingen of verbeteringen maken voor de software en deze verder verspreiden. Pakketten zoals het Linux besturingssysteem, de Firefox webbrowser of the Apache webserver zijn de bekendste voorbeelden van open source.

Open source heeft zeker voordelen. Het kan alleen lastig zijn om uit te zoeken wat nu precies mag. Open source licenties lijken op een aantal essentiële aspecten af van traditionele “gesloten” licenties of EULAs. Het meest opmerkelijke is de eis om eigen software die voortbouwend op open source ook weer vrij te geven als open source.

  • Wat is open source
  • <li>Open source als een ontwikkelmodel</li>
    
    <li>De open source gemeenschap</li>
    
    <li>Voordelen van open source software</li>
    
    <li>Risico's van open source software</li>
    
    <li>Uitgangspunten van open source licenties</li>
    
    <li>Interpretatie van licentievoorwaarden</li>
    
    <li>Herkennen van open source</li>
    

Lees verder in Open source praktijkgids (in Programma’s > Open source software @ iusmentis.com).

Er is ook meteen maar een Engelse versie, Open source in practice.

UPDATE: bij Livre hebben ze het gevonden.

Arnoud

Economische motivatie om mee te doen aan open source

Vandaag vond ik een nieuw artikel van Dirk Riehle, The Economic Motivation of Open Source Software: Stakeholder Perspectives in IEEE Computer Magazine. Het zoekt naar de economische motivatie van de bedrijven die bijdragen aan open source. Riehle focust daarbij op ‘integrators’, bedrijven die complete producten of diensten leveren waarbij ze technologieën van vele verschillende partijen integreren. Bedrijven die moeten profiteren van open innovatie dus.

Zoals al beschreven in het boek Innovation Happens Elsewhere, gaat het bij open innovatie niet alleen maar om het aan- of verkopen van innovaties, maar ook om het gratis delen daarvan. En open source is een zeer geschikt middel om innovaties te delen.

De grote vraag is natuurlijk, wat maak je nu dus open source? Welke technologieën ga je gratis delen? Nou, die technologieën die complementair zijn aan je differentiators. In mijn artikel over mixed-source software schrijf ik hierover:

Open source is in principe geschikt voor complementaire features. Immers, het gemakkelijker en breder beschikbaar komen hiervan is in het belang van de makers van differentiërende features. Zij kunnen dan daarop voortbouwen met hun unieke producten.
Zoals Riehle het zegt:
It’s … in a system integrator’s interest to acquire hardware and software as cheaply as possible. Open source software, if an option, is typically much cheaper than closed source software, hence its use increases profits for the system integrator.
Voor bedrijven als IBM is de dienst de differentiërende feature, en de software complementair daaraan. Met de software bouwen ze immers hun dienst. Dit is dan ook de belangrijkste reden waarom bedrijven als IBM meedoen aan open source (plus natuurlijk het feit dat dit zo’n 12 miljard omzet per kwartaal oplevert). Immers:
Large system integrators, or solution providers, stand to gain the most from open source software because they increase profits through direct cost savings and the ability to reach more customers through improved pricing flexibility. Every dollar a system integrator saves on license costs paid to a software firm is a dollar gained that the customer might spend on services.
En gezien IBM’s uit services

Maar met de tweede reden die Riehle noemt, ben ik het niet eens:

Only community open source software prevents vendor lock-in. … Community open source ensures that prices for software support are subject to market forces rather than one owning corporation. Community open source is a strategic weapon for system integrators to squeeze out proprietary as well as commercial open source software vendors.

Dit is wel waar, maar vanuit het perspectief van die vendor is dit natuurlijk irrelevant. Die zit juist met klanten die lock-in willen voorkomen. Die eisen dus dat alle copyrights op de oplossing naar hen moeten worden overgedragen. Dan kunnen ze naar een andere leverancier. De leverancier wil die natuurlijk niet afgeven, want dan kunnen ze de oplossing niet bij de volgende klant hergebruiken.

Het unieke van IBM is dat zij als enige kunnen zeggen “Dat zouden we graag doen, maar ja het is allemaal open source.”

Hoe dan ook, het moge duidelijk zijn dat deze aanpak de software-industrie zal veranderen. Software-bedrijven moeten niet meer proberen de volgende Microsoft te worden, zoals Bruce Perens al in 2005 bepleitte. Riehle voorspelt een verschuiving van pure software-ontwikkeling naar diensten bovenop open source, met als bijkomstigheid een emancipatie van de programmeur:

Open source software has enabled large system integrators to increase their profits through cost savings and reach more customers due to flexible pricing. This has upset existing ecosystems and shuffled structural relationships, resulting in the emergence of firms providing consulting services to open source projects. This new breed of service firm in turn lives or dies by its ability to recruit and retain appropriate talent.

For such talent, in particular for software developers, life has become more difficult and exciting at once. Developers face new career prospects and paths, since their formal position in an open source project, in addition to their experience and capabilities, determines their value to an employer. Economically rational developers strive to become committers to high-profile open source projects to further their careers, which in turn generates more recognition, independence, and job security.

Maar wat zal dit betekenen voor de secundaire software-sector, de embedded software-gebruikers? Iets voor een volgende keer.

Arnoud

Nieuw op Iusmentis: Mixen van open en gesloten software (Nederlandse versie)

Na bijna acht maanden toch de Nederlandse vertaling van mijn artikel uit Intellectual Asset Magazine over mixed-source software ontwikkeling: het combineren van gesloten en open source software.

Veel firma’s gaan op een ad-hoc manier om met open source: een programmeur heeft een stukje code nodig om een deadline te halen, men komt toevallig iets tegen op internet, of een leverancier meldt en passant dat gebruik is gemaakt van open source. Als er wel beleid over open source is, komt dat meestal neer op “niet toegestaan, tenzij”. Het meer structureel en pro-actief gebruikmaken van open source voor bepaalde onderdelen van producten kan grote voordelen opleveren.

Regels over open source moeten niet gericht zijn op het verbieden daarvan, maar moeten onderdeel zijn van de strategie waarmee het bedrijf effectief gebruik van open source maakt. Cruciaal hierbij is een positieve houding van de bedrijfsjuristen en IP-specialisten, en natuurlijk voldoende kennis van software-ontwikkeling om een zinvolle bijdrage aan het ontwerp te kunnen leveren.

De open source strategie bestaat uit drie stappen. Allereerst moet bij elk product duidelijk zijn welke features differentiërend, baseline of commodity zijn. De volgende stap is op basis hiervan beslissen waar open source gebruikt gaat worden. En als derde stap moeten naast de technische ook de juridische ontwerpbeslissingen worden gemaakt, zodat het systeem op de juiste manier kan worden ontworpen. Het ABISS voorbeeld hierboven laat zien dat een goede samenwerking tussen de ontwikkelaars en de juristen hierbij van groot belang is. Kortom, mix dus niet alleen open en gesloten software, maar ook ontwikkelaars en juristen.

Mixen van open en gesloten software (in Programma’s > Open source software @ iusmentis.com).

Hierop voortbordurend is mijn Innoveren met open source.

Arnoud

Innoveren met open source

Innovatie is tegenwoordig zo complex dat niemand dat meer in zijn eentje kan doen. Samenwerking en open innovatie zijn cruciaal om te kunnen blijven innoveren. Door eigen innovaties te combineren met die van anderen, blijven bedrijven in staat om nieuwe producten te creëren en naar de markt te brengen.

Maar innovaties vertalen naar een product vereist meer dan dat. Een innovatie is een feature, een aspect, een onderdeel van een product. Een moderne televisie bevat meer dan 600 uitvindingen bijvoorbeeld. Sommige daarvan zijn innoverend: Ambilight, 100 Hertz, verbetering van de beeldkwaliteit. Andere zijn al oud: teletekst, automatische zenderselectie, stereo geluid. En dat zijn er nog maar zes van de zeshonderd.

Die overige 594 bij elkaar harken is nog een flinke klus. Die technologieën beschouwen we allang niet meer innoverend of differentiërend. Die wil je dus graag zo goedkoop mogelijk ergens inkopen, en het maakt niet zo veel uit bij wie. Zolang het maar gewoon werkt. Hoe krijg je dat nu voor elkaar?

Er is gelukkig een categorie software die a) gewoon werkt en b) overal beschikbaar is. Open source. Ik ben er dan ook heilig van overtuigd dat open source gebruiken een essentieel aspect is van innoveren. Zie bijvoorbeeld mijn artikel Mixed-source software development.

Het boek Innovation Happens Elsewhere was dan ook een zeer positieve verrassing. Niet alleen legt het helder uit wat open source is en hoe open source projecten werken, maar het benadert open source vanuit het innovatie-perspectief.

Uitgaande van de observatie dat open innovatie de toekomst heeft, komen ze tot de conclusie dat:

To succeed, companies need to find ways to use outside innovations and to become part of a distributed fabric of innovation through a combination of licensing and well-chosen gifts. Although the concept of a gift may not at first seem to fit well with free-market capitalism, it might when thought of in the context of collaborating with others to build common commodity-like infrastructure. If it makes business sense in that context, then perhaps it makes business sense in others.
Dit verklaart meteen de titel: innovatie gebeurt elders. Dat kun je ontkennen (maar dan ga je failliet) of je kunt er gebruik van maken.

Open innovatie gaat niet alleen maar om het aan- of verkopen van innovaties, maar ook om het gratis delen daarvan. En open source is een zeer geschikt middel om innovaties te delen. Door de licentievorm wordt iedereen geacht netjes samen te werken en verbeteringen te delen.

Natuurlijk zijn er meer mensen die pleiten voor het gebruik van open source. Zie bijvoorbeeld An Open Source Strategy for the Open Group, A Guide to Developing an Enterprise Open Source Strategy of Open Source as a Business Strategy. Dit is alleen het eerste boek dat ik ken dat de strategisch inzet van open source bespreekt.

Companies that develop software can use open source as a basis for sharing tools, technology, and prototypes, and communities can be built around open-source projects.

There are many advantages to using open source, but being able to engage the Innovation Happens Elsewhere strategy is especially compelling. Not only does it build the market size, but the tactics to make it work help companies that use it get to better products faster by directly involving the customer base in their design. Through direct conversations with customers, there is reduced guesswork in gathering market requirements. Moreover, there are some operational efficiencies to be gained through better testing, community-based support, and some significant product contributions.

De grote vraag is natuurlijk welke innovaties je volgens deze strategie voor jezelf houdt, welke je in- of verkoopt en bij welke je open source gebruikt. Dat is iets voor een volgend artikel.

UPDATE: deze post is verwerkt in het artikel Open innovatie vraagt om open source dat ik op Sync heb gepubliceerd.

Arnoud