SourceForge opent commerciële marktplaats voor opensourcesoftware

Deze week is SourceForge Marketplace geopend. Ontwikkelaars kunnen daar hun opensourcesoftware en diensten aanbieden, en gebruikers kunnen vervolgens tegen betaling, waaraan SourceForge ook verdient, de software laten aanpassen.

Eind november maakte SourceForge bekend dat er in het derde fiscale kwartaal een verlies was gemaakt van 1,1 miljoen dollar. Om een constante inkomstenstroom te waarborgen heeft men daarom de online softwareveiling ontwikkeld. Volgens SourceForge is het plaatsen van software op de nieuwe website volledig gratis. In het geval dat er via de Marketplace diensten of producten verkocht worden, moet een commissie van 7,7 tot 12,5 procent van de omzet aan SourceForge worden afgedragen.

Binnen de opensourcesoftwaregemeenschap is, schrijft BetaNews, op verschillende nieuwssites amper gereageerd op de lancering van de commerciële activiteit van SourceForge, een bedrijf dat groot is geworden met de verspreiding en publicatie van opensourcesoftware. De kans is groot dat men het gewoon is gaan vinden dat dit gebeurt, aangezien een toenemend aantal ontwikkelaars van dit soort programmatuur geld gaat vragen voor ondersteuning of voor extra features.

Reacties (70)

[Verwijderd]

OpenSource heeft helemaal niets te maken met de gevraagde prijs. Ik snap niet dat dit bericht daar weer mee geflamed word.

Ik kan me een briljant citaat herinneren, alleen weet ik jammer genoeg niet meer wat de bron is, maar het ging een beetje als volgt:

Free as in Freedom, not Free as in free beer.

De originele ontwikkelaar kiest zelf om een bepaalde reden voor een bepaalde licentie, als in die licentie is opgenomen dat aanpassingen altijd gratis aan de community moet worden overgedragen is dat prima, maar als dat niet het geval is, dan staat het ontwikkelaars vrij om een pakket over te nemen, aan te passen en verder te verkopen zolang er voldaan word aan de licentievoorwaarden (vaak dat de code meegeleverd word, zodat er weer verder ontwikkeld kan worden).

Je kunt het zo moeilijk of zo makkelijk maken als je wilt, maar iedereen die roept dat OpenSource gratis moet zijn is niet reeel. Houd je aan de Licenties en je zit altijd goed.

Ik vind het een goed streven dat een grote speler in de OSS community als SourceForge de stap neemt om commerciele exploitatie van OSS te stimuleren, het betekend namelijk dat ontwikkelaars net dat tandje extra kunnen inzetten voor de ontwikkeling van hun software, wat in de toekomst alleen maar meer mogelijkheden bied voor Vrije software.

[Herko_ter_Horst]

"Free as in freedom, not free as in beer" heeft NIETS te maken met Open Source, maar met de GPL/Free Software Foundation. Bovendien hebben zij het over freedom voor gebruikers (en niet, bijvoorbeeld, over freedom voor developers: voor mij als developer biedt de GPL veel minder "freedom" dan bijvoorbeeld een BSD licentie). Overigens is het practische gevolg van "free as in freedom" "free as in beer" waar het de source code betreft.

Het gevolg van een Open Source licentie is dat (de source code van) die software vrijelijk beschikbaar is (lees artikel 1 en 2 van de Open Source Definition).

Als het een zogenaamde "reciprocal" licentie betreft zal ook de source code van alle afgeleide software vrijelijk beschikbaar moeten komen.

Dat wil inderdaad NIET zeggen dat je geen geld MAG vragen voor de software (tenzij een bepaalde licentie dat expliciet verbiedt), maar dat de source in elk geval (zo goed als) gratis beschikbaar moet zijn. Wat dus tot gevolg heeft dat er altijd een manier is om de software gratis (en legaal ) te pakken krijgen.

P.S. gooi alsjeblieft "Free Software" (zoals gedefinieerd door de FSF) en "Open Source" (zoals gedefinieerd door de Open Source Initiative) niet op één hoop.

Free Software is maar één van de mogelijke invullingen van Open Source (een invulling die vanuit een bepaalde ideologie de vrijheden van de gebruiker wil beschermen ten koste van de vrijheden van ontwikkelaars/verspreiders).

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Verwijderd]

Bovendien hebben zij het over freedom voor gebruikers (en niet, bijvoorbeeld, over freedom voor developers: voor mij als developer biedt de GPL veel minder "freedom" dan bijvoorbeeld een BSD licentie).

Dit ligt er puur aan wat je er mee wil gaan doen. Ik vind een nadeel van de BSD license dat iemand anders er mee aan de haal kan gaan. Je hoeft alleen maar de eigenaar/programmeur te vermelden.

Ik wil niet negatief zijn maar ik denk dat de kans at het gevonden wordt en de sancties die hier op staan nog kleiner zijn dan op GPL.

Als je echte freedom met je code wil hebben moet je ze niet vrijgeven. Het nadeel is dan ook dan een second source je code niet kan beoordelen en verbeteren. Maar dat is natuurlijk een keuze die je maakt.

[Herko_ter_Horst]

Natuurlijk is een "nadeel" van de BSD dat iemand anders er mee aan de haal kan gaan. Als ontwikkelaar die graag gebruikt maakt van 3rd party libraries vind ik dat echter een voordeel.

Het is veel lastiger de BSD te overtreden dan de GPL, simpelweg omdat de BSD veel meer toestaat.

De laatste alinea begrijp ik niet. Als maker heb je sowieso alle vrijheid met je code, jij bezit immers het copyright. Je beslist zelf aan wie je onder welke voorwaarden (licentie) je de software beschikbaar stelt. Het gaat altijd om wat anderen met jouw software mogen, niet wat je er zelf mee mag.

Dus: als gebruiker heb ik het liefst gratis software (en eigenlijk maakt de licentie me dan verder geen zak uit), als ontwikkelaar liever BSD (omdat ik daarmee de garantie heb dat ik er vrijwel alles mee mag doen).

Wat ik het probleem vind van de GPL/FSF is dat de term "free(dom)" gebruikt wordt voor een hele specifieke soort vrijheid (hebben amerikanen wel vaker last van, trouwens), in dit geval de vrijheid van de eindgebruiker. De BSD vind ik veel vrijer omdat er minder restricties in staan. Inderdaad biedt dit geen/weinig bescherming aan de maker, maar wel veel vrijheid voor zowel de eindgebruiker als de ontwikkelaar/verspreider om met de software te doen wat ie wil.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Little Penguin]

De BSD vind ik veel vrijer omdat er minder restricties in staan. Inderdaad biedt dit geen/weinig bescherming aan de maker, maar wel veel vrijheid voor zowel de eindgebruiker als de ontwikkelaar/verspreider om met de software te doen wat ie wil.

Het probleem is dat als er software aangeboden wordt, waarbij er gebruik gemaakt is van mijn library - die ik vrijwillig vrijgegeven heb, dat als ik voor de BSDL kies ik niet de garantie heb dat ik de broncode kan verkrijgen. Kies ik voor de GPL dan heb ik wel de toegang tot de volledige code.

Mocht ik nu alleen geïnteresseerd zijn in verbeteringen aan de library zelf, dan zou ik bijvoorbeeld kunnen kiezen voor de LGPL of MPL e.d.

Het mooie van de GPL is dat, als je verstand van zaken hebt natuurlijk, je irritaties/foutjes uit de software weg kan nemen. De meeste andere licenties geven die garantie niet...

Dus: als gebruiker heb ik liever GPL software, als ontwikkelaar liever BSD.

Daar ben ik het bijna helemaal mee eens, zoveel libraries maak ik zelf toch niet. Mocht ik dat ooit echter wel doen, dan kies ik zelf als ontwikkelaar toch eerder voor een FSF-licentie dan voor de BSDL. Waarschijnlijk zal ik dan voor de LGPL kiezen, omdat wijzigingen (vaak verbeteringen) dan wel vrijgegeven moeten worden.

Als ontvangende ontwikkelaar heb ik dus graag BSDL of public domain broncode, maar als gevens ontwikkelaar ga ik eerder voor de LGPL/MPL e.d.

[Herko_ter_Horst]

Precies: het gaat dus steeds om wiens rechten je wilt beschermen.

Ik werk zelf voor een Open Source bedrijf, en wij gebruiken zowel een BSD-style license (BSD-"style", omdat de BSD een template license is waar je je eigen naam in moet vullen) als de Open Software License (OSL) voor bepaalde delen van onze code.

De BSD gebruiken we voor standaard libraries die we ontwikkelen als als utilities voor onze eigen software én voor software waarvan we vinden dat verspreiding/gebruik voor ons meer waard is dan controle over toevoegingen en ge-/misbruik door anderen. In ons geval geldt dat laatste voor software waar we al een sterke community omheen hebben opgebouwd, zodat de kans op forks e.d. een stuk kleiner is.

De OSL gebruiken we voor onze "kroonjuwelen": de software die echt deel uitmaakt van onze core business. Door middel van de OSL hebben we meer controle over wat ermee gebeurt en voorkomen we dat de concurrentie er zomaar mee aan de haal kan gaan.

We hebben specifiek NIET gekozen voor de GPL omdat de GPL vanuit de achterliggende ideologie bepaalde restricities oplegt die wij niet onderschrijven. Ook zijn bepaalde klanten overgevoelig voor de GPL (lees: er mag geen GPL software gebruikt worden). Daarnaast waren er nog een paar practische redenen, zo sluit de OSL door de gebruikte terminologie beter aan bij de europese rechtspraak.

Al onze software is overigens ook verkrijgbaar onder een proprietary (niet-Open Source) license, waarvoor uiteraard betaalt moet worden.

[Little Penguin]

Uiteindelijk kiest de verspreider van software voor een licentie, dan wordt er gekozen voor een licentie die het best aansluit bij de intenties die de verspreider heeft. Niemand verbied dat ook.

Als ontvanger van zo'n software onder de gekzen licentie zul je moeten kiezen of je akkoord gaat, of niet - ga je niet akkoord dan zul je andere software moeten kiezen.

We hebben specifiek NIET gekozen voor de GPL omdat de GPL vanuit de achterliggende ideologie bepaalde restricities oplegt die wij niet onderschrijven.

Mocht je het niet eens zijn met de GPL, dan kun je altijd nog kiezen voor de LGPL. Ben je het daar ook niet mee eens, dan zijn er nog tientallen licenties waar je uit kunt kiezen - waarvan de 3-clause en 4-clause BSD-licenties mogelijke keuzes zijn...

Ook zijn bepaalde klanten overgevoelig voor de GPL (lees: er mag geen GPL software gebruikt worden).

Tenzij die klanten software ontwikkelaars zijn, of jullie direct betalen voor de ontwikkeling van software (maatwerk dus) zie ik niet in waar men overgevoelig over zou moeten zijn.

Daarnaast waren er nog een paar practische redenen, zo sluit de OSL door de gebruikte terminologie beter aan bij de europese rechtspraak.

Om eerlijk te zijn ken ik de OSL niet en kan ik daar dus niet over oordelen. Overigens is versie 3 van de (L)GPL ook beter toegespitst op internationale rechtspraak, dus dat argument komt op (middel)lange termijn te vervallen.

Voor de geïnteresseerden: http://en.wikipedia.org/wiki/Open_Software_License
Uit dat artikel begrijp ik zelf dat de OSL vergelijkbaar met , maar niet identiek is aan, de LGPL

[Herko_ter_Horst]

Uiteindelijk kiest de verspreider van software voor een licentie, dan wordt er gekozen voor een licentie die het best aansluit bij de intenties die de verspreider heeft. Niemand verbied dat ook.

Als ontvanger van zo'n software onder de gekzen licentie zul je moeten kiezen of je akkoord gaat, of niet - ga je niet akkoord dan zul je andere software moeten kiezen.

Helemaal mee eens.

[...]
Mocht je het niet eens zijn met de GPL, dan kun je altijd nog kiezen voor de LGPL. Ben je het daar ook niet mee eens, dan zijn er nog tientallen licenties waar je uit kunt kiezen - waarvan de 3-clause en 4-clause BSD-licenties mogelijke keuzes zijn...

Uiteraard hebben wij de LGPL ook overwogen. Hier was het met name de onduidelijkheid rondom de "linking clause" die ons hiervan heeft doen afzien (al dan niet terecht, maar preceptie binnen de communty was voor ons ook belangrijk).

[...]
Tenzij die klanten software ontwikkelaars zijn, of jullie direct betalen voor de ontwikkeling van software (maatwerk dus) zie ik niet in waar men overgevoelig over zou moeten zijn.

Het gaat inderdaad om klanten c.q. partners die op basis van onze software verder willen kunnen ontwikkelen.

[...]
Om eerlijk te zijn ken ik de OSL niet en kan ik daar dus niet over oordelen. Overigens is versie 3 van de (L)GPL ook beter toegespitst op internationale rechtspraak, dus dat argument komt op (middel)lange termijn te vervallen.

Voor de geïnteresseerden: http://en.wikipedia.org/wiki/Open_Software_License
Uit dat artikel begrijp ik zelf dat de OSL vergelijkbaar met , maar niet identiek is aan, de LGPL

GPL/LGPL v3 waren niet beschikbaar. Maar zelfs als ze wel beschikbaar waren geweest betwijfel ik of we daarvoor hadden gekozen.

OSL is inderdaad vergelijkbaar met de LGPL(v2), echter de terminologie van de OSL was (ook volgens de juristen die we hebben geraadpleegd) beduidend helderder en voor minder interpretaties vatbaar.

[Verwijderd]

Wat ik het probleem vind van de GPL/FSF is dat de term "free(dom)" gebruikt wordt voor een hele specifieke soort vrijheid (hebben amerikanen wel vaker last van, trouwens), in dit geval de vrijheid van de eindgebruiker. De BSD vind ik veel vrijer omdat er minder restricties in staan. Inderdaad biedt dit geen/weinig bescherming aan de maker, maar wel veel vrijheid voor zowel de eindgebruiker als de ontwikkelaar/verspreider om met de software te doen wat ie wil.

Volgens mij benaderen we dit beide van een andere invalshoek. "Correct me if I'm wrong".

Ik heb het over iemand die GPL/BSD code ontwikkeld.

Je hebt het over een ontwikkelaar die GPL/BSD code gebruikt.

Ik sta in deze niet achter de mening die je verkondigd ook al "zondig" je tegen geen enkele license. Ik vind dat je minimaal iets aan de community zou terug moeten geven. Dit kan bij GPL zich ook beperken tot alleen het verbeteren van een library die dynamisch gelinkt hebt, dit hoeft niet eens bij BSD. Het wil niet zeggen dat je je eigen code moet vrij geven.

Hoe zit het trouwens met BSD en het vermelden van de bron? Is dit verplicht.
E.a. gevonden:
http://www.xos.nl/resources/articles/lv-04
http://www.livre.nl/compo...task,doc_download/gid,16/

GPL is niet alleen vrijheid het betekend ook dat verbeteringen in GPL dmv commerciële fabrikanten ook terug komen. Zodat de code maximaal verbeterd kan worden. Zo wordt bijvoorbeeld KHTML verbeterd doordat Apple deze render engine in Safari gebruikt.

Ik zou niet willen dat commerciële partijen er mee aan de haal zouden gaan. En zeker niet in de vorm dat ze een paar kleine veranderingen aanbrengen waardoor een andere partij dit niet meer kan gebruiken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:48]

[Herko_ter_Horst]

Ik zie jouw invalshoek nog niet, dus ik weet niet of ik op het juiste reageer

Ik heb het volgens mij over zowel over "uitgevers" als "ontvangers".

Ik weet niet over welke "mening" je het hebt die iets met zondigen te maken heeft. Ik heb volgens mij nergens verkondigd dat je moet zondigen tegen welke licentie dan ook.

Je moet m.i. als "uitgever" de licentie gebruiken die het beste past bij jouw bedoelingen met de code. Dat kan wat mij betreft ook best een proprietary license zijn, hoewel ik denk dat er praktische (niet: ideologische) redenen zijn om dat niet te doen. De FSF (of iig Richard Stallman) verwerpt echter proprietary software als "antisocial" en "immoral".

Daarbij gebruikt de FSF de term "free(dom)" voor een specifieke soort vrijheid, wat volgens mij nooit kan kloppen. Even voor de duidelijkheid: elke licentie (en het hele copyright systeem) *beperkt* vrijheden. Alleen iets in het Public Domain heeft geen enkele restrictie en kan dus wat mij betreft echt "free" (zowel "as in beer" als "as in speech") worden genoemd.

De GPL beschermt met name de rechten van de *gebruiker* van de software om toegang te krijgen tot de orginele source code en eventuele latere aanpassingen daarop. De GPL doet dit door de rechten/vrijheden van ontwikkelaars/distributeurs van op GPL gebaseerde software in te perken. Als dat je doel is voor een bepaald stuk software: prima. Maar noem dat dan geen "vrijheid".

Overigens beschermt elke "reciprocal" license de rechten van de community/oorspronkelijke ontwikkelaars met de eis dat aanpassingen onder (meestal dezelfde) Open Source license worden vrijgegeven, dit is niet voorbehouden aan de GPL. De GPL gaat hier alleen extreem ver in.

Dus als je niet wilt dat iemand met jouw software aan de haal gaat: gebruik een reciprocal license. Als je graag wilt dat je software zo veel mogelijk gebruikt wordt, gebruik dan een academic license zoals de BSD.

P.S. m.b.t. de BSD: de BSD eist weinig. In de oorspronkelijke BSD licentie stond een zgn. "Advertising Clause" die de verplichting oplegde om in alle "advertising materials" voor een product gebaseerd op de BSD code een acknowledgment op te nemen. De (tegenwoordig gebruikte) "new BSD license" heeft als eisen dat bestaande copyright notices niet verwijderd mogen worden en dat de naam van de oorspronkelijk ontwikkelaar niet mag worden gebruikt voor promotiedoeleinden.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Verwijderd]

Ik weet niet over welke "mening" je het hebt die iets met zondigen te maken heeft. Ik heb volgens mij nergens verkondigd dat je moet zondigen tegen welke licentie dan ook.

Volgens mij zondig je nergens tegen. Alleen zijn onze idealen anders. Daar is ook niets mis mee. Ik ben meer een GPL persoon die vind dat alle verbeteringen ook terug moeten komen bij de bron c.q. code. Ik streef meer naar perfectie dmv een gezamenlijke ontwikkeling waar de source binnen OSS gemeenschap blijft, niet eens bij de originele ontwikkelaar. Eigenlijk het model dat momenteel voor de Linux Kernel toegepast word.
IMO was de Linux Kernel nooit zo snel en goed ontwikkeld als deze nu is. Het zelfde gaat IMO bijvoorbeeld op voor KDE.

De GPL doet dit door de rechten/vrijheden van ontwikkelaars/distributeurs van op GPL gebaseerde software in te perken.

Daarvoor krijgen ze een product terug dat door een hele groep mensen ontwikkeld en verbeterd word. Dus ook verbeteringen van commerciele partijen.

Een voorbeeld. Nokia gebruikt voor hun FW appliances een BSD kernel. Ze zullen zeker verbeteringen in deze kernel aangebracht hebben. Doordat deze binnen de BSD license valt hoeven ze niets aan de community terug te geven c.q. source code te publiceren. Mogelijk dat ze dat wel gedaan hebben, aangezien Nokia de OSS een behoorlijk warm hart toedraagt.

Dus als je niet wilt dat iemand met jouw software aan de haal gaat: gebruik een reciprocal license. Als je graag dat je software zo veel mogelijk gebruikt wordt, gebruik dan een academic license zoals de BSD.

Ik heb het gevoel dat het niet zoveel uitmaakt of je een BSD license hebt of een GPL. Het probleen IMO dat veel bedrijven er (nog) niet mee om kunnen gaan. Bij een BSD license eindigt al je energie mogelijk in een produkt waarvan niemand weet dat je dit ooit ontwikkeld hebt. Het schijnt bijvoorbeeld dat Microsoft windows kerberos en Bind4 heeft gebruikt. Wat ook mag, maar wat hebben de originele ontwikkelaars hier mee gewonnen.

Er zijn al veel bedrijven die het nu van GPL inzien. Je hebt als voordeel dat je bij een interessant project veel meer en goedkoper ontwikkelaars bij krijgt dan je ooit zou kunnen financieren. Dan kan de support de doorslaggevende reden zijn waarom mensen toch voor je product betalen.

[Herko_ter_Horst]

Ik streef meer naar perfectie dmv een gezamenlijke ontwikkeling waar de source binnen OSS gemeenschap blijft, niet eens bij de originele ontwikkelaar.

Dit streven is de denk ik de één van de basisgedachten achter Open Source. Dit is echter af te dekken met elke reciprocal license, niet alleen met de GPL. Daarnaast zijn er communities die sterk/gevestigd genoeg zijn om met een academic license (BSD-achtige) hetzelfde te bereiken en/of het niet erg vinden dat er óók partijen zijn die niets teruggeven.

Free Software zoals door de FSF gedefinieerd en zoals gecodeerd in de GPL heeft daarnaast nog expliciet een andere doelstelling: het voorkomen van non-Free c.q. non-GPL software.

Veel reciprocal licenses (en de GPL in het bijzonder) definieren een gesloten wereld, wat natuurlijk een ironische situatie is. Voor bepaalde ontwikkelaars en/of projecten is het belangrijker zoveel mogelijk toe te staan dan om zich te beperken tot zo'n gesloten wereld. Daarbij nemen ze dan het gebruik binnen andere gesloten werelden (zoals proprietary software) voor lief.

[Verwijderd]

Daarnaast zijn er communities die sterk/gevestigd genoeg zijn om met een academic license (BSD-achtige) hetzelfde te bereiken en/of het niet erg vinden dat er óók partijen zijn die niets teruggeven.

Dat kan en mag. Bijvoorbeeld Microsoft verdient miljarden over de rug ook met hulp van code van deze mensen. Met als ergste dat ze zelfs nooit iets terug gegeven hebben.

Free Software zoals door de FSF gedefinieerd en zoals gecodeerd in de GPL heeft daarnaast nog expliciet een andere doelstelling: het voorkomen van non-Free c.q. non-GPL software.

Dit is onzin! Als ze dit zouden toelaten moesten ze ook toelaten dat de license van GPL veranderd mag worden naar een ander license type. Veel commerciële bedrijven inclusief Microsoft zouden juichen dan zou er een manier zijn om onder GPL uit te komen. Dit is ook de reden waarom ZFS niet in de Linux kernel zit. Beide licenses mogen niet herdefinieert worden.

Veel reciprocal licenses (en de GPL in het bijzonder) definieren een gesloten wereld, wat natuurlijk een ironische situatie is. Voor bepaalde ontwikkelaars en/of projecten is het belangrijker zoveel mogelijk toe te staan dan om zich te beperken tot zo'n gesloten wereld. Daarbij nemen ze dan het gebruik binnen andere gesloten werelden (zoals proprietary software) voor lief.

Volgens mij definieert GPL alles behalve een gesloten wereld. Hoogstens voor de mensen die deze licentie willen misbruiken.
Ik kan me helaas niet aan de indruk onttrekken dat je GPL hinderlijk vind omdat je het niet vrijelijk mag gebruiken.

Mijn ervaring is dat van de kant van ontwikkeling GPL zelfs een heel open wereld is. Ontwikkel projecten zoals KDE, openSuSE, ubuntu, debian, fedora, mandriva etc verwelkomen iedereen met open armen ook al heeft diegene geen programmeer ervaring. Iedereen kan een bijdrage een aan project leveren van new bie tot expert. In de vorm van vertalen, testen, programmeren etc.

Ik ben blij dat GPL een gesloten wereld is voor bedrijven die de licentie niet willen naleven. Dan moeten ze maar commerciële software gebruiken of alles van de grond af programmeren.

GPL code kun je ook in propietary code gebruiken. Dis ook wat Apple doet met KHTML in Safari. KHTML is OSS en Safari niet c.q. alleen het KHTML deel van Safari.

[Herko_ter_Horst]

[...]
Dat kan en mag. Bijvoorbeeld Microsoft verdient miljarden over de rug ook met hulp van code van deze mensen. Met als ergste dat ze zelfs nooit iets terug gegeven hebben.

[...]
Dit is onzin! Als ze dit zouden toelaten moesten ze ook toelaten dat de license van GPL veranderd mag worden naar een ander license type. Veel commerciële bedrijven inclusief Microsoft zouden juichen dan zou er een manier zijn om onder GPL uit te komen. Dit is ook de reden waarom ZFS niet in de Linux kernel zit. Beide licenses mogen niet herdefinieert worden.

Wat is er onzin? Ik zeg toch niet dat ze iets zouden moeten toelaten? Ik geef alleen aan dat er naast de GPL meer licenties zijn die "teruggeven van aanpassingen/verbeteringen" regelen en dat de GPL daarnaast een extra doel heeft. En dat ZFS niet in de kernel zit bevestigd mijn verhaal over gesloten werelden.

[...]
Volgens mij definieert GPL alles behalve een gesloten wereld. Hoogstens voor de mensen die deze licentie willen misbruiken.
Ik kan me helaas niet aan de indruk onttrekken dat je GPL hinderlijk vind omdat je het niet vrijelijk mag gebruiken.

Dan begrijp je me verkeerd c.q. heb je mijn eerdere reacties niet goed gelezen (en je spreekt jezelf tegen). Ik werk voor een Open Source bedrijf. Voor onze software maken we gebruik van twee licenties: de BSD (een academic license met weinig restrictieve voorwaarden) en de OSL (een reciprocal license, die -net als de GPL- eist dat je aanpassingen aan onze software onder de OSL "terug moet geven"). Ik heb niks tegen het principe van het teruggeven van software. Ik probeer alleen duidelijk te maken dat er meer mogelijkheden zijn dan de GPL om dit voor elkaar te krijgen en dat de GPL aanvullende eisen stelt die gevolgen hebben.

Mijn ervaring is dat van de kant van ontwikkeling GPL zelfs een heel open wereld is. Ontwikkel projecten zoals KDE, openSuSE, ubuntu, debian, fedora, mandriva etc verwelkomen iedereen met open armen ook al heeft diegene geen programmeer ervaring. Iedereen kan een bijdrage een aan project leveren van new bie tot expert. In de vorm van vertalen, testen, programmeren etc.

Ik ben blij dat GPL een gesloten wereld is voor bedrijven die de licentie niet willen naleven. Dan moeten ze maar commerciële software gebruiken of alles van de grond af programmeren.

Natuurlijk is er veel openheid in Open Source projecten. Mijn opmerking ging daar ook niet over. Veel Open Source licenties (met name de reciprocal c.q. Copyleft licenties) zijn niet compatible met andere Open Source licenties. Vandaar mijn opmerking over gesloten werelden en ironie.

GPL code kun je ook in propietary code gebruiken. Dis ook wat Apple doet met KHTML in Safari. KHTML is OSS en Safari niet c.q. alleen het KHTML deel van Safari.

Dat kan alleen omdat KHTML onder de LGPL licentie valt. Als dit de GPL licentie was geweest, had dit niet gemogen.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Verwijderd]

<q>
GPL code kun je ook in propietary code gebruiken. Dis ook wat Apple doet met KHTML in Safari. KHTML is OSS en Safari niet c.q. alleen het KHTML deel van Safari.
</q>

Dat kan alleen omdat KHTML onder de LGPL licentie valt. Als dit de GPL licentie was geweest, had dit niet gemogen.

In de vorm die Apple gebruikt klopt dit ze doen namelijk statisch linken c.q. ktml wordt een integraal deel van hun software. Als ze dynamisch gelinkt hadden (als dat in dit voor dit deel mogelijk was) had dit probleem waarschijnlijk/mogelijk niet opgetreden.

Dit een beetje een grijs gebied, of dynamisch linken met GPL code de andere code ook GPL maakt, zie:
http://lkml.org/lkml/2007/6/15/284
http://www.legistics.net/...&id=52&Itemid=99&lang=eng
http://www.novell.com/coolsolutions/feature/1532.html

Het lijkt me het best dat hier een uitspraak over gedaan word. IMO is het best dat dynamisch linken wel toegestaan wordt maar statisch niet. C.q bij dynamisch linken kan de code non GPL blijven bij statisch linken moet de code ook GPL worden.

LGPL is nog steeds een GPL license die je verplicht om de code terug te geven voor het LGPL deel. Dit hoeft onder een BSD/MIT license niet.

Veel Open Source licenties (met name de reciprocal c.q. Copyleft licenties) zijn niet compatible met andere Open Source licenties. Vandaar mijn opmerking over gesloten werelden en ironie.

Dat klopt maar het ligt er aan hoe je het bekijkt. Omdat GPL strenge regels opstelt is het moeilijker te combineren met andere code. Ik ben er ook blij me. Ik ben er van overtuigt dat in het geval de GPL code onder een MIT/BSD license uitgeven zouden zijn zou een bedrijf als Microsoft allang delen van deze code gebruikt hebben (wat ook geheel legaal zou zijn). Dan zou je in direct je eigen graf gegraven hebben. Zeker omdat Microsoft veel machtiger en commercieel sterk is dan een OSS project.

[Herko_ter_Horst]

[...]
In de vorm die Apple gebruikt klopt dit ze doen namelijk statisch linken c.q. ktml wordt een integraal deel van hun software. Als ze dynamisch gelinkt hadden (als dat in dit voor dit deel mogelijk was) had dit probleem waarschijnlijk/mogelijk niet opgetreden.
[...]
Het lijkt me het best dat hier een uitspraak over gedaan word. IMO is het best dat dynamisch linken wel toegestaan wordt maar statisch niet. C.q bij dynamisch linken kan de code non GPL blijven bij statisch linken moet de code ook GPL worden.

Dit grijze gebied is nou juist het deel van de license waarin de GPL uitgaat boven andere reciprocal licenses (het gebied dat het zogenaamde "virale" karakter van de GPL vastlegt). Nog afgezien van het feit dat "statisch en dynamisch linken" in veel programmeertalen helemaal geen betekenis heeft, is het gezien de laatste regel op deze pagina duidelijk de bedoeling dat elk programma dat gebruik maakt van code die onder de GPL valt, zelf ook onder de GPL moet vallen.

LGPL is nog steeds een GPL license die je verplicht om de code terug te geven voor het LGPL deel. Dit hoeft onder een BSD/MIT license niet.

Mee eens. De LGPL heeft voorwaarden die vergelijkbaar zijn met de meeste andere reciprocal licenses: als je iets verandert aan de code zelf moet je het teruggeven, als je alleen maar "gebruik maakt van" hoeft dat niet. Nadeel van de LGPL is wel dat de uitzondering op de GPL die dit laatste toestaat ongelukkig is uitgedrukt (namelijk in termen van "libraries", "linking" en "executable", die óf een zeer specifieke betekenis hebben, of helemaal geen). Vanwege de FUD die hier omheen hangt (terecht of onterecht) hebben wij ervoor gekozen een andere license te gebruiken om hetzelfde af te dwingen.

[...]
Dat klopt maar het ligt er aan hoe je het bekijkt. Omdat GPL strenge regels opstelt is het moeilijker te combineren met andere code. Ik ben er ook blij me. Ik ben er van overtuigt dat in het geval de GPL code onder een MIT/BSD license uitgeven zouden zijn zou een bedrijf als Microsoft allang delen van deze code gebruikt hebben (wat ook geheel legaal zou zijn). Dan zou je in direct je eigen graf gegraven hebben. Zeker omdat Microsoft veel machtiger en commercieel sterk is dan een OSS project.

Even los van het feit dat ik helemaal niet wil zeggen dat iedereen alles maar onder een permissive academic license zoals MIT/BSD moet uitbrengen (zoals gezegd: er zijn meer reciprocal licenses dan alleen de GPL), zie ik niet in hoe je daarmee je eigen graf zou graven. Doet het feit dat Microsoft de BIND DNS code gebruikt zonder daar iets voor terug te geven (aangenomen dat dat waar is) iets af aan de waarde die BIND voor de rest van de wereld heeft?

[Verwijderd]

Nog afgezien van het feit dat "statisch en dynamisch linken" in veel programmeertalen helemaal geen betekenis heeft, is het gezien de laatste regel op deze pagina duidelijk de bedoeling dat elk programma dat gebruik maakt van code die onder de GPL valt, zelf ook onder de GPL moet vallen.

In de meeste moderne talen heeft het of een betekenis of het is altijd dynamisch gelinkt of wat er op lijkt. Bij C(++) kun je het aangeven en bij bijvoorbeeld Java is het altijd dynamisch c.q. libraries worden nooit een integraal deel van je object file.

In de regel die je aanhaalt is er geen verschil gemaakt tussen dynamisch en statisch. Daarbij is het artikel heel oud. Als je bijvoorbeeld naar de opmerking van Linus in het Novell artikel in de latere post op de kernel mailing list. Dan is de mening al meer genuanceerd. Ik weet het niet hoe het juridisch precies zit, misschien is het wel een gedoogbeleid ivm NvIdia en ATI/AMD modules.
Om dit te voorkomen is een dual license GPL & LGPL natuurlijk ook een mogelijkheid dan zul je dit probleem nooit hebben.

Doet het feit dat Microsoft de BIND DNS code gebruikt zonder daar iets voor terug te geven (aangenomen dat dat waar is) iets af aan de waarde die BIND voor de rest van de wereld heeft?

Nee Bind niet maar de IP stack wel. Ze zonder enige kosten zich heel snel op het niveau van hun concurrenten kunnen komen. Wat in mijn ogen gerust mag, maar een bedankje kan er toch wel af. Onder GPL zou dit bedankje geforceerd zijn.

Het is duidelijk dat je liever een BSD/MIT achtige licentie hebt dan een GPL license terwijl het voor mij precies andersom is. Daar kunnen we heel veel posts aan wijden maar ik verwacht niet dat ons beider mening niet zal veranderen.

Dat is ook een van de voordelen van OSS "the freedom of choice" met een kanttekening dat het soms licentie conflicten oplevert.

[Herko_ter_Horst]

Het is wat lastig discussieren als je blijft hameren op GPL vs MIT/BSD terwijl ik al vele keren heb aangegeven dat het gaat over reciprocal licenses (dus NIET academic licenses zoals MIT/BSD).

Nog één keer op een rijtje:
1. Als eindgebruiker maakt het me niet uit, als het maar "echt" gratis is, dus geen shareware, crippleware of andere verborgen "features". Vanuit mijn ontwikkelaars achtergrond geeft Open Source me wel een beter gevoel dan gratis proprietary software.
2. Als ontvangende ontwikkelaar heb ik het liefst een Open Source license met zo min mogelijk restricties, d.w.z. een academic license zoals MIT/BSD, omdat ik dan zelf de meest vrije keuze heb.
3. Als uitgevende ontwikkelaar kies ik voor een license die de juiste balans biedt tussen bescherming van mijn rechten, bescherming van de rechten van ontwikkelaars die mijn software willen gebruiken en bescherming van de rechten van de eindgebruiker.

In de meeste gevallen zal dat een reciprocal license zijn die eist dat veranderingen aan de software worden "teruggegeven" (nadruk op bescherming van de community). Een license vergelijkbaar met de LGPL dus (wij gebruiken echter niet de LGPL maar de OSL, om een aantal praktische redenen die ik in eerdere posts heb aangegeven). Ik kies NIET voor de GPL omdat ik het niet nodig vind om bij ongewijzigd gebruik van de library te eisen dat de gebruikende software ook GPL is. Deze regel, die uitgaat boven de LGPL en andere reciprocal licenses, komt voort uit de filosofie van de FSF die "ownership" van software verwerpt. Hier ben ik het pertinent mee oneens.

Daarnaast kies ik in bepaalde gevallen ook als uitgevend ontwikkelaar voor een academic license, bijvoorbeeld omdat ik het belangrijker vind dat mijn software overal (ook in projecten met een andere license, en desnoods ook in proprietary projecten) gebruikt kan worden.

Misschien maakt het volgende lijstje duidelijk hoe ik de diverse categorieen zie.

Wat is per categorie het antwoord op de vraag:
Mag ik software S, uitgegeven onder X, (al dan niet aangepast) gebruiken in mijn eigen software T, uitgegeven onder Y?

X = Proprietary license: Nee
X = "Free Software" license (GPL): Nee, tenzij Y == X
X = Reciprocal license (LGPL, OSL): Ja, mits je veranderingen aan S zelf onder X teruggeeft
X = Academic license (BSD, MIT): Ja (mits je copyright notices intact laat)
X = Public Domain: Ja! Doe wat je wilt!

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Verwijderd]

Het is wat lastig discussieren als je blijft hameren op GPL vs MIT/BSD terwijl ik al vele keren heb aangegeven dat het gaat over reciprocal licenses (dus NIET academic licenses zoals MIT/BSD).

Dat klopt er zijn veel reciprocal licenses.

Hoe zou OSL omgaan met zeg openoffice als dit onder deze license zou vallen. Iemand zou een module ontwikkelen om een file in formaat x op te slaan? Ik zou het liefste zien dat deze op dat moment ook onder OSL zou vallen.

Terwijl in het omgekeerde geval de code niet onder OSL zou vallen. De module is OSL maar de rest is gesloten commercieel.

Ik vind in den beginne zeker bij heel nieuwe code GPL ideaal. Lees een project dat direct OSS project opgestart wordt zodat de code maximaal terug kan komen naar de community. Terwijl ik ook licenses zoals Sun bijvoorbeeld gebruikt ook begrijp zij hebben meer rechten op openoffice dan contributers. Hoewel ik vind dat dit na een lange tijd zou moeten verlopen als de inbreng van Sun substantieel minder is dan de niet Sun contributers.

Binnenkort word ik zelf ook gedwongen om naar license te kijken. Ik ga/ben een interface aan het ontwikkelen dat gebruik gaat maken van een module die ik wil OSSen. Maar omdat de rest van de code niet vrijgegeven mag worden zal ik hier een license voor moeten hebben die dit deel ook beschermt. Maar ik wil wel dat alle ontwikkel effort terug komt in de module.

Ik zou ook meer voor license zijn waar het actieve brengen in staat ipv het min of meer passieve van (L)GPL.

Van de andere kant begin ik bang dat niemand nog iets van de verschillende licenses snapt. Er ontstaan meer en meer licenses. Waarvan er sommige maar marginaal verschillen. http://freshmeat.net/faq/view/48/
Daar nog niet eens Microsoft licenses bij:
http://www.microsoft.com/...ensingbasics/default.mspx

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:48]

[Herko_ter_Horst]

OpenOffice valt onder de LGPL. De voorwaarden daarvan zijn vergelijkbaar met de OSL, voor waar het het teruggeven van aanpassingen betreft. Artikel 1b en 1c van de OSL, drukken voor zover ik weet hetzelfde uit als artikel 1 en 2 van de LGPL (versie 2.1).

Het is dus mogelijk om OpenOffice code in ongewijzigde vorm te gebruiken binnen andere software (even afgezien van wat artikel 5 LGPL precies betekent), ook als die software niet onder de LGPL valt. Ook is het mogelijk modules te maken voor OpenOffice die niet onder LGPL vallen. Wel is het zo dat de project leiding van OOo eist dat alle code die echt aan het OOo project zelf wordt bijgedragen onder de LGPL valt, maar dat is een eis van het project, niet van de license zelf.

M.b.t. tot jouw project: ik begrijp niet helemaal wat je gaat doen? Je gaat een interface maken voor module, dat begrijp ik (bedoel je met interface trouwens een User Interface of een Application Programmer's Interface?). De interface wordt Open Source software. Maar de module zelf is/wordt dat niet?

Ik zou ook meer voor license zijn waar het actieve brengen in staat ipv het min of meer passieve van (L)GPL.

Deze zin begrijp ik niet, kun je dat uitleggen?

Met betrekking tot de grote hoeveelheid licenses: de Open Source Initiative is begonnen met het rubriceren van de verschillende Open Source licenses: http://www.opensource.org/licenses/category
Dit om de keuzes duidelijker te maken en "license proliferation" tegen te gaan. Kies bij voorkeur een license uit één van de eerste 3 categorieen (Popular, Special purpose, Other/Misc).

Wat je ook kiest: licensing is complexe materie. Laat je, zeker als je bedrijfsmatig iets gaat doen, goed voorlichten door een jurist met verstand van deze zaken.

En kies niet "by default" de GPL, omdat iedereen dat doet

[Verwijderd]

OpenOffice valt onder de LGPL. De voorwaarden daarvan zijn vergelijkbaar met de OSL, voor waar het het teruggeven van aanpassingen betreft. Artikel 1b en 1c van de OSL, drukken voor zover ik weet hetzelfde uit als artikel 1 en 2 van de LGPL (versie 2.1).

Ik was in de veronderstelling dat OpenOffice ook de CDDL gebruikte net als OpenSolaris.

Mijn projectje is het volgende.
Een kernel driver en library en een Java library die ik onder een OSS wil brengen. Waarschijnlijk bestaat de kernel module al binnen OSS project, mogelijk dat er aanvullingen in moeten komen.
Het boven liggende programma zal geheel gesloten blijven. Omdat de opdrachtgever dit eist. Wat ook begrijpelijk is.
Ik wil de libraries OSSen omdat deze bruikbaar voor anderen kunnen zijn en de library daardoor mogelijk ook verbeterd zal worden.

<q>
Ik zou ook meer voor license zijn waar het actieve brengen in staat ipv het min of meer passieve van (L)GPL.
</q>

Deze zin begrijp ik niet, kun je dat uitleggen?

De (L)PGL zegt dat je bij afvraag de source code moet leveren. Ik zou liever zien dat de gene die de code commercieel inzet de source code direct actief moet beschikbaar stellen. Wat er op neer dat sommige code nooit meer terug komt, terwijl de gene zie de software commercieel inzet zich netjes aan de license heeft gehouden.

[Little Penguin]

Om even je laatste zin eruit te lichten:

Free Software < Open Source

Als gebruiker van software ben ik het daar dus niet mee eens, ik vind Free Software absoluut niet minder dan Open Source - ik als gebruiker heb bij Free Software zelfs meer rechten als bij de meeste open source software.

Als het om het ontwikkelen van software gaat (en dan met name de commerciële exploitatie) dan heb je wel een punt. De ontwikkelaar wordt verplicht om de code vrij te geven (als daar om gevraagd wordt), als er sprake is van distributie...

Het is dus maar net hoe je het bekijkt...

[Verwijderd]

Als gebruiker van software ben ik het daar dus niet mee eens, ik vind Free Software absoluut niet minder dan Open Source - ik als gebruiker heb bij Free Software zelfs meer rechten als bij de meeste open source software.

Dit zal best in veel gevallen kloppen maar zeker niet in alle Free Software kan ook met "Absolutely no warranty" geleverd worden. Als een fabrikant bijvoorbeeld dmv van zijn free virus scanner een commerciële variant wil laten kopen zal dat best gelden. Wat me vaak opvalt bij free windows software is dat deze na installatie helemaal niet free blijkt te zijn. Ze willen je bijvoorbeeld na 30 dagen laten betalen c.q. je hebt dan een license nodig.

@Herko_ter_Horst,

OK, dan slaat mijn reactie nergens op.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:48]

[Herko_ter_Horst]

Pas even op: het gaat hier om de specifieke term "Free Software" zoals gedefinieerd door de Free Software Foundation. In de praktijk: software uitgebracht onder de GPL.

Het gaat níet om "gratis", "shareware" of "time-restricted" software die je gratis kan downloaden.

[Verwijderd]

Pas even op: het gaat hier om de specifieke term "Free Software" zoals gedefinieerd door de Free Software Foundation. In de praktijk: software uitgebracht onder de GPL.

Ook dat valt wel mee, er zijn meer licenses die compatible zijn met het Free Software idee, waarvan Public Domain en Copyleft waarschijnlijk de bekendste zijn.

[Herko_ter_Horst]

Onjuist.

Public Domain is geen license. Het is de staat van het ontbreken van copyright en license. Software in het Public Domain heeft geen restricties. Afgeleide werken kunnen dus óók proprietary zijn, iets wat de GPL/Free Software beweging specifiek tegen wil gaan.

Copyleft is ook geen license, maar een term voor een type licentie waarin het "teruggeven" van wijzigingen onder dezelfde (of een vergelijkbare) licentie is geregeld. GPL is een Copyleft licentie. Maar bijvoorbeeld de Open Software License (OSL) is óók een Copyleft license, maar géén Free Software license.

Public Domain software is inderdaad wel compatible met Free Software (je mag er immers alles mee, inclusief het onder een Free Software license uitbrengen), maar lang niet alle Copyleft software is dat.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Herko_ter_Horst]

Sorry, ik bedoelde het anders: Free Software is een invulling van Open Source met extra ideologische restricties. Ik pas mijn reactie hierboven aan.

[Verwijderd]

Eerst is het allemaal gratis en eenmaal goedlopend mag je betalen. Vanaf dag 1 al de opzet geweest van opensource software maar om zich eerst in te burgeren moest men een vuist maken tegen de gevestigde orde.

Niks mis mee voor de rest maar in het leven is het nu eenmaal een feit dat niets gratis is en je uiteindelijk toch de rekening betaald

[Gerco]

De licentie van de meeste open source software (GPL of niet) garandeert dat de software nu en voor altijd vrij is en zal blijven. Het is niet mogelijk dat er opeens geld gevraagd gaat worden voor de Linux kernel ofzo.

Wat wel mogelijk is, is dat de ontwikkelaar nieuwe versies tegen betaling gaan aanbieden, maar wat eenmaal gereleased is onder een open source licentie zal altijd vrij blijven.

Er is overigens niets mis met het aanbieden van betaalde diensten voor open source software, programmeurs moeten ook eten en bedrijven verdienen genoeg met het gebruik ervan, iets terugdoen mag ook wel een keer.

[poepkop]

Ik vind het zelfs een hele goede oplossing. Normaal wordt oss toch in de vrije tijd geschreven en wordt er soms geld voor ondersteuning gevraagd. Maar nu kan iemand een request doen en daar geld voor geven, zo heeft de progammeur een motivatie om aan zijn project verder te werken en wanneer het af is wordt het weer online gezet voor iedereen!

[Herko_ter_Horst]

Normaal, normaal, wat is normaal? Qua aantal projecten zal je waarschijnlijk gelijk hebben, maar ik vraag me af je qua regels code ook nog steeds gelijk hebt. OSS is behoorlijk uit het hobby-hoekje gekropen.

Er zijn namelijk inmiddels behoorlijk wat Open Source bedrijven die "gewoon" mensen in dienst hebben om aan die Open Source software te werken. MySQL A.G. is wel het bekendste voorbeeld. Maar ook RedHat/JBoss en vele anderen hebben de ontwikkeling van Open Source software als core business (met natuurlijk de verkoop van diensten en/of proprietary licenties als inkomstenbron).

* Herko_ter_Horst werkt ook betaald aan Open Source software

[J.J.J. Bokma]

Wat in mijn ogen jammer is, is dat niet iedere programmeur zin heeft in support, en dat professioneel support aanbieden iets anders is dan de programmeur van het pakket zijn (dat klinkt vreemd, maar kijk maar eens rond, dan zie je zelf dat support vaak door een professioneel bedrijf wordt gedaan en niet door de programmeur(s), tenzij die laatste in dienst zijn van dat bedrijf).

[Verwijderd]

Volgens mij is de support wat je bedoeld, Ik heb namelijk het gevoel dat de eerste en tweedelijns support bedoel. user en configuratie support, niet de strekking van de suport van de ontwikkelaar is maar door experts. Derde lijns support en toevoegen van features wordt zeker door de programmeur(s) gedaan, ook binnen commerciële bedrijven.

Dat wil niet zeggen dat eerste en tweedelijns support niet gedaan wordt door OSS programmeurs.

Het is ook niet zo dat iedereen die mee werkt binnen een OSS project allemaal programmeurs zijn. Er zijn vaak ook vertalers, testers, etc zo'n tester zou zich kunnen aanbieden als eerste en/of tweedelijns support persoon.

Mensen die eerste en tweedelijns support willen aanbieden kunnen dit ook via de source forge marketplace. Dit kunnen heel bekwame gebruikers zijn die vaak ook nog een groot OSS netwerk achter zich hebben.

Ik adviseer een keer naar take a tour op: http://sourceforge.net/services/buy/index.php te gaan.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:48]

[Verwijderd]

Eerst is het allemaal gratis en eenmaal goedlopend mag je betalen. Vanaf dag 1 al de opzet geweest van opensource software maar om zich eerst in te burgeren moest men een vuist maken tegen de gevestigde orde.

Volgens mij is helemaal niet goedlopend. Zie:

Eind november maakte SourceForge bekend dat er in het derde fiscale kwartaal een verlies was gemaakt van 1,1 miljoen dollar.

Op zich IMO helemaal niets mis met hun aanpak. Ze brengen software ontwikkelaars en bedrijven samen. Waardoor:
1) De site als gratis site kan blijven bestaan.
2) Ook OSS ontwikkelaars een centje bij kunnen verdienen.
3) Bedrijven goedkopere en mogelijk betere software krijgen. Ze hebben namelijk meer keuze en mogelijk de ontwikkelaar van een bepaald pakket. Zodat een aanpassing sneller gedaan kan worden.

[Little Penguin]

Eerst is het allemaal gratis en eenmaal goedlopend mag je betalen. Vanaf dag 1 al de opzet geweest van opensource software maar om zich eerst in te burgeren moest men een vuist maken tegen de gevestigde orde.

Waar haal je het idee vandaan dat het de opzet geweest is dat je voor open source software moet betalen? Natuurlijk kunnen bedrijven als RedHat, Novell, MySQL, Mozilla, etc niet zonder inkomsten, maar dat staat nog niet gelijk aan het feit dat je voor open source zou moeten gaan betalen.

Bij RedHat, Novell en MySQL betaal je voor de support op de producten, niet voor het product zelf - hooguit voor de distributie ervan. Bij MySQL komt daar dan nog bovenop dat als je een licentie afsluit je de code in een close source omgeving mag gebruiken (dit is mogelijk omdat MySQL de eigenaar (copyright houder) van alle code is en zelf mag kiezen onder welke licentie de code verspreidt wordt).

In het geval van Mozilla worden de inkomsten gegenereerd door de advertenties die zichtbaar zijn bij de zoekmachines.

In al deze gevallen zijn er inkomsten, maar daardoor is het doel van de gebruikte open source licentie niet het genereren van inkomsten - die worden op een andere manier gegenereerd.

[Verwijderd]

De software blijft gratis. Alleen aanvullende diensten kosten geld. Dat hoef je niet te gebruiken.

[Verwijderd]

Zo begint het toch altijd? Eerst zijn de aanvullende diensten de dingen die je toch niet gebruikt/nodig hebt als simpele gebruiker en drie versies later is zelfs het opslaan van je gebeuren ineens een aanvullende dienst.

[Verwijderd]

Volgens mij heb je op dit moment een commerciële software bril op. Iedere aanvullende dienst zal daar inderdaad geld kosten.

Bij OSS software zal iedere zinvolle toevoeging (als je een van de ontwikkelaars overhaalt, je kunt het natuurlijk ook zelf doen maar dat is niet de essentie van de market place) in het OSS project komen. Zodra er iemand geld voor zal geven kunnen er toevoeging in komen die de ontwikkelaar niet echt zinvol vind of het programmeer werk kan naar voren geschoven worden (een ontwikkelaar heeft uiteindelijk ook zijn prioriteiten).

Afhankelijk van de license zal de veranderde code ter beschikking van iedereen staan. Onder GPL zal dit zeker het geval zijn, mits het geen module is.

IMO is er alleen een win win situatie voor OSS software.

Bedrijven krijgen betere support, projecten kunnen zich sneller ontwikkelen. OSS ontwikkelaars kunnen full time OSS ontwikkelaar worden als ze die kans nog niet hadden.

[GeniusDex]

Mocht dat gebeuren zijn er alternatieven genoeg waar veel projecten heen zullen gaan. De kracht van SourceForge is juist dat het gratis is; als dat het niet meer is zal het hele project in elkaar storten.

[J.J.J. Bokma]

Natuurlijk, en iedereen gaat dan opzoek naar een fork? Hoeveel mensen denk je gaan forken om speciaal voor mensen die echt alles gratis willen aan de slag te gaan? Ik denk dat juist meer mensen liever zich gaan specialiseren in een gewild OS pakket, om er zo support op te leveren.

[Verwijderd]

Het gaat niet om gratis vs. niet-gratis, het gaat om vrij vs. niet vrij. Een programma dat een proprietaire toevoeging nodig heeft om van de basisfunctionaliteit gebruik te kunnen maken is nauwelijks meer vrije software te noemen - reken maar dat er dan een fork komt. Bovendien, een programmeur die al van te voren van plan is zijn product in crippleware te veranderen zal heus niet voor een "open" licentie kiezen.

[Verwijderd]

@J.J.J. Bokma

Hoeveel mensen denk je gaan forken om speciaal voor mensen die echt alles gratis willen aan de slag te gaan?

IMO is en zal dit nooit de reden van een fork zijn mijn gevoel zegt da meestal license of verschil van inzicht de reden van een fork is:
Enkele forks zijn de xfree86 fork naar de xorg fork. Dit was een license issue.
Compiz naar Beryl omdat een groep ontwikkelaars het niet eens was met de gang van zaken. Ze zijn nu weer bij elkaar onder de naam Compiz-Fusion.

Ik denk dat juist meer mensen liever zich gaan specialiseren in een gewild OS pakket, om er zo support op te leveren.

Deze mensen kunnen terecht als eerste en tweedelijns support op de market place. Een onwikkelaar zal dit zeer waarschijnlijk niet doen en zich bezig houden met derde lijns support en feature requests. Ik denk dat beide groepen graag hun diensten willen aanbeieden.

Er toch niets mooier dan je met je hobby bezig te houden, en daar voor betaald krijgen.

[Verwijderd]

En dat is weer precies waarvoor de oss staat geloof ik...

[Fireshade]

Yep, en je mag er zelf ook aan sleutelen ("aanvullen").
Dus je hoeft de originele ontwikkelaar nog steeds niks te betalen, als je het zelf kunt.

[Emielio]

Gezien Parabellum's berichtgeschiedenis schat ik zo in dat hij een oss voorstander is die oss tegenstanders dom wil laten lijken door domme opmerkingen te maken.

[Dima_2005]

Wel, dat is een vaak gebeurt misverstand, open-source is niet altijd gratis

[Herko_ter_Horst]

Open Source is wél altijd gratis. Tenminste, voor zover het gaat om het verkrijgen van de source code: die moet (wil de licentie voldoen aan de Open Source Definition) vrijelijk beschikbaar én (in ongewijzigde vorm) verspreidbaar zijn. Ook moet je de source voor eigen gebruik vrij mogen aanpassen en gebruiken. Als je de aangepaste source/binaries gaat verspreiden krijg je te maken met de specifieke restricties van de licentie waaronder de oorspronkelijke code is uitgegeven.

Dit houdt in dat je altijd gratis een werkend programma kunt krijgen door de (gratis) source te downloaden, te compileren en te draaien.

Dat wil niet zeggen dat je geen geld mag vragen voor allerlei zaken eromheen. Als jij Open Source software compileert, op een CD/DVD brandt en er een leuk doosje omheen doet, mag je daar best geld voor vragen (zie alle commerciele Linux distro's). Als je support of andere diensten levert op Open Source software, mag je daar best geld voor vragen.

Trouwens: Open Source != GPL. De GPL is min of meer "toevallig" óók compatible met de Open Source definitie. Er zijn echter véél meer Open Source licenties dan alleen de GPL (teveel zelfs, maar dat is weer een ander verhaal).

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Little Penguin]

Open Source is wél altijd gratis. Tenminste, voor zover het gaat om het verkrijgen van de source code: die moet (...) vrijelijk beschikbaar én (...) verspreidbaar zijn.

Vrijelijk beschikbaar is niet gelijk aan gratis beschikbaar, daar zit een enorm gat tussen.

Ook moet je de source voor eigen gebruik vrij mogen aanpassen en gebruiken. Als je de aangepaste source/binaries gaat verspreiden krijg je te maken met de specifieke restricties van de licentie waaronder de oorspronkelijke code is uitgegeven.

Als ik een product maak, gebaseerd op de Linux kernel en ik verkoop dat product voor 1000EURO dan kan is mijn product verre van gratis. De broncode hoef ik alleen maar beschikbaar te stellen aan de ontvangers van mijn product, dat zij de vrijheid hebben om die weer gratis beschikbaar te stellen is een tweede - maar dat maakt mijn product nog niet gratis...

[Herko_ter_Horst]

Als jij een product maakt gebaseerd op de Linux kernel (d.w.z. een afgeleid werk van de Linux kernel) dan heb jij je te houden aan de GPLv2 waaronder de Linux kernel is uitgebracht. Dat wil zeggen dat jij de source code van jouw product ook onder de GPLv2 moet uitbrengen. Wat weer tot gevolg heeft dat je die gratis(*) ter beschikking moet stellen.

Dus de eerste gebruiker die wél 1000 euro heeft betaald het recht de source code te verspreiden. Kijken hoeveel exemplaren jij daarna nog verkoopt.

Er is voor zover ik weet geen enkele "commerciele" aanbieder die dit als een valide business model ziet. Je betaalt altijd voor éxtra zaken die niet direct te herleiden zijn tot de source.

(*) of zo goed als gratis

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 16:48]

[Verwijderd]

Open source != GPL

[Herko_ter_Horst]

Dat was al gezegd

[farlane]

Niets staat mij in de weg om voor een klant een stukje software te leveren op basis van GPL'ed software en daar, om maar eens een dwarsstraat te noemen, 30K voor te vragen.

Die software zal helemaal niet snel ergens anders terecht komen want mijn klant heeft helemaal geen behoefte om ontwikkelwerk voor anderen te betalen.

Bottom line is, omdat hij de source erbij krijgt, dat hij de keuze heeft om dat wel of niet te doen. Hij wordt alleen door mij niet gedwongen tot een bepaalde keuze, zoals bij veel closed software wel het geval is.

[Herko_ter_Horst]

Dat is inderdaad een mogelijkheid. Ik denk echter dat geen enkel bedrijf z'n business model hierop zal baseren. Er hoeft maar één klant te zijn die er anders over denkt en jij verkoopt die software nooit meer.

[farlane]

Dit zou heel goed kunnen werken als je ( zoals wij dat doen ) maatwerk levert voor je klanten.
.

[Verwijderd]

OM in te zoomen op de GPL.

Dit is de situatie voor GPLv2:

3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software
interchange; or,

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)

De kosten voor GPLv2 zijn in ze administratie en media kosten.

Dit is GPLv3:

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

* a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
..
etc

GPL 3 zergt het zelfde ook alleen administratie en media kosten.

BSD license ed zijn geheel anders. Dit is een link naar vele type licenties: http://freshmeat.net/faq/view/48/

[martijn_brinkers]

De kosten waarover wordt gesproken zijn de kosten die de 'leverancier' moet maken om de source code beschikbaar te stellen en deze dus mag 'verhalen' op de koper. De GPL zegt, IMHO, niets over het bedrag waarvoor de leverancier het aangepaste GPL programma mag verkopen aan de koper. Dat is iets dat de kopende en verkopende partij onderling afspreken. De kopende partij heeft zelf weer de vrijheid om deze aangepaste code weg te geven.

[MadEgg]

Voor zover ik begrepen heb is het enige wat de GPL zegt dat als iemand de binaries geeft, dat diegene dan ook recht heeft om de source erbij te krijgen en daar vervolgens mee te doen wat hij wil.

Neemt nog steeds niet weg dat je er dan nog steeds geld voor mag vragen. Bied je de binaries niet gratis aan, dan betaal je dus in principe ook voor de source. Dat je het daarna zelf gratis verder mag verspreiden doet daar niets aan af.

[ChevyVanDude]

Afhankelijk van de licencie idd.
Maar wat al eerder vermeld is: G(eneral)P(ublic)L(icence) is gewoon gratis, blijft gratis en je kan zelfs het gebruiken voor commercieel gebruik.
Niets beter dan dat:P

Er staan ook zeker wat degelijke projecten of SF.net, helaas ook dode (of inactieve) projecten.

[OddesE]

Lees de GPL. Gebruiken is ok, maar als je het gaat aanpassen loop je risico's (zie Verizon voor de rechter gedaagd wegens schending GPL). Risico's waar commerciele organisaties huiverig voor zijn.

Overigens, Open Source software is impliciet wél altijd gratis, hoewel je wel geld kunt verdienen aan diensten er omheen. Bestudeer de tien richtlijnen van het OSI. Je kunt geld vragen voor de download, da's waar. Maar niemand kan mij dan verbieden het gratis aan te bieden op mijn website. Dus praktisch gezien blijft het gratis.

[Verwijderd]

Risico's waar commerciele organisaties huiverig voor zijn.

Als ze netjes de licentie volgen is er geen enkel probleem. Het probleem is dat ze de verkopende afdeling niet weet dat het GPL code is of dat de licentie willens en wetens geschonden wordt.

Dit laatste deel is helaas mogelijk omdat er nooit hoge boetes op gestaan hebben. Tot nu is het als nog publiceren van de source code voldoende gebleken.

[Herko_ter_Horst]

Als je het gaan aanpassen én verspreiden...

Aanpassen voor eigen gebruik is toegestaan.

[Verwijderd]

Lees de GPL. Gebruiken is ok, maar als je het gaat aanpassen loop je risico's (zie Verizon voor de rechter gedaagd wegens schending GPL). Risico's waar commerciele organisaties huiverig voor zijn.

Hou toch eens op met dit domme gejank. Er zijn helemaal geen risico's. De regels zijn glashelder: je mag GPL software gebruiken, je mag GPL software aanpassen, je mag de aangepaste GPL software verder verspreiden, maar als je dat doet moet dat ook onder de GPL. Niks risico's, niks om "huiverig" voor te zijn.
Ga eens gesloten software aanpassen en verder verspreiden... en kijk eens wat voor "risico's" je dan loopt.

[Sijmen]

Er is niks dat je ervan weerhoudt om GPL software te verkopen, het wordt zelfs expliciet toegestaan.

[Linux_koen]

Hoezo de je bedoeld dat de diensten niet altijd gratis zijn

[stoicz]

Maar de gebruiker/klant krijgt dan wel een aangepaste versie van die software.

En het kan natuurlijk een manier zijn voor SourceForge om te kunnen blijven bestaan.

Waarom niet?

[Verwijderd]

Goed initiatief om op deze manier een platform te creeeren waarmee je de mogelijkheid krijgt om commerciele uitbreidingen of support op software aan te schaffen.
Ook bedrijven die oss maken moeten ergens hun geld vandaan halen. Dit helpt daarbij.

[mashell]

Ik weet niet of het wel zo goed is. Je kunt nu al vaak tegen dat bedrijven een open source variant en commerciële variant van hun product maken. Waarbij helaas soms de bugs aanwezig in beide versies alleen in de commerciële variant worden opgelost. Het lijkt erop dat Sourceforge nu een platform biedt voor precies dit model en dit nare gedrag daarmee impliciet aanmoedigt.