“The legal rules often play a key role when it comes to business models in software businesses andnotably in free and open source software projects. This is particularly true when the project owner wants to maintain some level of control over the software and the project itself. The balance between control and freedom is achieved by legal tools and policies, such as licenses, compliance policies,contracts, trademarks, organisation rules, contribution policies, only to name a few.” Full article at Symbio’s site: http://www.symbio.com/techblog/?p=307.

Näkökulma: Artikkelin myytit on valittu ison organisaation ostajan näkökulmasta, joskin myytit ovat tätä yleisempiä.

A. Johdanto

Avoin lähdekoodi tietojärjestelmissä ei ole ihmeellinen tai uusi asia. Avoimen lähdekoodin hyödyntämisessä on kyse ohjelmistoista, siinä missä suljetun lähdekoodin hyödyntämisessäkin.

Avointa lähdekoodia ei tule kohdella kuin jotain erityistä ilmiötä, sitä tulee kohdella ohjelmistoina. Ohjelmistoja on hyviä ja huonoja ja niiden lisensiointi voi olla yritykselle sopivaa tai epäsopivaa. Tämä soveltuu sekä avoimiin että suljettuihin ohjelmistoihin. Yrityksen tulee katsoa yksittäisiä ohjelmistoja ja niiden soveltuvuutta yrityksen tarkoituksiin. Yrityksen ei yleensä ole järkevää lukittautua yhteen ohjelmistoon tai yhteen lisensiointimalliin.

Ohjelmistoja tulee arvioida samoin kriteerein, olivat ne avoimia tai suljettuja. Arvioinnissa ohjelmiston avoimuus on käyttäjäyritykselle käytännössä aina vain etu, sillä avoimen ohjelmiston arviointi on helpompaa ja lisenssien myöntämä käyttämis-, muuttamis- ja monistamisvapaus on etu.

Lähtökohtaisesti avoimen lähdekoodin arviointiprosessit voisivat olla samoja kuin suljettujen ohjelmistojen arviointiprosessit. Kuitenkin avointa lähdekoodia voidaan hankkia ja käyttää huomattavasti enemmän ja joustavammin kuin erikseen ostettavia suljettuja osia: näin arviointitilanteiden lukumäärä kasvaa. Lisäksi avoimen lähdekoodin arviointiprosesseissa on tiettyjä samankaltaisuuksia silloin, kun kyseessä on avoin lähdekoodi (mm. yleisesti käytettyjä lisenssejä, lähdekoodi saatavilla, kehitysprojekti tutkittavissa jne.). Tämän johdosta voi olla tehokkaampaa luoda erillinen prosessi avoimen lähdekoodin (tai internetistä ladattavien ohjelmien) arviointia ja hyväksyntää varten.

B. Totuudet ja niihin liittyvät myytit

1. myytti: Avoimen lähdekoodin ohjelmistoja ei tueta
2. myytti: Avoin lähdekoodi tarttuu tietojärjestelmiin
3. myytti: Tehdyt muokkaukset pitää julkaista
4. myytti: Suljetut järjestelmät pitää julkaista, jos käyttää avointa lähdekoodia
5. myytti: Freeware ja shareware ovat avointa lähdekoodia
6. myytti: Avoimen lähdekoodin lisensiointi on sekavaa ja aiheuttaa riskejä
7. myytti: Julkaisemalla open sourcea luopuu tekijänoikeudestaan ja patenttioikeuksistaan
8. myytti: Open Source on tietoturvatonta
9. myytti: Isot yritykset eivät käytä open sourcea
10. myytti: Julkisena hankintana ei voi hankkia avointa lähdekoodia

1. Myytti: Avoimen lähdekoodin ohjelmistoja ei tueta

Totuus 1: Tukea on saatavilla monipuolisesti avoimelle lähdekoodille, mutta ei jokaiselle internetistä ladattavalle ohjelmalle (oli lisensiointi suljettua tai avointa). Tuki vaatii työtä (joko omaa tai toisen) ja työ maksaa.

Laajasti käytettyjen avoimen lähdekoodin projektien osalta tuki on varsin monipuolista. Saatavilla voi olla:

-         maksullista tukea projektia ylläpitävältä organisaatiolta,

-         maksullista tukea paikalliselta ja muilta organisaatiolta,

-         maksullista koulutusta ja opastusta,

-         julkisia käyttäjäkokemuksia ja ratkaisuja käyttäjien ongelmiin (maksuton),

-         julkisia resursseja tikettien raportointiin ja seurantaan (maksuton),

-         dokumentaatiota: niin maksullista kuin maksutonta ja

-         vaikutusmahdollisuuksia.

Monipuolisuus mahdollistaa sekä hankitun tuen, että itse tuotettavan tuen. Se, että käyttäjäorganisaatio, voi tuottaa tukea myös omatoimisesti, ei ole heikkous vaan vahvuus.

Toisaalta tietyn ohjelmiston tukimahdollisuudet tulee selvittää ohjelmistokohtaisesti. Löytyy paljon ohjelmistoa – niin suljettuja kuin avoimia – joiden tukikäytännöt eivät vastaa käyttäjäorganisaation toiveita.

2. Myytti: Avoin lähdekoodi tarttuu tietojärjestelmiin

Totuus 2: Mitään tarttumista ei ole olemassa. Kyse on väärinkäsityksestä ja itse asiassa moninkertaisesta väärinkäsityksestä. Väärinkäsitys on lähtenyt liikkeelle Microsoftin Steve Ballmerin haastattelulausunnosta Chicago Sun-Timesille vuonna 2001.

Ballmer on lausunnossa kuvannut avointa lähdekoodia syöväksi, joka tarttuu ja siirtyy yrityksen tietojärjestelmään. Joskus on myös käytetty niin ikään virheellistä termiä ”virusvaikutus”.

Ensinnäkin ajatuksen taustalla oleva vastavuoroisuus on ymmärretty väärin. Vastavuoroisuudella tarkoitetaan sitä, että jos ohjelman haluaa luovuttaa edelleen muokattuna, tulee omat muokkaukset antaa vastaanottajalle samalla lisenssillä kuin ohjelma on tullut. Jos tätä ehtoa ei noudata, ei ole oikeutta levittää alkuperäistä ohjelmaa. Noudattamatta jättämisen seurauksena on mm. tekijänoikeusloukkaus, mutta ei mitään tarttumista (tai automaattista lisenssin tarttumista yrityksen tekijänoikeuden alaiseen ohjelmaan).

Toiseksi vastavuoroisuusvelvollisuus koskee vain tiettyjä lisenssejä, ei avointa lähdekoodia yleisesti (GPLv2 on yleisin esimerkki lisenssistä, joka sisältää vastavuoroisuusvelvollisuuden).

Kolmanneksi vastavuoroisuusvelvollisuus ei kosketa lainkaan oman organisaation sisäistä käyttöä tai kopiointia organisaation sisällä. Palvelun tarjoamista vastavuoroisuusvelvollisuus ei myöskään kosketa, paitsi erikoistapauksissa (esim. Affero GPL).

Neljänneksi vastavuoroisuusvelvollisuutta pitää noudattaa silloin, kun ohjelmaa levittää. Noudattamatta jättämisen seuraus on se, että alkuperäistä (esim. GPLv2-lisenssin alaista) ohjelmaa ei saa levittää. Mikäli silti levittää, on seurauksena tavanomaiset seuraukset, kuten hyvitysmaksuvelvollisuus tekijänoikeuden loukkauksesta.

3. Myytti: Tehdyt muokkaukset pitää julkaista

Totuus 3: Tämäkin on väärinkäsitys. Mikään tunnettu avoimen lähdekoodin lisenssi ei sisällä julkaisuvelvollisuutta. Joidenkin lisenssien mukaan niiden alaisen ohjelmiston lähdekoodi tulee pitää lisenssinsaajan saatavilla eli sen saatavilla, jolle yritys avoimen lähdekoodin ohjelmiston luovuttaa. Toisin sanoen ei ole velvollisuutta luovuttaa lähdekoodia kenelle tahansa, yleisölle, eikä edes alkuperäiselle projektille.

Lisäksi kannattaa huomioida, että lähdekoodin luovutusvelvollisuus koskee vain tiettyjä avoimen lähdekoodin lisenssejä ja aina vain sitä ohjelmistoa, jota kyseinen lisenssi koskee. Lähdekoodin luovutusvelvollisuus ei siis koske yrityksen jollain muulla lisenssillä julkaiseman ohjelmiston lähdekoodia. Lähdekoodin luovutusvelvollisuus koskettaa myös vain levitystilanteita, ei koskaan yrityksen sisäisiä käyttötilanteita.

4. Myytti: Suljetut järjestelmät pitää julkaista, jos käyttää avointa lähdekoodia

Totuus 4: Tämä on yhdistelmä myyttejä 2 ja 3. Kuvitellaan, että lisenssit hyppivät ohjelmistosta toisiin itsestään ja niiden mukaan pitäisi lähdekoodeja julkistaa. Myytit 2 ja 3 kumottiin edellä, joten tämäkin on kumottu.

5. Myytti: Freeware ja shareware ovat avointa lähdekoodia

Totuus 5: Kaikki internetistä ladattavat ohjelmistot eivät ole avointa lähdekoodia. Freeware nimitystä käytetään lisenssimaksuttomasta, mutta suljetusta ohjelmistosta. Shareware on freewarea, josta on esimerkiksi poistettu joitakin toiminnallisuuksia käytöstä tai rajoitettu käyttö testiperiodiin. Toiminnallisuudet saa käyttöön maksamalla lisenssimaksun tai vastaavan.

6. Myytti: Avoimen lähdekoodin lisensiointi on sekavaa ja aiheuttaa riskejä

Totuus 6: Lisensiointia on monen tasoista. Toiset ovat esimerkillisiä (esim. Apache Software Foundationin projektit) ja toiset vaihtelevan tasoisia. Kuitenkin lisensiointi on yleisesti arvioiden helposti selvitettävissä, joskin se vaatii hiukan työtä. Jos hiukan kiinnittää huomiota lisensiointiin, riskit ovat varsin pienet, jopa täysin minimaaliset.

Loppukäyttäjän näkökulmasta on myös hyvä todeta, että teoreettiset riskitkin koskevat käytännössä vain levittäjiä, ei ohjelmiston käyttäjiä.

Asiaa voidaan arvioida muutamalla eri tavalla:

-         Monet avoimen lähdekoodin projektit käyttävät tunnettuja lisenssejä ja niiden lukemiseen ei sen takia kulu juurikaan aikaa. Suljetut projektit käyttävät järjestään projekti-spesifejä lisenssejä, jotka ovat pahimmillaan monikymmensivuisia.

-         Kaikki avoimen lähdekoodin projektit eivät ole kertoneet lisensioinnista parhaalla mahdollisella tavalla. Tätä varten pitää tehdä jonkinasteista selvittelytyötä. Tätä varten on olemassa hyviä työkaluja (avoimen lähdekoodin, erityisesti Fossology[1]) ja lisää syntyy koko ajan. Myös palveluita on tarjolla.[2] Erityisesti nämä työkalut ja palvelut auttavat levittäjiä; loppukäyttäjät tarvitsevat näitä yleensä vasta, kun he alkavatkin levittää toisille organisaatioille avoimen lähdekoodin ohjelmistoja. Suljetuissa projekteissa samoja kysymyksiä ei yleensä voida selvitellä.

-         Suomessa on vuosittain useita it-projektiriitoja, mutta tiedossa ei ole yhtään avoimeen lähdekoodiin kohdistunutta riitaa. Maailmanlaajuisesti tuomioistuimen päätökseen on päätynyt noin kymmenen oikeustapausta. Näissä vastaajina on lähes aina ollut laitevalmistaja. Määrä on minimaalinen it-projektien lukumäärään verrattuna.

-         Avoimen lähdekoodin piirissä toimivat yhteisöt suosittelevat julkisuudelta piilossa tapahtuvaa yhteistoimintaa yritysten kanssa asioiden selvittämiseksi.[3]

7. Myytti: Julkaisemalla avointa lähdekoodia luopuu tekijänoikeudestaan ja patenttioikeuksistaan

Totuus 7: Avoimen lähdekoodin lisensiointi perustuu tekijänoikeuden pidättämiseen ja sitten lisenssin myöntämiseen. Tekijänoikeudenhaltijalla on valta päättää lisensioinnista ja halutessaan myös muuttaa lisensiointia tulevissa julkaisuissaan. Tekijänoikeudenhaltija antaa lisenssissä päättämänsä oikeudet. Niiden mukana voi olla patentteja koskevia oikeuksia.

Ajoittain esitetään käsityksiä, että avoin lähdekoodi olisi jotenkin vierasta markkinataloudelle tai että se rikkoisi sen perustavia lainalaisuuksia. Nämä perustuvat immateriaalioikeuksien väärinymmärrykseen ja avoimen lähdekoodin projektien toimintalogiikan huonoon tuntemukseen.

Projekteissa tekijänoikeudella ja siihen liittyvillä projektin toimintaperiaatteilla on keskeinen merkitys. Nämä vaikuttavat päätöksentekoon projektissa ja yhteisön dynamiikkaan. Yritys, joka perustaa avoimen lähdekoodin projektin, voi itse valita toimintatapansa. Tekijänoikeuden, projektin tavaramerkin ja verkkotunnuksen haltijan rooli on keskeinen, sillä näillä on valta päättää projektin sisällöstä (mitä julkaistaan) sekä lisenssistä. Nämä voivat myös päättää muutoksista. Yleensä päätöksentekovallan pidättäminen vaikuttaa yhteisön dynamiikkaan toimeliaisuutta vähentävästi.

Mikäli yritys osallistuu jo olemassa olevaan projektiin, on ratkaisevaa projektin käytännöt erilaisten kontribuutioiden käsittelemisestä.

8. Myytti: Avoin lähdekoodi on tietoturvatonta

Totuus 8: ”Avoin lähdekoodi” ei ole tietoturvamielessä oikea arvioinnin kohde. Oikea arvioinnin kohde on tietty ohjelmisto. Ohjelmistojen tietoturvataso (oli ohjelmisto avointa tai suljettua) vaihtelee.

Avoimen lähdekoodin ohjelmistojen osalta kuka tahansa voi tutkia ohjelmiston toimintaperiaatetta ja mahdollisia tietoturvaheikkouksia. Tämä nähdään yleensä yksinomaan etuna, koska tietoturvalliseksi ratkaisuksi mielletään ratkaisut, joiden tietoturva perustuu julkisiin tietoturvakäytäntöihin. Ratkaisut, joiden tietoturva perustuu siihen, että aukkoja on hankalampi löytää suljetun koodin vuoksi, mielletään yleensä haavoittuvaisemmiksi. Yksittäistilanteissa tämä voi olla toisinkin.

Kuitenkin laajasti käytetyillä avoimen lähdekoodin ohjelmistoilla on se etu, että monet ovat voineet tutkia käytettyjä tietoturvaratkaisuja detaljoidusti. Julkisuus tukee myös löydettyjen haavoittuvuuksien nopeaa paikkaamista.

9. Myytti: Isot yritykset eivät käytä open sourcea

Totuus 9: Isot yritykset käyttävät avointa lähdekoodia erittäin paljon ja koko ajan vain enemmän.

-         Hewlett-Packard raportoi jo vuonna 2003 saavansa 2,5 miljardia (USD) Linux-liitännäistä liikevaihtoa

-         Red Hat:in (Red Hat Linux-jakelun ylläpitäjä) liikevaihto oli keväällä 2010 päättyneellä tilikaudella noin 800 miljoonaa (USD)

-         Forrester raportoi 2009, että 23 % eurooppalaisista ja amerikkalaisista yrityksistä ilmoitti, että eivät käytä avointa lähdekoodia[4] –> eli 77 % oli sitä mieltä, että käyttävät

-         Oikeusministeriö ja sen hallinnonala otti käyttöön Open Officen noin 10.000 työaseman organisaatiossa.

-         Maailmanlaajuisesti ison toimittajan ilmailuelektroniikkajärjestelmät ovat vuonna 2010 avointa lähdekoodia (lähdettä ei paljasteta)

-         Accenture (elokuu, 2010): 38 % haastatelluista isoista yrityksistä (yli 500 miljoonaa USD/vuosi) aikoo siirtää toimintakriittisiä järjestelmiä avoimeen lähdekoodiin.[5]

10. Myytti: Julkisena hankintana ei voi hankkia avointa lähdekoodia

Totuus 10: Avoimen lähdekoodin hankinta julkisena hankintana on mahdollista ja tarjouspyynnössä voidaan myös vaatia toimitettavaksi vain avoimen lähdekoodin ohjelmistoja.

Mahdollisuus vaatia avointa lähdekoodia perustuu siihen, että avoin lähdekoodi käsitteenä ei ole ohjelmisto, brändi tai toimittaja, vaan kyseessä on vain yleinen kuvaustapa ohjelmistoa koskevan lisenssin tietyistä ominaisuuksista. Käsitteen alla olevia ohjelmistoja ja brändejä on lukuisia ja toimittajia on useita. Jos kunta haluaa voida käyttää hankkimaansa ohjelmistoa vapaasti ja muuttaa sitä ja tarvittaessa jakaa sitä, se voi tällaisen vaatimuksen esittää. Vaatimuksen voi nimittää avoimeksi lähdekoodiksi, mutta on selvempää kirjoittaa se auki.

Hankintayksikkö voisi myös vaatia hankinnassa tekijänoikeuksia itselleen (ei yleensä järkevää), joten laaja lisensiointi – esim. avoin – on tästäkin näkökulmasta mahdollinen vaatimus.

Julkisissa hankinnoissa tulee noudattaa tasapuolisuuden ja syrjimättömyyden vaatimusta. Tämä tarkoittaa muun muassa sitä, että hankintaa ei yleensä tule määritellä niin, että on vain yksi mahdollinen toimittaja.

Sen sijaan tarjouspyynnössä ei yleensä voi vaatia Ubuntua ja Zentyalia (brändiä). Sen sijaan voisi hankkia sähköpostijärjestelmän, jota on oikeus käyttää vapaasti, muokata ja levittää edelleen. Vaatimus voi olla myös Microsoft-yhteensopiva sähköpostijärjestelmä (tai Zentyal-yhteensopiva).

Hankintayksikkö voi vaatia tietojärjestelmältään vapaata käytettävyyttä, muutettavuutta ja edelleen levitettävyyttä. Vain erikoistapauksissa – esimerkiksi jos vain yksi toimittaja pystyisi tällaisen toimittamaan – voisi tällainen muodostua syrjiväksi.

Oikeudellisesta kysymyksestä kokonaan erillinen kysymys on käytännöllinen kysymys siitä, miten joku tietty hankinta kokonaisuutena kannattaa toteuttaa. Tähän kysymykseen vaikuttavat tarjonta markkinoilla ja tietojärjestelmien elinkaarikustannukset.

Mikäli avoimen lähdekoodin toimittajia ei ole, ei ehkä kannata vaatia avointa lähdekoodia. Tämä tilanne kuitenkin on kokonaan loppumassa. Toisaalta, ostajan ja ostajien etu voi usein olla viedä markkinoita avoimen lähdekoodin suuntaan.

Elinkaarikustannusta koskeva analyysi on ohjelmisto tai ratkaisukohtainen ja siinä ohjelmiston lisensiointitapa – avoin tai jonkinlainen suljettu – on vain mauste. Lisensiointi ei ratkaise elinkaarikustannusta suuntaan tai toiseen, joskin avoimuus on vaikkapa muuten yhtäläisten järjestelmien tilanteessa ostajan kannalta sekä käytännöllinen että strateginen etu.

JHS 169-suositus

JHS 169-suosituksen, kohta 6.4, mukaan[6] (Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa):

”Jos ”monistettavuuden” vaatimus tai arviointiperuste esitetään tarjouspyynnössä, se tulee esittää yleisellä tasolla viittaamatta tiettyihin ohjelmistolisensseihin. Näin vertailu on tasapuolinen sekä perinteisten suljettujen että avoimen lähdekoodin ratkaisujen tarjoajille.”

JHS:n mukaan suositeltava muotoilu tarjouspyynnössä on esimerkiksi: ”Tilaajalla on oikeus muokata ohjelmistoa tarkoituksiinsa sopivaksi ja niin halutessaan jakaa ohjelmistoa lähdekoodeineen eteenpäin kolmansille osapuolille ilman rojalteja tai muita maksuja.”

JHS-suosituksessa (kohta 6.6) myös esitetään vaihtoehdot ohjelmiston hankkimiseen avoimen lähdekoodin lisenssillä. Vaihtoehtoina on 1) määritellä hankittavan ohjelmiston lisensiointi avoimen lähdekoodin periaatteilla (periaatteet kuvaten), 2) määritellä hankintayksikölle määräysvalta lisensioinnista päättämiseen ja 3) hankkia ohjelmisto tekijänoikeuksineen.

EU:n avoimen lähdekoodin hankintaopas

EU:n komission IDABC on teettänyt ohjeistuksen avoimen lähdekoodin julkisia hankintoja varten[7]. Kyseessä ei ole komission virallinen kannanotto.

Avoimen lähdekoodin hankintaopas on sisällöllisesti samoilla linjoilla kuin JHS 169-suositus. Tarjouspyynnössä avoin lähdekoodi voi olla vaatimuksena, joskaan se ei sellaisenaan takaa kilpailutuksen tasapuolisuutta. Tarjoajien rajaaminen eri tavoilla voi myös muodostua syrjiväksi.

IDABC:n hankintaopas kuvaa myös mahdollisuutta käyttää avoimuutta pisteytyksessä siten, että avoin lisensiointi on tarjoajille etu.

Martin von Willebrand
Asianajotoimisto HH Partners Oy, osakas
www.hhpartners.fi

An already overcome example of a challenge is the question on SLAs: today one can purchase service level agreements at different levels, whereas a couple of years ago this was much less available. Today, it is difficult to get a service provider to (even against payment) give some guarantee on data preservation or backups. I think we can expect the services to develop to cover this, e.g. against extra payment.

Addition on 30 December 2010: Bradshaw, Simon, Millard, Christopher and Walden, Ian have made a great and detailed comparison of over 50 or so cloud service contracts and their terms.

Addition on 12 January 2011: Dennis van der Heijden has set up a good comparison on pricing practices covering 317 cloud service providers.

I’m linking some here, for my own and others’ reference.

As always, Carlo Daffara continues writing on and analysing open source business models and comments the recent open core debate. His basic point is that control on code is a tradeoff against contributions.

Simon Phipps heated up the debate with a post on down-sides of open core. Comments from many (in Simon’s blog there were also comments by Mårten Mickos and Henrik Ingo):

- Mark Radcliffe, not agreeing and arguing that open core should not be demonized, and it serves a purpose for the FOSS community,

- Mårten Mickos, although agreeing to some points, basically sees open core as a necessary tool,

- Carlo Daffara, restating that open core strategy trades off contributions and thus requires more development expenditure or the like.

These deserve some thinking. A business needs value to be traded, but how can and should the value be optimised? That will depend on the type of software/service, and every business experimenting with these is welcomed by me at least.

It all comes down to the value offered: as long as a business is able to leverage more value than other relevant vendors, it will thrive. The value offered can be e.g. service for it-departments, software license, cloud service for users, or an existing user base (e.g. Facebook).

The other side of the coin is the cost to keep the business up and running, developing with innovation. Here the community becomes relevant, as does the ease of contribution, and the existing user-base.

I also describe the methodology of Validos, although my and Mikko-Pekka Partanen’s recent article in IFOSSLR is significantly more thorough (and longer) and in English. The recent article is titled Package Review as a Part of Free and Open Source Software Compliance.

IPRinfo is a magazine published by IPR University Center -  a department for IPR studies of a number of Finnish universities.

IPRinfo is a magazine published by IPR University Center -  a department for IPR studies of a number of Finnish universities.

1. Again, Andrew Katz writes a very pleasant to read book review. And this time, I need to get the book, too.

2. Andrew Sinclair writes a short article on BSD-license, tying the loose ends up. And I agree to the community view on BSD licenses permissions on modifying, reproducing and even sublicensing: it is there and Andrew just made it an IFOSSLR tad stronger.

Although there is a clear consensus that reproducing a work is permitted under BSD licenses, I have also been thinking that in the language of the BSD, “distribution” of software could be considered to include reproduction and distribution.

There is an interesting thread on GPL-compatibility, although Andrew could perhaps write a couple of paragraphs more on this.

3. Then there is my and Mikko-Pekka Partanen’s article on practical FOSS package compliance. I’m excited about the article and our work with Validos. I hope the article serves its purpose: takes a step towards a consensus on practical compliance conclusions. It was really an effort to get it finished in time for the publication, but we did it; and not least thanks to quick peer reviewers.

Then there is a number of other writings articles, but I haven’t had the time to read them yet…

Due to my blog on the Paris GPL case, I was actually asked to write a case law report to IFOSSLR. It was also published now.

I had the chance to read in advance Richard Kemp’s article Towards Free/Libre Open Source Software (“FLOSS”) Governance in the Organisation and heartily recommend it due to its building block approach and many examples.

I also just finished reading Andrew Katz’ book review on Law and the Internet and it surely was professional, but it was also entertaining!

Glad to see the publication flourishg: I and Mikko-Pekka Partanen are proposing a new article on open source compliance and the practical legal conclusions used in reviewing packages and source code and their license compliance. This is based on our work with Validos and has also a purpose to make public (and therefore subject to criticism and improvement) the compliance methodology used by Validos.

My slides in English.

It was a great event, a lot of people from abroad and Finland. Ebox (Ignacio Correas), eCars.now (Henry Palonen), Tampere city (Teppo Sulonen) and Maemo Community, N900 (Quim Gil) are the ones I remember best. I sadly missed Peter Chengs presentation.