Åben sovs

Det var en mørk og stormfuld eftermiddag.

Den slipseklædte konsulent havde trængt mig op i en krog i mødelokalet for at udspørge mig om kvaliteten i den løsning jeg havde skitseret til det nye projekt.

Han ville vide om den nu var stabil, fremtidssikret og fornuftigt designet.

Mødet forløb som sådan fint nok. Der var styr på design, arkitektur og analysen var rundet fint af....indtil han spurgte til om vi brugte standardkomponenter.

"Næ nej", sagde jeg. "Vi benytter de bedste open source komponenter fra Apache til f.eks. logning, sikkerhed og persistens".

I samme øjeblik faldt temperaturen til langt under nulpunktet. Der blev iskoldt i lokalet og konsulentens slips (jeg sværger det er sandt) - ja det strammede sig sammen om halsen på ham.
Han hostede og spruttede og blev aldeles ildrød i hovedet. Hans øjne var ved at falde ud og der stod damp ud af ørene på ham.

"Open source ' OPEN source ' SAGDE DU OPEN SOURCE ?", vrælede han.

"Ja", sagde jeg. "Det bruger vi her i Jylland, gør I ikke det der hvor du kommer fra?".
(Jeg forsøgte at genskabe lidt feel-good fornemmelse ved at spørge til hans verden...)

"Jamen, jamen - hvem garanterer for kvaliteten ' Hvem sikrer at der sker opdateringer ' Hvem kan man ringe til ' Hvem, hvem '", sprudlede han videre...

Almost reality
Jeg må her tage et øjeblik og skuffe jer: Ovennævnte har aldrig fundet sted, men essensen af historien er, at os der aktivt bruger open source komponenter i vores løsninger gang på gang på gang på gang bliver konfronteret med at vi er nogle uansvarlige sjuskehoveder som ikke har forstand på kvalitetsløsninger.

Jeg husker engang jeg skrev tilbud på et større system og midt i processen valgte jeg at skifte en open source Java applikationsserver ind i tilbuddet fremfor den applikationsserver som den (ellers udemærkede) underleverandør havde på hylden til adskillige hundrede tusinde pr. CPU.
Det gjorde løsningen meget billigere og jeg var overbevist om, at jeg sagtens kunne levere lige så høj kvalitet i løsningen selvom jeg nu valgte open source.

Aldrig har jeg fået større møgfald (og så endda af en UNDERLEVERANDØR!). Jeg formoder, at jeg nok havde fornærmet ham mindre, hvis jeg havde kaldt hans store Audi for en Fiat.

Eller hvad med dengang hos det store IT hus hvor vi havde kørt med open source komponenter i 3 år uden problemer, men pludselig måtte vi ikke køre med samme komponenter da firmaet blev overtaget af et andet stort firma som KUN benyttede de open source komponenter der stod på deres white list.

Jeg forstår dem godt...lidt da
Og folkene har jo ret, lidt hen ad vejen i hvert fald.

Vi kan ikke benytte open source komponenter i systemudviklingen, hvis:
- vi ikke har garanti for at *nogen *supporterer dem (typisk i form af et aktivt community eller en god flok nørder hos os selv)
- vi er first mover og/eller alene om overhovedet at bruge det
- de ikke er sikre/stabile/færdige nok (hvordan kan vi ellers garanti oppetid, skalérbarhed og stabilitet til vores kunder?)

Men i alle de virksomheder jeg har hørt om, HVEM er det da der foretager en vurdering af om ovennævnte kriterier er overholdt ?

Ledelsen ? I think not...
Det er den enkelte udvikler/arkitekt der gør det.

Og derfor bliver ledelsens svar helt Dilbert agtigt: "Jeg har ikke hørt om den open source komponent før og derfor kan vi ikke benytte den.
Lad os hellere ringe til en stor IT leverandør og betale 3 millioner for et kommercielt alternativ, så kan vi altid sagsøge dem hvis der bliver problemer."

Overbevis mig...
Men vær så rar - kære læser - at overbevise mig om at DIN virksomhed gør det anderledes.

Eller fortæl mig hvordan vi slipper for diskutere hvorvidt open source komponenter er værre eller bedre end kommercielle komponenter?
Er problemet måske at vi udviklere blot lader brugen af open source være en græsrodsting og ikke gør et hæderligt arbejde for at overbevise ledelsen om at DET også er et muligt strategisk valg ?

Pretty please, with sugar on top...

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Flemming Sørensen

Problemet er vel at de kun har hørt om open source, i forbindelse med nogle få højtråbende fanatikere fra FSF Jihad, og set nogle selvmords pingviner der render rundt og springer sig selv i luften, for at redde verden. Det er jo ikke noget der i overvældende grad tyder på en mulig fredelig sameksistens mellem open og closed source. Hvis det var det eneste jeg havde set, så ville jeg også råbe og skrige som en gal.

  • 0
  • 0
#3 Flemming Sørensen

Ok, selvmordspingvinerne har jeg endnu ikke set, men besøg OSNews, næste gang Robert releaser en ny udgave af SkyOS, så skal du nok få resten at se. Du kan også kikke forbi det lidt mere hjemmelige Newz... Problemet er jo (som altid...) det højtråbende mindretal, der langt overdøver det fornuftige flertal.

  • 0
  • 0
#4 Deleted User

De virker nogen gange som om, at kravene til open source produkter er langt højere end til kommercielle.

Jeg arbejder i en større dansk transport virksomhed og her er det f.eks MS internet explorer version 6 over hele linjen. Fanden tage den der vover at installere en open source browser på sin klient. Selv Microsoft har åbent indrømmet, at IE-6 har været forsømt i flere år og den er da også af mange andre kåret som den største IT sikkerheds-trussel nogensinde.

Ja, det er dokumenteret at IE 6 er smæk fyldt med fejl og trusler mod sikkerheden. Ja, den er godt supporteret, halvdelen af konsulentbranchen er jo afhængig af MS. Ja, der er et firma man i det mindste kan forsøge at sagsøge. Ja, vi ved hvorfra opdateringerne kommer.

Men er forskellen virkelig så stor? Der er vil ikke noget bedre dokumenteret end netop open source, her kan man jo se hver enkelt linje kode om man vil. Normalt er der også en udemærket support at hente, den fungere bare anderledes: man betaler ikke en konsulent, men spørger f.eks bare programmøren. Man kan ikke rigtig sagsøge nogen, men har man forslag til forbedringer i produktet er de som oftes velkomne. Det er min erfaring, at opdateringerne på open source produkter ofte er hyppigere og hurtigere end på kommercielle.

Jeg tror der er noget helt andet og mere simpelt, der gør sig gældende. Martin Thorborg, skrev for nyligt et morsomt blog-indlæg, om at han fik mange flere henvendelser, da han satte prisen for et foredrag op fra lidt rødvin til 30.000 kr.

Jeg tror at en stor del af forklaringen, skal findes i primitive mekanismer i den menneskelige natur. Når noget koster mange penge, må det jo være godt?

Er Norton eller Clamwin antivirus bedst dokumenteret, supporteret, opdateret, eller bare bedst? Gider vi overhovedet at undersøge det, hvis vi kan smide penge efter førstnævnte?

Ville Firefox indtage alle danske kontorer, hvis den kostede 5000 kr pr licens? Er din næste IT-konsulent en 13 årige poptøs med en kæmpe D&G bæltespænde; "Du skal da have Hugo Boss browser, fordi det er jo ligesom Hugo Boss, ligesom, ..altså"?

  • 0
  • 0
#5 Dennis Krøger

Man kan sagtens få support på de fleste lidt større, eller kommercielt backed, open source produkter, det er bare ikke nødvendigvis fra udviklerne selv.

At der ikke er nogen garantier, er ikke så anderledes, har I nogensinde set en EULA der ikke fraskriver sig størstedelen af ansvaret?

  • 0
  • 0
#6 Peter Mogensen

Uanset hvad folk så har set, eller mener at have set, så er det da komplet uansvarligt at basere sin holdning til et softwareprodukt på det. Det er da komplet ligegyldigt hvor mange selvmordspingviner man mener at have set, hvis softwaren er af god kvalitet, der er mulighed for support og der endda er flere eksempler på størrer installationer, der har anvendt det gennem længere tid, så må man sgu som ansvarlig beslutningstager tage sig sammen og glemme sine fordomme fra OSnews, Newz, eller hvor man nu har fået dem henne.

  • 0
  • 0
#7 Peter Mogensen

En konsulent-opave jeg var på hos en større dansk halv-offentlig instituion. Ud over at jeg fik nogle mærkelige arbejdsforhold, hvor jeg kunne vælge mellem at sidde i larmen i server-rummet, eller kode via en langsom VNC-forbindelse, så fik jeg også "white-list" problemet at føle, da jeg pludselig stod og havde brug for at resize og convertere et par billeder. Jeg spørger selvfølgelig til om de har et program, der kan det? Næee... ikke umiddelbart. Jeg foreslår så at jeg blot installerer Gimp og kommer videre - men nej. "Gimp" er ikke på white-listen. Ved nærmere eftersyn viser det sig at det er det kun Photoshop der er. Jeg ved ikke med jer andre, men jeg er da glad for at jeg ikke arbejder et sted, hvor det koster 7000 kr at skalere to billeder.

  • 0
  • 0
#8 Thomas Ammitzbøll-Bach

Jeg er et par gange blevet spurgt om netop det samme, om hvilken garanti der er, for at man kan få support.

Nu indeholder tilværelsen en masse forhold, som der ikke er garanti for: At der er en erhvervsvenlig regering efter næste valg, at Donau ikke går over sine bredder, at dollaren ikke falder/stiger og en masse andre ting. Derfor taler alle, der har forstand på noget, heller ikke om garanti, men risc management. Sagt med andre ord: Du kan ikke få garanti, og hvis du kan, bliver det dyrt; men du kan købe de lodsedler, der giver bedst chance for gevinst.

Tilbage til sagen: Hvis du anvender Open Source (i snæver eller bred forstand) har du garantien for, at du altid kan hyre en ekspert et eller andet sted i verden, og betale ham for at gøre noget ved dit problem. Hvis du bruger Closed Source, kan du kun sagsøge/betale/trygle et enkelt firma, nemlig leverandøren.

Det andet, man tit hører, er at man kan sagsøge en leverandør, hvis softwaren ikke opfylder forventningerne. Det er det rene vås. Hvis man læse de betingelser, hvorunder man må bruge softwaren, så står det højt og tydeligt, at der ikke gives andre garantier end, at hvis installationsmediet er beskadiget, kan man få det ombyttet til et andet medium (et levn fra diskette-dagene, hvor der tit var læsefejl på disketterne.)

Så alt i alt: Du har lavet en applikation, der er bygget op over et framework, og sat den i drift. Nu viser det sig, at en fejl i frameworket gør din applikation ustabil. Du har kontaktet leverandøren, men denne har ikke udvist nogen interesse for at løse problemet. Titusindekronersspørgsmålet er nu: Er det bedst, at det er Open Source, hvor du kan købe nogen til at reparere det, eller at det er Closed Source og du skal indgive en stævning mod leverandøren om udbedring af fejlen? You take your pick!

Thomas

  • 0
  • 0
#9 Hasse Hagen Johansen

Jeg synes jo det er lidt grinagtigt at mange af de folk som bestemmer i de danske virksomheder(og især it-virksomhederne) synes det er svært at vurdere robusthed,support o.s.v. i opensource projekter. Det er jo sådan set meget sværere at vurdere når koden, og support er lukket så man ikke kan vurdere det før man har købt produktet

For det meste synes jeg ikke det virker som om der er saglige grunde til at vælge opensource fra, men at man vælger de proporitære "fordi det gør alle de andre"

  • 0
  • 0
#10 Flemming Sørensen

Q: Hvem sikrer at der sker opdateringer? A: Ingen.

Q: Hvem kan man ringe til? A: Ingen.

Q: Hvem, hvem? A: Ingen, ingen...

http://blogs.msdn.com/larryosterman/archive/2007/10/29/why-do-people-thi...

"These call centers didn't have the ability to upgrade their software (the vendor had gone out of business, and the application worked just fine for their needs)."

Ring til dem. Sagsøg dem. Glæd dig over dit closed source software, for tænk hvis det havde været det der open source noget. Det ville da have været frygteligt trist hvis man kunne have fået opdateret sit software...

  • 0
  • 0
#11 Jørgen Henningsen

Åben eller lukket source er vælger jeg efter behov, men det er bare sådan at der ofte med et lukket source program også følger lukkede og udokumenterede filformater/protokoller. Det kan jeg ikke forstå at noget firma kan leve med. Når man tænker på hvor store økonomiske resourcer, som er deponeret i arbejdsfilerne i sådan en PC, Så er det helt uforståeligt at man kan leve med at det for bestemte filtyper kun er eet bestemt firma med een bestemt applikation, som forstår at læse disse filer.

  • 0
  • 0
#12 Jesper Lund Stocholm Blogger

Diskussionen om CSS og OSS bliver meget lidt interessant, hvis den bliver polariseret og kun omhandler IIS vs. Apache, Windows vs. Linux eller plone vs. Community Server. Spørgsmålet om anvendelse af OSS er for os mest relevant/påtrængende, når vi ikke taler om "platforms-software" men om del-komponenter, der skal udføre en konkret opgave. Helt overordnet set er vi græsk-katolske overfor, om en givet opgave skal løses med OSS-software eller CSS-software. Eneste (næsten) parameter for os er, hvilken software, der løser opgaven bedst.

Men for vores kunder er det lidt anderledes - og her er vores opgave jo enten at rådgive dem eller på en god måde at forklare dem vores valg. For det er jo ikke nok, at et produkt er OSS - der skal også være support på det ... ellers risikerer vores kunde at stå med håret i postkassen, hvis noget går galt. Og nej - det er som udgangspunkt ikke nok, at "man jo bare kan kigge i kildekoden".

Men det behøver jo ikke at være first-tier, 24-timers support. Det kan lige så godt være et aktivt community (som det blev nævnt ovenfor) eller anden form for support - bare den er der. Vi har tidligere haft problemer med anvendelse af både OSS og CSS, hvis vi er kommet til at bruge noget software, hvor firmaet pludseligt ikke længere eksisterer - eller gutten bag det har fået et rigtigt arbejde eller lignende :o), så derfor er support i en eller anden form essentiel.

I forhold til OSS er der for os to klare udfordringer:

  1. Forståelse af licenserne og deres konsekvenser for det system, hvori softwaren skal anvendes

  2. Forklaring til kunden af, hvorfor det ikke er et problem at anvende noget software, hvor man ikke kan ringe til fx IBM, hvis det går galt.

Ovenstående er bestemt ikke umulige opgaver - men kræver dog, at man tænker sig om.

:o)

  • 0
  • 0
#13 Jesper Lund Stocholm Blogger

Jeg forstår ikke helt hvorfor folk mener at man skal være meget opmærksom i forbindelse med open source software og licenser.

Fordi OSS-licenser ofte er væsensforskellige fra CSS-licenser (i grove træk). Når du anskaffer dig en CSS-licens, så erhverver du dig typisk retten til at bruge licensen på x antal maskiner eller af x antal udviklere. (Punktum). Ved anvendelse af fx GPL-licenser og lGPL-licenser kan din brug af softwaren have konsekvenser for, hvordan du skal forholde dig til licensen af resten af din applikation. Derfor er det i hvert fald vores erfaring, at vi er nødt til at forholde os en smule anderledes til OSS-licenser end CSs-licenser. Det drejer sig ikke om, at det ene er bedre end det andet - blot at vi mener, at vi er nødt til at kigge lidt anderledes på OSS-software end CSS-software. I tråden her nævnes meget muligheden for at sagsøge - men det er slet ikke relevant for os (jeg har heller aldrig hørt det fra nogen kunde) - det er derimod relevant, hvad vi må og kan anvende softwaren til.

At man "bare kan kigge i kilde kode", er som nævnt ikke nok, det er betryggende at have den mulighed, hvis man ellers har evnerne.

Præcist - hvis man har evnerne eller pengene til at betale for, at andre hjælper med det. Mange af de OSS-komponenter vi anvender kræver utrolig stor domæneviden at lave, og det giver ikke mening at sige, at vi jo bare kan kigge i koden, hvis der er et problem. Jo - hvis koden kaster uventede fejl e. lign., men hvis vi fx blot har en mistanke om, at den regner forkert et eller andet sted, så er der ofte ikke mange andre, der har den nødvendige domæneviden til at løse det - end lige netop forfatterne af komponenten selv. Det er vores erfaring, at adgang til kildekoden kan hjælpe med at løse mange problemer - men bestemt ikke alle.

Jeg synes bare ikke det er det man ser, man ser folk vælge Microsoft løsninger, forbi software = Microsoft.

Jeg tror ikke på, at der er mange, der køber software fra Microsoft "fordi software=Microsoft". De gør det derimod fordi de er vante til at arbejde med produkter fra Microsoft og måske har en række medarbejdere, der har kompetence indenfor vedligeholdelse af fx en Windows-server. Derfor kan jeg ikke se problemet i, at en virksomhed vælger fx en Windows-server til at agere fil-server, hvis de har andre Windows-servere i forvejen, de har kompetencer, der kan vedligeholde den og det er deres erfaring, at en Windows-server virker godt for dem. Der er naturligvis masser af gode argumenter for at vælge en andens slags server-software ... jeg mener blot ikke, at den anden grund er dårlig i sig selv.

:o)

  • 0
  • 0
#14 C Frigaard

Som Dennis er lidt inde på, så er kvaliteten af den åh-så-vigtige support afgørende: jeg har flere gange prøvet at ringe til Microsoft supporten vdr. nogle MS problemer jeg sad med, men uden at jeg kunne trækken nogen form for brugbar viden ud af supporterne.

Med andre ord: et hurtigt opslag på nettet eller et kig i en howto manual kan være langt bedre som systemdokumentation end et supportopkald.

Mvh Carsten

  • 0
  • 0
#15 Thomas Ammitzbøll-Bach

Er der nogen her, der selv har, eller kender nogen, der har sagsøgt et større softwarefirma (Microsoft, Oracle, Adobe eller lignende)?

Hvordan gør man? EULA'en siger, at leverandøren ikke garanterer noget. Men der er nationale regler, der sætter disse ansvarsfraskrivelser ud af kraft eller svækker dem væsentligt. Hvordan griber man det an?

Hvad gør man så, efter man har vundet? Står man så med en pose penge men stadig uden en løsning, eller kan kan opnå et retsligt pålæg til disse firmaer om at rette fejlen?

Jeg er ret uvidende på dette område, så hvis der er nogen her, der kan fortælle noget, så kunne det være interessant.

(Gennem mit arbejde har vi ind i mellem opgaver, hvor vi skal fikse noget Open Source software, der ikke er i orden. Det er både en god forretning for os og vores kunder. Det kunne man ikke gøre med Closed Source software.)

Thomas

  • 0
  • 0
#16 Jesper Lund Stocholm Blogger

jeg har flere gange prøvet at ringe til Microsoft supporten vdr. nogle MS problemer jeg sad med, men uden at jeg kunne trækken nogen form for brugbar viden ud af supporterne.

Hvilken support drejede det sig om?

Jeg har et par gange haft fat i deres produktsupport med fejl i produkter - fx SQL Server. Den ene gang skyldtes en fejl i SQL-server (så det kostede os ikke noget) og den anden gang gav de os en work-around på vores problem. Begge gange har det været både tid og penge værd.

Med andre ord: et hurtigt opslag på nettet eller et kig i en howto manual kan være langt bedre som systemdokumentation end et supportopkald.

Enig - men det er ikke det samme som, at der slet ikke er behov for fx Professional Services fra Microsoft. De har helt klart deres berettigelse på markedet.

:o)

  • 0
  • 0
#17 Jens Katz-Kolberg

Jeg forstår ikke helt hvorfor folk mener at man skal være meget opmærksom i forbindelse med open source software og licenser.

Fordi OSS-licenser ofte er væsensforskellige fra CSS-licenser (i grove træk). Når du anskaffer dig en CSS-licens, så erhverver du dig typisk retten til at bruge licensen på x antal maskiner eller af x antal udviklere. (Punktum). Ved anvendelse af fx GPL-licenser og lGPL-licenser kan din brug af softwaren have konsekvenser for, hvordan du skal forholde dig til licensen af resten af din applikation. Derfor er det i hvert fald vores erfaring, at vi er nødt til at forholde os en smule anderledes til OSS-licenser end CSs-licenser.

Jeg forstår det stadigvæk ikke.

Der er ingen af de godkendte OSS licenser, der giver nogen specielle restriktioner, når man blot BRUGER softwaren.

OSS licensernes særlige forhold (f.eks. GPL og LGPL) gør sig først gældende, når man vil ændre i kildeteksten, og kopiere softwaren videre til andre.

Det kan man jo alligevel aldrig med closed-source.

Ved mange closed-source programmer er der alle mulige restriktioner mht. hvordan man blot bruger softwaren, som man altid er nødt til at sætte sig ind i. Det kan f.eks. være antal clienter ifb. med serversoftware, at man ikke må offentliggøre benchmarks, at man giver afkald på muligheden for søgsmål ifb. med at producenten evt. bryder ens egne patenter, etc.

Closed source software licenser bør altid forbi firmaadvokaten.

  • 0
  • 0
#18 Jesper Lund Stocholm Blogger

Der er ingen af de godkendte OSS licenser, der giver nogen specielle restriktioner, når man blot BRUGER softwaren.

Sikkert ikke.

OSS licensernes særlige forhold (f.eks. GPL og LGPL) gør sig først gældende, når man vil ændre i kildeteksten, og kopiere softwaren videre til andre.

Jeps - og det er jo også der vores anvendelse af software ligger. Det er til brug i applikationer, der skal sælges videre til en kunde. Derfor er det vigtigt at vide, hvad vi må anvende softwaren til. Må vi linke til den dynamisk (som fx lGPL-licensen lægger op til), må vi kompilere kildekoden ind i vores egen applikation? Må vi rette et komma i kildekoden og derefter kompilere den i vores applikation? Må vi c/p kildekoden ind i vores egen kildekode uden at angive, hvor den kommer fra? Alle disse ting er vigtige i forhold til den kontrakt vi har lavet med vores kunde om overdragelse af den software vi bygger.

Det kan man jo alligevel aldrig med closed-source.

Sikke noget pjat - bare fordi noget software er CSS er det ikke det samme som, at licenserne for det forbyder at man sælger/giver den som en del af en løsning til en kunde. At noget er CSS er heller ikke det samme som, at det koster penge.

Closed source software licenser bør altid forbi firmaadvokaten.

(alle licenser bør da forbi firma-advokaten)

Du blander tingene sammen. At noget er CSS betyder udelukkende, at man ikke har adgang til kildekoden. At antage at al CSS-software indebærer accept af uhyrlige licenskrav er direkte misvisende. På samme måde er det forkert at antage, at al OSS-software er licenseret under GPL v3. Det er jeg helt sikker på, at også du ved er tilfældet.

Det vil være givtigt for diskussionen, hvis du vil holde dig for øje, at vi taler om to forskellige ting:

  1. licenser til software
  2. adgang til kildekode eller ej

De to ting hænger ofte sammen, men det er ikke muligt at konkludere noget absolut om det ene på baggrund af det andet.

:o)

  • 0
  • 0
#19 Flemming Frandsen

For os der har indset at man godt kan lave profitabel software med OSS komponenter er det en ren fryd at at konkurrenter hoppe på CSS-limpinden.

Så vidt jeg kan se er OSS komponenter absolut kritiske for software udviklere, alene apache er jo en guldgrube af en anden verden.

At begrænse sig til CSS stumper ville jo være som at smøre en formel 1 bil med stabilgrus; dyrt og ikke særligt godt.

  • 0
  • 0
#20 Jesper Lund Stocholm Blogger

Flemming,

Så vidt jeg kan se

Tja - hvor er det lige henne, at den enøjede er konge?

er OSS komponenter absolut kritiske for software udviklere, alene apache er jo en guldgrube af en anden verden.

:o)

At begrænse sig til CSS stumper ville jo være som at ...

Det er jo ikke et spørgsmål om at begrænse sig til CSS-software. Det er et spørgsmål om, at man i den givne situation vælger den software, der bedst dæker ens behov - naturligvis givet faktorer som pris, licens og tilgængelighed af kildekode. For er det ikke det, det hele handler om - at have et valg og benytte sig af det?

... eller skal jeg forstå dig på den måde, at der er nogle valg, der i sig selv er bedre end andre?

:o)

  • 0
  • 0
#21 Jesper Lund Stocholm Blogger

Det vil være givtigt for diskussionen, hvis du vil holde dig for øje, at vi taler om to forskellige ting:

Øehm ... jeg var lige lidt hurtig. Der skulle naturligvis have stået:

Det vil være givtigt for diskussionen, hvis vi vil holde os for øje, at vi taler om to forskellige ting:

... jeg beklager :o)

  • 0
  • 0
#22 Jens Katz-Kolberg

Der er ingen af de godkendte OSS licenser, der giver nogen specielle restriktioner, når man blot BRUGER softwaren.

Sikkert ikke.

OSS licensernes særlige forhold (f.eks. GPL og LGPL) gør sig først gældende, når man vil ændre i kildeteksten, og kopiere softwaren videre til andre.

Jeps - og det er jo også der vores anvendelse

Din anvendelse måske. Andre tilrettter OSS applikationer, uden at skrive kildekode, eller ændre i OSS applikationens kildekode.

af software ligger. Det er til brug i applikationer, der skal sælges videre til en kunde. Derfor er det vigtigt at vide, hvad vi må anvende softwaren til. Må vi linke til den dynamisk (som fx lGPL-licensen lægger op til), må vi kompilere kildekoden ind i vores egen applikation? Må vi rette et komma i kildekoden og derefter kompilere den i vores applikation? Må vi c/p kildekoden ind i vores egen kildekode uden at angive, hvor den kommer fra? Alle disse ting er vigtige i forhold til den kontrakt vi har lavet med vores kunde om overdragelse af den software vi bygger.

Naturligvis er det vigtigt at vide. Det skriver jeg jo heller ikke at det ikke er.

Men det er de færreste CSS applikationer, hvor du må rette i kildeteksterne OG give (evt. sælge) det videre. Kan du give et eksempel ??

Hvilket var det jeg mente med nedenstående sætning:

Det kan man jo alligevel aldrig med closed-source.

Sikke noget pjat - bare fordi noget software er CSS er det ikke det samme som, at licenserne for det forbyder at man sælger/giver den som en del af en løsning til en kunde. At noget er CSS er heller ikke det samme som, at det koster penge.

Det har jeg jo heller ikke skrevet nogen steder.

Closed source software licenser bør altid forbi firmaadvokaten.

(alle licenser bør da forbi firma-advokaten)

Ja, men med OSS er det så heldigt at der eksisterer mange færre godkendte OSS licenser, end der er CSS licenser.

Se http://www.opensource.org/licenses/category - så send dem til firmaadvokaten een gang for alle. Og så er det ikke et problem mere...

Med CSS skal du i princippet sende licensen til gennemsyn, hver gang licensen bliver ændret, og det gør den ofte. Jeg har set det ofte for de store producenter (IBM/Oracle/Microsoft/..), - nogen gange for hver eneste version/patch, der kommer fra producenten.

OSS projekter ændrer også licens en gang imellem, men i langt, langt de fleste tilfælde er det blot til en anden af de godkendte licenser. Og det er jo enkelt at have med at gøre.

Du blander tingene sammen. At noget er CSS betyder udelukkende, at man ikke har adgang til kildekoden. At antage at al CSS-software indebærer accept af uhyrlige licenskrav er direkte misvisende. På samme måde er det forkert at antage, at al OSS-software er licenseret under GPL v3. Det er jeg helt sikker på, at også du ved er tilfældet.

Jeg blander ikke noget som helst. Intet af det du skriver her har jeg påstået.

Det vil være givtigt for diskussionen, hvis du vil holde dig for øje, at vi taler om to forskellige ting: 1. licenser til software 2. adgang til kildekode eller ej De to ting hænger ofte sammen, men det er ikke muligt at konkludere noget absolut om det ene på baggrund af det andet.

Jeg kan ikke se at ovenstående er relevant for mit indlæg.

Men som du selv skriver "At noget er CSS betyder udelukkende, at man ikke har adgang til kildekoden". Hvilket jo er en vigtig del af det.

I min verden er CSS software, der ikke opfylder kravene for godkendt OSS (http://www.opensource.org/docs/osd).

  • 0
  • 0
#23 Jesper Lund Stocholm Blogger

Jens,

Din anvendelse måske. Andre tilrettter OSS applikationer, uden at skrive kildekode, eller ændre i OSS applikationens kildekode.

Nu er jeg jo ikke involveret i alle vores projekter, men det er min opfattelse, at vores brug af OSS-projekter dækker disse området også.

Men det er de færreste CSS applikationer, hvor du må rette i kildeteksterne OG give (evt. sælge) det videre. Kan du give et eksempel ??

At noget er Closed Source Software indebærer jo "som oftest", at man ikke har adgang til kildekoden. Så nej - jeg har ikke oplevet, at man kan rette i kildekoden til noget software, hvor man ikke har adgang til kildekoden.

:o)

Ja, men med OSS er det så heldigt at der eksisterer mange færre godkendte OSS licenser, end der er CSS licenser.

Jeps

Se http://www.opensource.org/licenses/category - så send dem til firmaadvokaten een gang for alle. Og så er det ikke et problem mere...

Ja - det er en god start. Så er man sikker på, at der er /nogen/, der har tænkt over det.

  • 0
  • 0
Log ind eller Opret konto for at kommentere