MySQL en licenties

[rogierslag]

Ik ben op het moment bezig met het maken van een intranet-omgeving, gericht op bedrijven. Deze wil ik uiteindelijk ook actief gaan verkopen aan bedrijven.

Hiervoor wil ik een servertje bij bedrijven neermikken met daarop Apache, PHP 5 en indien niet aanwezig, een database. Zelf gebruik ik voor de ontwikkeling MySQL (die was snel beschikbaar). In verband met de redelijk ondoorzichtige licentie van MySQL heb ik op het moment géén idee welke licentie ik zou moeten nemen.

Enkele punten:

• De code is gesloten en zal niet onder de GPL vrijgegeven worden
• Ik heb geen MySQL support nodig, want ik ken MySQL voldoende goed voor deze toepassingen
• De server wordt met voldoende back-upmogelijkheden uitgerust, transactions en andere exclusieve features zijn dan ook niet nodig
• Indien er al een databaseserver aanwezig is in het bedrijf (zoals MSSQL Server) wordt deze gebruikt en wordt er géén MySQL geïnstalleerd
• Vanwege de uitwisselbaarheid is er sprake van een database-transparency-layer (geen idee of het de goede term is, maar het houdt in dat de code zijn queries verstuurd met de zelfgeschreven functie execute_query en dat die vervolgens dit mapt naar de gebruikte database) zodat ook databases als PostGreSQL gebruikt kunnen worden
• Het intranet is puur intern en zal ook niet van extern te benaderen zijn

Ik ben dus een beetje de weg kwijt tussen de twee verschillende licenties die MySQL AB aanbiedt. Aan de ene kant zou de GPL versie niet kunnen, omdat mijn product geen GPL is. Terwijl aan de andere kant volgens deze pagina ik wél de community versie kan gebruiken.

Omdat de kosten van het pakket nog niet al te hoog moeten worden vindt ik het zonde om $ 595 dollar per jaar te gaan betalen. Zeker aangezien ik voor de server tegen zo´n 2500 euro aanmik en het geheel tegen 4000 euro wil leveren is die 595 eurootjes een redelijk hoge uitgave. Ook is juist mijn idee dat mensen een licentie nemen voor een aantal gebruikers en geen perikelen meer hebben met jaarlijks betalen vanwege ... Ik kan dit echter onmogelijk meenemen in de prijscalculatie.

Wat denken jullie, kan ik gewoon een GPL licentie gebruiken of moet ik toch aan de commerciele licentie?

P.S. Opmerking dat MySQL geen vereiste is, het pakket draait ook onder postgreSQL en MSSQL

[Toolskyn]

Je database is geen onderdeel van je softwarepakket? Dan kan ik me niet zo voorstellen dat je je over die voorwaarden van de GPL druk moet maken. Je veranderd immers niets aan MySQL, je gebruikt geen onderdelen van MySQL, je gebruikt puur het (binaire, gecompileerde) eindproduct. Ik denk dat je gewoon de GPL licentie kan gebruiken.

[aukema]

Denk ik ook, tenzij je natuurlijk wel kosten voor MySQL in rekening brengt...

[rogierslag]

Ik lever alleen één product bestaande uit se server, debian, apache, php en eventueel MySQL (en natuurlijk de intranetsoftware )

In principe zit in een aantal gevallen MySQL wél geïntegreerd in het pakket, maar de gebruiker kan ook postgreSQL kiezen. De combinatie maakt het in ieder geval een beetje lastig. En als MySQL mij 595 per jaar gaat kosten, ga ik dat inderdaad doorbelasten...

Verder pas ik inderdaad niks aan en spreek ik MySQL enkel aan via PHP. en eventueel de commandline mocht dat eens nodig zijn

Natuurlijk krijgt de eindgebruiker ook nog even netjes alle licenties voor zich, die hij mag ondertekenen dat hij ermee akkoord gaat

[aukema]

ik zou denk ik:
a. € rekenen voor de installatie.
b. € rekenen voor de door jou ontwikkelde software.
c. € rekenen voor onderhoud en support (20% van totaalprijs per jaar)

zodoende is duidelijk dat je niet de voor de overige software € rekent (mysql, php, linux etc)

[ Voor 21% gewijzigd door aukema op 18-11-2007 23:58 ]

[spone]

Ik denk dat Toolskyn bedoelt dat je gewoon gebruik maakt van de files die je zo downloadt vanaf de site van MySQL en niet de sources ervan in je eigen programma gaat integreren.

[rogierslag]

oops, niet duidelijk genoeg geweest.

Met geïntegreerd in het pakket bedoel ik dat het pakket de server is en dat MySQL daar op staat. Hier wordt in ieder geval gebruik gemaakt van de binary versie.

Zogezegd kom ik met de server met alles daarop aanlopen bij het bedrijf en dat is wat ze gekocht hebben. Dat er MySQL en PHP5 opstaat boeit de meeste mensen verrekt weinig zolang het prima werkt en binnen het budget past

MySQL zal nooit via de source of iets worden geïntegreerd in de zelfgeschreven software, laat dat duidelijk zijn

[rogierslag]

Even én een kickje én het aandragen van een nieuw punt.

Indien de gebruiker (het bedrijf dus) de server zelf installeert dus inclusief MySQL, hoe verloopt het dan met licenties. Ik ben er vrij zeker van dan dan de GPL licentie opgaat als ze geen ondersteuning nodig hebben, maar 100% zeker ben ik niet.

Iemand die zijn licht erover wil laten schijnen?

[Robtimus]

Waarom moeilijk doen? Je zegt zelf dat je postgreSQL support. Deze is onder de BSD licentie uitgegeven, en met deze mag je hoe dan ook wat je wilt. Gebruik dus gewoon postgreSQL als default als er geen andere database server aanwezig is ipv MySQL. Als de klant dan zelf al MySQL gebruikt, prima, maar die is dan geen onderdeel van jouw pakket.

[leuk_he]

rogierslag schreef op dinsdag 20 november 2007 @ 22:34:
Indien de gebruiker (het bedrijf dus) de server zelf installeert dus inclusief MySQL, hoe verloopt het dan met licenties. Ik ben er vrij zeker van dan dan de GPL licentie opgaat als ze geen ondersteuning nodig hebben, maar 100% zeker ben ik niet.

Dan is het bedrijf verantwoordelijk.

Maar buiten dat punt: als je genoeg aan de features van de community server hebt kun je denk ik die gebruiken. Het essensiele onderdeeel van de gpl is echter of de MYSQL de libary gelinkt wordt aan je applicatie, of dat ze zodanig ontkoppeld zijn dat het geen onderdeel van je applicatie uitmaakt.

in gplv2 termen:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Ik denk dat je gewoon de gpl versie van de mysql kunt gebruiken. Als je het packaged in een installer is het wellicht handig de (L)gpl componenten in losse packages te includen.

Bedenk wel dat als je zelf de mysql (community) version gaat distibueren, dat je ook de source moet kunnen aanbieden. dus die ter download zetten op je site is niet optioneel. (en waarom zou je dat archive ook niet gewoon op de installtie media zetten... kost niks)

Als je mysql gaat aanpassen valt dat uiteraard onder de gpl, echter een connectie maken met mysql levert neit op dat je applicatie gpl moet worden. zo werkt gpl niet. netzo goed dat je met je closed source internet browser met een gpl webserver kunt browsen.

Voor backup scripts enzo, en het spul wat dichter bij de database ligt is het wellicht verstandig niet closed source te gaan. Dan kom je wel op wankel gebied. maar ik denk dat dat niet je vraag is.

de GPL faq is echter duidelijker dan ik kan bewoorden.

[Soultaker]

Ik ben het min of meer met leuk_he eens. Het is nogal verwarrend omdat MySQL AB verschillende licenties voor verschillend gebruik aanbiedt, en ze zelf nogal onduidelijk zijn over het verschil tussen de broncodelicentie en wat je met een gecompileerd product mag doen.

Jij wil duidelijk niet MySQL aanpassen, en er ook niet mee linken (communiceren via een netwerkverbinding wordt in het algemeen niet als linken gezien), dus zou je in commerciële applicatie prima kunnen samenwerken met een GPL-licensed versie van MySQL. Zoveel staat vast.

Dan komt dus de vraag of je MySQL mag distribueren. MySQL AB zegt zelf:

MySQL Products are available under the "dual licensing" model. Under this model, users may choose to use MySQL products under the free software/open source GNU General Public License (commonly known as the "GPL") or under a commercial license. ISVs and Resellers, who are embedding and reselling MySQL as part of their own commercial solutions, can purchase a MySQL commercial license. See our OEM products page for details.

Het accent op embedding and reselling heb ik toegevoegd; naar mijn idee is het geen embedding als je een ongewijzigde GPL'ed versie meedistribueerd. Dan zou het dus gewoon kunnen.

[ Voor 14% gewijzigd door Soultaker op 20-11-2007 23:57 ]

[Gomez12]

Ach tja, hoe ik het altijd zie : Heb je de broncode van mysql nodig dan commerciele licentie, anders gpl licentie, behalve als je echt geld vraagt voor jouw mysql instantie ( oftewel, 500 euro voor het standaard pakket, als u geen db server heeft kunnen wij u mysql aanraden en leveren voor 250 euro ).
Hierbij wel in het achterhoofd houdend dat ik wel altijd een losse mysql installatie doe, ik ga hier dus geen luxe installers voor maken die alles automagisch invullen na mijn installer, nee als laatste actie in mijn installer start ik gewoon even setup.exe op van mysql, wat de mensen hier invullen mogen ze zelf weten.

Dit puur geredeneert vanuit het feit dat elk bedrijf de gpl versie mag downloaden en gebruiken voor eigen gebruik, linux versies mogen het meeleveren op hun cd's dus ik mag de installer ook wel meeleveren en opstarten.

[Soultaker]

Gomez12 schreef op woensdag 21 november 2007 @ 00:33:
Heb je de broncode van mysql nodig dan commerciele licentie, anders gpl licentie, behalve als je echt geld vraagt voor jouw mysql instantie

Wat heeft geld vragen ermee te maken? De GPL staat expliciet toe om geld te vragen voor het distribueren van free software. Ook MySQL AB maakt slechts onderscheid tussen free software (GPL of OSI-approved) en non-free software, en daar komt ook geen geld bij kijken.

[Confusion]

rogierslag schreef op zondag 18 november 2007 @ 23:12:
In verband met de redelijk ondoorzichtige licentie van MySQL

Je bedoelt dat je de GPL ondoorzichtig vindt?

Aan de ene kant zou de GPL versie niet kunnen, omdat mijn product geen GPL is.

Je moet dat onduidelijke gezwam op hun website niet geloven. Je kan het als volgt zien:
• Eerst help je het bedrijf een MySql server te installeren. Je distribueert zelf geen MySql als je het gewoon van hun website (of een van de vele mirrors) kan downloaden).
• Vervolgens lever je het bedrijf een product dat van MySql gebruik maakt. Daarvoor is geen commerciele licentie vereist, tenzij je er tegen wil/moet linken; zie Soultaker eerder in de thread.

• De server wordt met voldoende back-upmogelijkheden uitgerust, transactions en andere exclusieve features zijn dan ook niet nodig

offtopic:
Transactions zijn geen exclusieve feature (zit standaard in InnoDB) en heeft weinig met backups te maken.

[rogierslag]

Oke allemaal harstikke bedankt voor jullie antwoorden. Ik denk dat ik nou eventueel toch de GPL versie van MySQL aan bedrijven kan aanraden.

MySQL of postgreSQL zal voor een netwerk van 50 gebruikers niet veel uitmaken. Ze moeten toch wel heel veel gelijktijdige requests gaan doen voordat één van de twee zwakker gaat presteren (zelf getest op voorbeelcode van het project). Die 2 milliseconden waarop de ene sneller is gaat niemand de kop kosten, aangezien voor het testbedrijf de verbinding vervolgens door een hele reeks firewalls heengaat, het internet op, en vervolgens bij de andere vestiging weer eens door een hele zwik firewalls binnenkomt. Dan komt er toch meer dan 2 ms vertraging

verder wordt er via PHP verbinding gemaakt naar de server met MySQL, dat vind ik ook geen linken

[Olaf van der Spek]

Soultaker schreef op dinsdag 20 november 2007 @ 23:55:
Jij wil duidelijk niet MySQL aanpassen, en er ook niet mee linken (communiceren via een netwerkverbinding wordt in het algemeen niet als linken gezien),

Welke client-side implementatie van het MySQL protocol gebruik je dan?

[leuk_he]

rogierslag schreef op woensdag 21 november 2007 @ 19:16:
verder wordt er via PHP verbinding gemaakt naar de server met MySQL, dat vind ik ook geen linken

Olaf van der Spek schreef op donderdag 22 november 2007 @ 12:57:
[...]

Welke client-side implementatie van het MySQL protocol gebruik je dan?

Dat regelt de licentie van php toch? daar heeft mysql speciaal een exceptie voor:

http://www.mysql.com/comp...g/opensource-license.html

[Olaf van der Spek]

leuk_he schreef op donderdag 22 november 2007 @ 13:41:
Dat regelt de licentie van php toch? daar heeft mysql speciaal een exceptie voor:

http://www.mysql.com/comp...g/opensource-license.html

Dat klopt, maar Soultaker's statement leek veel algemener. Op zich is het vaag dat een PHP script dat MySQL gebruikt niet open source hoeft te zijn, maar een C++ 'script' dat MySQL gebruikt wel.

[leuk_he]

Olaf van der Spek schreef op donderdag 22 november 2007 @ 13:47:
[...]

Dat klopt, maar Soultaker's statement leek veel algemener. Op zich is het vaag dat een PHP script dat MySQL gebruikt niet open source hoeft te zijn, maar een C++ 'script' dat MySQL gebruikt wel.

Behalve dat je als C++ "script" waarschijnlijk MYSQL++ gebruikt, dat een LGPL heeft en waar je geen exceptie voor nodig hebt.

Als je zelf een closed source api voor mysql schrijft dan heb je waarschijnlijk inderdaad een probleem, maar daar is geen sprake van en ik ook niet aan waarom je dat zou willen doen, tenzij je MS of Borland bent. En zelfs dan kun je redeneren dat het via een tcp/ip verbinding vast zit, en dus niet echt onderdeel van MY/SQL uitmaakt.

[Soultaker]

Olaf van der Spek schreef op donderdag 22 november 2007 @ 12:57:
Welke client-side implementatie van het MySQL protocol gebruik je dan?

Oops, dat heb je inderdaad ook nog eens; daar had ik niet aan gedacht. Je zou dan inderdaad een niet-GPL (bv. LGPL) client library moeten gebruiken. (Maar in het specifieke geval van MySQL met PHP is daar inderdaad een uitzonderingsclausule voor.)

[Olaf van der Spek]

leuk_he schreef op donderdag 22 november 2007 @ 14:58:
Behalve dat je als C++ "script" waarschijnlijk MYSQL++ gebruikt, dat een LGPL heeft en waar je geen exceptie voor nodig hebt.

Ik heb zelf een wrapper om de C API geschreven en gebruik dus geen MySQL++. Maar ik snap niet hoe MySQL++ LGPL kan zijn terwijl de C API GPL is.

Als je zelf een closed source api voor mysql schrijft dan heb je waarschijnlijk inderdaad een probleem, maar daar is geen sprake van en ik ook niet aan waarom je dat zou willen doen, tenzij je MS of Borland bent. En zelfs dan kun je redeneren dat het via een tcp/ip verbinding vast zit, en dus niet echt onderdeel van MY/SQL uitmaakt.

Als je zelf het protocol implementeerd is er volgens mij geen probleem. Alhoewel, is het protocol documented? Zo nee, mag je dat reverse engineren?

[Creepy]

Overigens: over die TCP verbinding, er is een AGPL in de maak waarin ook dat wordt dichtgetimmerd. Oftewel: maak je een TCP verbinding met iets dat een AGPL licentie heeft dan ben je verplicht ook dat als onder een (A)GPL licentie te gaan voeren.
Edit: hij is al gepubliceerd zelfs: http://www.fsf.org/licensing/licenses/agpl-3.0.html

Vanaf MySQL versie 4 is de client GPL, oudere versies zijn LGPL en zonder problemen te gebruiken. Aangezien het MySQL protocol openlijk beschikbaar is(zie bijv. http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html) is een eigen implementatie hiervan maken, of een BSD of LGPL lib hiervoor gebruiken ook niet zo'n probleem.

[ Voor 7% gewijzigd door Creepy op 22-11-2007 15:39 ]

[Olaf van der Spek]

Creepy schreef op donderdag 22 november 2007 @ 15:38:
Vanaf MySQL versie 4 is de client GPL, oudere versies zijn LGPL en zonder problemen te gebruiken. Aangezien het MySQL protocol openlijk beschikbaar is(zie bijv. http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html) is een eigen implementatie hiervan maken, of een BSD of LGPL lib hiervoor gebruiken ook niet zo'n probleem.

Zijn er BSD en LGPL libs? MySQL++ is gebasserd op de standaard C library.
En een MySQL 3 library gebruiken lijkt me ook niet meer zo'n goed idee.