Software licenties

[ju5t]

Hoe doen jullie dit? Normaliter ontwikkelen wij voor de klant en is de klant eigenaar van de software.

Nu willen wij een abonnementservice gaan leveren op ons Content Management Systeem. Als voorbeeld situatie nemen we klant X die onze dienst voor 1 jaar afneemt. Na dit jaar besluit hij te stoppen maar gebruikt ons CMS nog steeds. Dit is in de praktijk mogelijk gezien wij een Open Source product leveren en eventuele beveiliging hiertegen gemakkelijk verwijderd kan worden. Het is ook geen hosted oplossing, maar het product staat op de server/het hostingpakket van de klant.

In hoeverre is het mogelijk dit contractueel, dan wel met licenties, tegen te gaan? Hierbij doel ik op mogelijk gerechtelijke stappen indien nodig. Onze doelgroep is voornamelijk het MKB.

[Randy]

Zend --> source encoderen.
Programmeer je source met een uniek ID, dat een connectie maakt met jouw database voor autenticatie. Geen geldige licentie, geen CMS.

[ju5t]

We kijken liever pas in een later stadium naar het encoderen van de source, voor zowel financiele als praktische redenen.

[ICTRecht]

Ik zie een probleem met betrekking tot open source. Open source licenties zijn dan wel vanuit een idealistisch doel opgesteld maar er zitten wel een paar addertjes onder het gras. Er zijn verschillende soorten open source licenties. Onder GPL mag men de software/broncode kosteloos gebruiken, aanpassen en verspreiden. Echter wel onder dezelfde licentievoorwaarden. De strekking van een dergelijke bepaling moet je ruim zien. Het kan betekenen dat je de broncode, die nauw samenwerkt met de open source CMS, ook aan derden "kosteloos" ter beschikking moet stellen.

Als de licentievoorwaarden van de open source CMS gunstig zijn, is het geen probleem om een licentiecontract op te laten stellen. Maar gezien het doel van open source zie ik dat somber in.

[Mark17]

Problemen bij abbonnements software kun je verkleinen door bij bepaalde pagina's een controle uit te voeren op jouw server via een script. Dit zou bij een script zeer makkelijk mogelijk moeten zijn. Indien je een voorbeeld nodig hebt moet je het zeggen, ik heb nog een gratis voorbeeld liggen.

[Str@nger]

Mark, probleem is dat die check eruit te halen is; de codatie daarentegen niet.

[ju5t]

Open Source is misschien nogal een onduidelijk begrip. Waar het op neer komt is dat onze software vrij aan te passen valt.

Ik dacht dat hier een licentie voor was op opensource.org, maar kan het tot nu toe niet vinden.

[ICTRecht]

Deze misschien:

http://opensource.org/licenses/osl-2.1.php

Het komt dus neer op het bovengenoemde.

"to distribute copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute shall be licensed under the Open Software License"

[Mark17]

Origineel geplaatst door Str@nger
Mark, probleem is dat die check eruit te halen is; de codatie daarentegen niet.

een combinatie is inderdaad het beste, echter is dit niet altijd een optie. indien gecombineerd een optie is dan kun je het voor 99,99% veilig maken (het blijft uiteindelijk te kraken voor de personen die dat willen).

[Str@nger]

Idd Mark, als je wilt dat iets niet te kraken is, dan moet je het niet openbaar maken.

getUP: waarom wil je dat het aan te passen is door de gebruikers, maar toch met licensies / gebruikscontract werken?
Want in principe als je het aanpast (al is het maar één . extra) is het volgens mij, jouw eigendom...(verbeter me maar als dit grote onzin is wat ik zeg)

[Dillard]

Als je je applicatie als broncode wegzet is het eenvoudig niet te beveiligen. Elke controle die je inbouwt is immers te omzeilen als je toegang hebt tot de broncode.

Enige oplossing is encoderen. Wij gebruiken Ioncube en de kosten hiervan vallen goed mee ($199,00) uit mijn hoofd. Zelfs als je wilt dat je applicatie aan te passen is, kun je ervoor kiezen om slechts enkele bestanden te coderen (zolang deze maar niet gepasseerd kunnen worden).

[Best4U]

Ik denk toch dat je met een eventuele check al een heel eind komt. Je richt je op het MKB met een open source product.

Bij het gemiddelde MKB bedrijf is over het algemeen vaak weinig kennis in huis over dit soort zaken. Als ze er echt veel verstand van hebben dan kunnen ze zelf alsnog het product orgineel weggehalen en zelf omcoden. voor zover ik weet mag je volgens open source licenties wel kosten in rekening brengen voor werk dat je verricht voor de klant om het product naar hun wensen om te vormen, maar niet voor het open source script zelf.

kortom, ik denk dat je je met een eenvoudige check al behoorlijk goed indekt en dat andere oplossingen verhoudingsgewijs toch vrij prijzig zijn.

[Designerhosting]

Het hangt allemaal af van welke open source-licentie jullie gebruiken.... Er zijn verschillende programma's waarmee je je source code kunt beveiligen, maar om dan te spreken van open source is wat overdreven..... Inderdaad is vaak het geval dat je voor diensten omtrent de open source geld mag vragen, design, specifieke aanpassingen etc.... Maar voor de software niet, deze is immers beschikbaar voor iedereen.... te downloaden en je moet hem vrijelijk beschikbaar stellen voor mensen...

[Aecius]

Het is evengoed mogelijk om via een contract of in de licentie af te spreken dat het CMS gebruikt mag worden zolang partijen een licentieovereenkomst hebben. Indien er dus geen licentieovereenkomst meer is en deze (ex-)klant blijft de software gebruiken, pleegt hij een wanprestatie en kan jij gerechtelijk een schadevergoeding eisen.

Het grote probleem hiermee is de handhaving. Hoe kom je te weten dat de klant het (jouw) CMS blijft gebruiken?

Zet gelijk in je voorwaarden dat het niet is toegestaan het CMS te verspreiden.

Mvg,

Mr. Arnoud Punt

[ju5t]

Zal het vermelden in onze voorwaarden, dan wel aparte licentie overeenkomst voldoen?

De check zal er hoe dan ook inkomen. We zullen wel zien hoeveel vaart het loopt.