So this discusses the most important legal and relationship questions each startup entrepreneur and founder will need to concentrate on. Preferably sooner than later, in order to move focus forward (instead of the present or the past).

@osma triggered this:

Thanks for all the congrats! This is where the work starts.. cc @metrify @pyryis @KristoOvaska @triekki (@osma, Sat 12 May 13:40)

Based on this and some earlier tweets I assumed the Metrify founders (Kristo Ovaska – @KristoOvaska, Osma Ahvenlampi – @osma, Tuomo Riekki – @triekki, Pyry Åvist – @pyryis) had signed a shareholders agreement (often referred to as a SHA), possibly transferred existing assets to their company, perhaps also formally founded the company. So:

Good to get incentives formalised, clear. Drives work! RT @osma Thanks for all the congrats! Work starts… cc @metrify @pyryis @KristoOvaska (@mvonwillebrand, Sat 12 May 16:21)

@mvonwillebrand yes indeed! Get the home base in shape before the real attack! cc @osma @metrify @pyryis @triekki (@KristoOvaska, Sat May 17:15)

Exactly! RT @KristoOvaska @mvonwillebrand yes indeed! Get the home base in shape before the real attack! cc @osma @metrify @pyryis @triekki (@mvonwillebrand, Sat 12 May 17:33)

“Get the home base in shape before the real attack!” – That’s the whole point. But it begs the question what is the right moment to do so. So:

Startups: One trap for beginning entrepreneurs is to fail in agreeing early, clearly what the incentives, ownership %s are. Slows down… (@mvonwillebrand, Sat 12 May 16:26)

Startups: early incentives for founders are mostly based on ownership %s of a company, so founding formally helps. (@mvonwillebrand, Sat 12 May 16:26 – 16:29)

Startups: then again, its some paperwork. When balancing when to formally found, remember the point on incentive clarity. (@mvonwillebrand, Sat 12 May 16:30)

So the key point here is: founders should agree early on who owns and how much. I have seen many times a startup or development project linger on and on without clear focus. Perhaps a portion of the Finnish nature makes it difficult to speak about money and ownership. But leaving the question on ownership open will slow down your team. Team members’ focus will be distracted by “is this actually my project or his/hers?”.

So with my first point made in a couple of tweets, I was warming up:

Startups: also, all important assets need to be placed in the company, for clarity. And two more important things… #aaltoes (@mvonwillebrand, Sat 12 May 16:32)

Startups: when founding, agree on amounts of work each of the founders are committed to, during the, say, next 6-12 months. #aaltoes (@mvonwillebrand, Sat 12 May 16:33)

Assets? Many times startups have started exploring or operating already prior to formal founding. This means there are rights to the name, domain names, presentations, videos, code, business model proposal documents, client contacts etc. All of these should be transferred to the company. If there are inventions, normally these should also be transferred to the jointly owned company, rather than having some assets remain in the personal name of one founder. The startup could also have some money, or, if not, it is probably in need of money. Founding will require someone to put money into the company too.

The other aspect is work commitments. While bootstrapping with a group of founders it is important to balance the expectations between all founders: will all of us work 100% on this startup, or less, or will someone work full time whereas someone’s role is more like an advisor?

This is clearly legal already, but I have more serious stuff coming:

Startups: And final very important thing: agree what will happen, if one of the founders leaves (share redemption, vesting) #aaltoes (@mvonwillebrand, Sat 12 May 16:35)

Yes, my gut experience says that this will happen to most startups, not just 1 in 5. During the very first years, one of the founders will probably leave. It isn’t odd, there’s nothing wrong in it and it’s just life. But if you aren’t prepared, you have a crisis in the foundation:

Startups: It’s quite usual that founders will change in the first 6-24 months. Need to prepare, otherwise crisis may loom. (@mvonwillebrand, Sat 12 May 16:36)

Startups: It’s difficult, almost impossible to bootstrap, if, say, 1/3 of shares are held by ex-founder,who nowdays works elsewhere #aaltoes (@mvonwillebrand, Sat 12 May 16:38)

@mvonwillebrand Maybe the startup vesting mistakes cannot be taught? Everyone hits the same issues. (@aukia, Sat 12 May 17:01)

My RT follows: Hear, hear: important issue RT @aukia @mvonwillebrand Maybe the startup vesting mistakes cannot be taught? Everyone hits the same issues. (@mvonwillebrand, Sat 12 May 17:04)

@aukia valid point, not easy to learn, but can be learned. I’ve got examples both ways. It’s not the standard pitching lesson though… (@mvonwillebrand, Sat 12 May 17:13)

But I’m optimistic, can be learned! RT @aukia @mvonwillebrand Maybe the startup vesting mistakes cannot be taught…(@mvonwillebrand, Sat 12 May 17:05)

@aukia, Sat 12 May 17:05: @mvonwillebrand And no-one makes the vesting mistake a second time. (@aukia, Sat 12 May 17:05)

@aukia (Petri Aukia) shares his experience that vesting, leavers and work-amounts (as we’ll learn in a little while) are crucial. I must say, I agree. You need to agree in advance how much shares, how much work, how vesting works and what will happen if one leaves. These are all intertwined and the picture is made complete by juggling all these to a common understanding.

But I think this can be learned. I have collected a couple of examples of what went wrong and some examples in which the team was well prepared. Added with the followin conceptual way of solving this, I believe teams are better off.

Example on Work Commitments and Vesting

Let’s say a startup has three major founders, each with 30% equity share. And two advisors with 5 % shares each. So the straight forward situation is that all of the major founders work equally for the company, whereas the advisors have more of – ahem – an advising role.The bootstrapping agreement could include that each of the 30 % holders agree to put at least 75 % of their time to the company, whereas the advisors could agree to put one day per month.

And, now, if the work amounts are established, we can look at the vesting schemes more intelligently than just bluntly throwing a sheet with four steps at it. Ok, work is difficult to measure and the value of input is difficult to appraise. But let’s not give something up because it’s difficult. Fortunately, the teams normally choose their members due to some reason and some trust in the abilities of the members. So we can look at the work time, and as long as no better measurement is available, that should also be used. So the 30 % founders could agree: vesting in three years, 75 % work commitment during the first year and board to decide on second and third year targets for work amounts. The vesting would occur only in the proportion that the founder has – in the average – achieved the work commitment. If a founder questions the work amounts of another founder, then a simple working time follow-up can be made.

But if the major founders don’t have equal expectations, and nothing clear is agreed as to work commitments, then there is a clear potential for differing expectations for commitment. Vesting alone does not solve this: it must be solved through boot-strapping work commitments combined with vesting.

E.g. in our probono startup program, we discuss good/bad leavers&vesting up with examples, confirmed by a participant (3rd startup for him) (@mvonwillebrand, Sat 12 May 17:08)

Re startup leavers/vesting problem: real life examples, confirmations help startups to learn: one crisis less, better off @aukia But I’m optimistic, can be learned! RT @aukia @mvonwillebrand Maybe the startup vesting mistakes cannot be taught… (@mvonwillebrand, Sat 12 May 17:10)

@mvonwillebrand Vesting issues teach negotiation in real life to the tech team. Not everyone is honest, and words are cheap. (@aukia, Sat 12 May 17:30)

@mvonwillebrand Sounds excellent. Although good/bad leavers create a whole bag of issues. (@aukia, Sat 12 May 17:31)

Our law firm, HH Partners, run a pro bono startup program this winter with 5 startups, helping them to be better prepared (these startups): founding the company and drafting a shareholders agreement. It was a good program in many respects: one was that we had several teams in same meetings and we discussed these challenges. While I was giving my examples, Paavo Perttula from Cute Attack – a participant for whom this was not the first startup – told his experinces. I believe the point was well received.

Also, to support what @aukia mentions regarding teaching negotiation skills: I think it is valuable to go through a shareholder agreement with an expert at the same time you are actually planning to make one. It is good preparation regarding concepts, terminology and – to quote @aukia – real life with a tech team: because agreeing about work commitments and vesting is not just words on a document, it’s about what others expect from you and what you can expect from others.

But this was not the end: the twitterverse brought up another point of view:

@mvonwillebrand @aukia I work with a lot of startups, most seem aware of vesting issues. No doubt thanks to startup communities sharing exp (@oniiranen, Sat 12 May 17:31)

@oniiranen @mvonwillebrand Everyone aware, yet I see similar mistakes over and over again… (@aukia, Sat 12 May 17:36)

@oniiranen @aukia I think there is awareness, but focus tends to distribute between too many issues. 3-4 really important ones. (@mvonwillebrand, Sat 12 May 17:58)

@oniiranen (Ossi Niiranen) brings up the fact that vesting is actually a well known concept. And he is correct. At the same time, I think the vesting concept – that people are aware of – tends to blend into a number of other questions: non-competition, secrecy, contractual penalties, share transfer restrictions, redemption of shares, sale rights, drag-along/tag-along, board positions, veto rights etc. These are all legal concepts, used in a startup and venture capital setting. While none of these is irrelevant (actually many are important), the concepts discussed in the tweets here are the crucial ones, for the beginning and the early team dynamics.

@oniiranen @mvonwillebrand No vesting for founders, excess equity to idea-man, equity to guys working on the side… (@aukia, Sat 12 May 17:38)

Incentives fail: RT @aukia @oniiranen @mvonwillebrand No vesting for founders, excess equity to idea-man,equity to guys working on the side… (@mvonwillebrand, Sat 12 May 21:40)

Re last RT of @aukia: while all situations are unique, the choices in the RT were clearly of the risk increasing type, in central Q:s. (@mvonwillebrand, Sat 12 May 21:44)

That was an interesting observation from @aukia. One risk increasing factor is to have a founder with clearly higher portion. In a startup setting, someone having 50% or more is slightly risky: there could be valid reasons, but it also means that the startup will die or thrive with that person, which in turn means that others are less willing to invest their time and money into such startup. But there are many companies that work well with one majority shareholder. Equity division should also be always proportional to the contributions (in work, money, other assets), otherwise there’s a potential source for demotivation. Small shares to advisors – as long as they are in proportion to contributions – seem to work.

Back to the central questions:

Startups, recap, central Q:s: equity-division; work and asset contributions; leavers and vesting. Clarify early->focus forward #aaltoes (@mvonwillebrand, Sat 12 May 21:49)

The standard shareholder agreement covers, not only these most important questions, but a horde of others:  non-competition, secrecy, contractual penalties, share transfer restrictions, redemption of shares, sale rights, drag-along/tag-along, board positions, veto rights etc. I wonder if the shareholder agreement step is a tad too big, resulting in people pushing it for too long and simultaneously failing in agreeing on the most central questions. Thus, this begs the question:

• Should there be a simpler initial agreement to just cover equity-division (how much everyone owns of the company); work and asset contributions and commitments; leavers and vesting?

Notes on this Blog

As a practical note, I have added some spacing to the tweets and corrected some typos.

I’m a Finnish tech lawyer with wide recommendations. I head the tecnology team at HH Partners. At HH Partners, we work a lot with startups and have acknowledged that startups are not a business for us when they start, but they can be a business if they succeed. So we want to help startups, build the ecosystem and our contacts.

This is my personal blog – see about page.

“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.