Når jeg skriver «fri programvare-lisenser» tenker jeg nå hovedsaklig på GNU GPL og andre restriktive lisenser. Noen mener at GPL er en trussel mot innovasjon og utvikling i programvarebransjen, og det er da spesielt GPL som får kritikk.
Kritikernes syn på fri programvare
Steve Ballmer svarer følgende på spørsmålet om han synes Linux og fri programvare er en trussel mot Microsoft1:
Do you view Linux and the open-source movement as a threat to Microsoft?
Yeah. It’s good competition. It will force us to be innovative. It will force us to justify the prices and value that we deliver. And that’s only healthy. The only thing we have a problem with is when the government funds open-source work. Government funding should be for work that is available to everybody. Open source is not available to commercial companies. The way the license is written, if you use any open-source software, you have to make the rest of your software open source. If the government wants to put something in the public domain, it should. Linux is not in the public domain. Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That’s the way that the license works.
Craig Mundie er inne på noe av det samme som Ballmer2:
The GPL asserts that any product derived from source code licensed under it becomes subject to the GPL itself. When the resulting software product is distributed, the creator must make all of the source code available, at no additional charge. This effectively makes it impossible for commercial software companies to include source code that is licensed under the GPL into their products, since by doing so, they are constrained to give away the fruits of their labor. As we think about technology, IP rights, and the public sector of knowledge, we need an intellectual model that encourages interaction, not a model that drives them apart.
(…) But as history has shown, while this type of model may have a place, it isnt successful in building a mass market and making powerful, easy-to-use software broadly accessible to consumers.
In contrast, two decades of experience have shown that an economic model that protects intellectual property and a business model that recoups research and development costs have shown repeatedly that they can create impressive economic benefits and distribute them very broadly.
De hevder her at programvare som er lisensiert som fri programvare ikke kan benyttes av kommersielle selskaper, ettersom de da må slippe resten av programvaren under samme lisens. Det er en sannhet med modifikasjoner, som du kan lese mer om nedenfor.
Mundie sier også at han vil ha en modell som motiverer til interaksjon. Jeg kan ikke tenke meg noe som har motivert meg mer til å bidra enn fri programvare-miljøet. Microsoft har i alle fall ikke gjort det. For å være helt ærlig gidder jeg ikke å trykke «Send Error Report» på krasj-rapporter i Windows lenger en gang.
Samtidig sier Mundie at GPL-lisensiert programvare gjør at selskapene ikke kan tjene penger. Dette er selvfølgelig bare sprøyt. Det finnes haugevis med selskaper som omfavner fri programvare og fortsatt tjener mye penger. IBM, MySQL, Sun, eZ Systems og Novell bare for å nevne noen.
Meningen med GPL
Men før vi går videre, så er litt av poenget med GPL at det ikke skal brukes i proprietær programvare3:
Using a certain GNU program under the GPL does not fit our project to make proprietary software. Will you make an exception for us? It would mean more users of that program.
Sorry, we don’t make such exceptions. It would not be right.
Maximizing the number of users is not our aim. Rather, we are trying to give the crucial freedoms to as many users as possible. In general, proprietary software projects hinder rather than help the cause of freedom.
Litt av poenget med GPL er med andre ord å forhindre at noen kan lage egne restriksjoner på programvaren og avgrense friheten til bruk og distribusjon. Jeg synes Mundie, Ballmer og andre bør respektere det valget. De legger mye vekt på «Intellectual Property» (intellektuell eiendom), men bør det ikke også være en rettighet å gi bort denne eiendommen og sørge for at den alltid vil være tilgjengelig?
Hva er det som er så mye verre med dette enn hvordan Microsoft tradisjonelt har gjort det? Hele prosessen og koden er lukket, patenter og lisenser forhindrer noen andre i å bruke løsningene, og forbrukerne må betale for et produkt som har massevis av begrensninger. Men Microsoft prøver seg nå også med å frigjøre noe kildekode, mest på grunn av pålegg fra EU og andre.
Microsoft Shared Source
Microsoft baserer seg heller på en «enveisdeling» med «Shared Source», som er deres måte å dele på. Det innebærer at noen utvalgte partnere og statlige institusjoner får innsyn i noe av kildekoden til produktene. Med unntak av noen lisenser under «Shared Source» har man kun innsyn, og har ikke lov til å endre og videredistribuere den.
I forhold til GPL kan dette fort gå på bekostning av forbrukeren, ettersom du alltid vil være prisgitt det ene selskapet. Man kan si hva man vil om at utviklingen fort kan stoppe opp i fri programvare-prosjekter, men legger en utvikler av proprietær programvare ned prosjektet, finnes det ingen muligheter for å gjenopplive det (annet enn kanskje ved å kjøpe det ut med penger).
Man forsvarer seg ofte med at Microsoft alltid vil finnes, og det kan godt hende, men det skjer ting med produktporteføljen til Microsoft hele tiden. Gamle formater blir forkastet, grensesnitt blir drastisk endret og maskinvarekravene strammes inn. Som innen fri programvare bør man være varsom med hva man vil satse på, med andre ord.
En forskjell er imidlertid at det er lettere å forlate fri programvare og bytte til noe annet. Konkurransen er tøffere ettersom fri programvare ikke har samme markedsmakt som Microsoft, og konkurranse kommer forbrukeren til gode.
Kombinere fri og proprietær programvare
Men tilbake til temaet. Ballmer og Mundie hevder at kommersielle aktører aldri vil kunne bruke fri programvare.
Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
Det er med andre ord ikke noe i veien med å kombinere fri programvare og proprietære løsninger. Man får bare ikke lov til å selge eller distribuere det videre uten å gi ut hele pakka som fri programvare. Igjen kommer GPL forbrukeren til gode.
Det er også mulig å kombinere GPL og andre lukkede lisenser i et produkt for en utvikler:
I would like to release a program I wrote under the GNU GPL, but I would like to use the same code in non-free programs.
To release a non-free program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times.
Dersom du er utvikler av både GPL-lisensiert programvare og proprietær programvare, finnes det med andre ord ingen hindringer for å kombinere dem uten å måtte gi ut alt under GPL.
Innstikk og andre uavhengige moduler kan også under noen omstendigheter lisensieres på andre måter:
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
For de som fortsatt ikke er overbevist og synes at GPL og andre restriktive lisenser er skumle, finnes det haugevis av ikke-restriktive åpen kildekode-lisenser som kan brukes også, som for eksempel BSD.
Uvitenhet er roten til mye usannheter og FUD. Ballmers uttalelse har blitt trukket frem i mange anledninger, og er et klassisk eksempel på akkurat dette. Som du selv er inne på avslutningsvis finnes det lisenser som BSD som tillater derivater uten videre deling. Mac OS X er et klassisk eksempel på dette.
Personlig synes jeg GPL er en god modell som sikrer riktig bruk av kildekoden slik den opprinnelige utvikleren — altså opphavsmannen — hadde tenkt. Enkelte løsninger leveres også med såkalt «dual license», det vil si muligheten til enten å laste ned en GPL-versjon uten kostnader, eller å kjøpe en såkalt PUL (Proprietary Use License). Eksempelvis benytter eZ Systems denne modellen fordi enkelte kunder gjør endringer i kildekoden som er kritisk for virksomheten deres, og som utgjør et konkurransefortrinn.
For øvrig enda en bra artikkel, Audun. Du er inne i en god flyt, nå.
mars 12, 2008 @ 11:54 ( Direktelink )
Mange takk, Martin!
eZ Systems bruker nettopp det «smutthullet» som jeg henviser til innlegget (nest siste sitat). De kan gjøre det, fordi de også er de opprinnelige utviklerne av koden.
Det er noen svake sider med dette også, blant annet at de kan komme i en vanskelig situasjon dersom andre kommer med store bidrag til koden. Da er det ikke bare eZ som er de opprinnelige utviklerne av koden, og det kan bli vanskelig å ta med denne koden inn i en proprietær lisensmodell.
Man må da ta et valg om å droppe å ta med koden i den proprietære lisensen, eller droppe den i begge (med fare for «forking»). Eller kanskje man også kan ansette den som skrev koden, og på en slik måte få den med i begge? Det kan uansett bli en liten bremsekloss i forhold til utviklingen av produktet. Jeg kommer ikke på noen eksempler, så stort sett tror jeg dette håndteres veldig bra.
Dette er slik jeg har forstått det hovedårsaken til at «dual license» blir kritisert av enkelte innen fri programvare-miljøet.
mars 12, 2008 @ 16:57 ( Direktelink )