Van wie is die website (met CMS)

| AE 4705 | Intellectuele rechten, Iusmentis | 68 reacties

Weer een regelmatig terugkerende kwestie: mensen laten een website bouwen, denken daar eigenaar van te zijn maar er blijkt een door de sitebouwer zelf ontwikkeld CMS achter te liggen. En artikel 18.3 van diens algemene voorwaarden bepaalt dat het eigendom daarvan “ten alle tijde” (sic) bij hem ligt. Ja, dat is rechtsgeldig ondanks die taalfout.

Hoofdregel uit het auteursrecht is dat degene die een werk maakt, de rechten daarop heeft. Ook als deze in opdracht werkt, hét grote misverstand bij online auteursrechten (oké, naast “het staat op internet en is dus vrij van rechten”). Als je dus een site laat bouwen, is die niet van jou. De site is van de ontwikkelaar en hij staat jou toe deze te gebruiken voor het doel dat in de offerte is benoemd, meer niet.

Natuurlijk kun je daar andere afspraken over maken in het contract. Een zin als “het (intellectueel) eigendom van de site ligt bij Klant” is genoeg, mits de passage ondertekend wordt en duidelijk is om welke site het gaat.

Dan is er nog één probleem: het contentmanagementsysteem oftewel CMS waarmee de site is gebouwd. Er zijn bergen opensourcecontentmanagementsystemen (zie plaatje) waarmee dit zou kunnen, maar menig ontwikkelbedrijf voelt de onbedwingbare neiging om toch zelf een CMS te bouwen. Goed, dat mag, maar het gevolg is wél dat je als klant alsnog vastzit aan dat ontwikkelbedrijf. Je zou haast gaan denken dat ze het erom doen.

De eigendom van het CMS opeisen kan, maar dan moet je wel een aparte bijzin opnemen “inclusief het achterliggende CMS” in die zin die ik daarnet noemde. Maar of de ontwikkelaar daarmee akkoord gaat, betwijfel ik. Hij kan dan immers het CMS aan niemand anders meer beschikbaar stellen. Mogelijk komt ie zelfs in de problemen met bestaande klanten die het CMS al gebruiken (hoewel dat op zich prima te regelen is met een licentie terug).

Dit probleem voorkomen kan maar op één manier: vooraf vragen met welk CMS de site gebouwd gaat worden en hoe het zit met eigendom daarvan. En dat behoort net zo’n logische vraag te worden als de verborgen gebreken bij huizen.

Arnoud

Deel dit artikel

    • Oh, met de standaard CMS pakketten zijn prima systemen mee te maken. Je kijkt nu immers ook naar een WordPress CMS systeem! 🙂 (Of heb je nu een compleet eigen ontwikkelde site, Arnoud?) Het probleem met dergelijke standaard oplossingen is vooral dat bedrijven te weinig kennis hebben om deze aan hun eigen bedrijfsstijl aan te passen en men vaak wensen heeft die de software niet standaard aanbiedt. Daarnaast moeten bedrijven ook steeds nieuwe updates installeren, wat weer lastig kan zijn als ze zelf van alles en nog wat in de (open-source) code hebben zitten wijzigen. Verder zijn van veel standaard-pakketten gevoelig voor forum-spammers en hackers die naar bekende kwetsbaarheden zoeken waardoor het zelf hosten van dergelijke standaard-pakketten extra risico’s met zich meebrengen. Niet dat een eigengemaakt systeem veel veiliger belooft te zijn, maar de kans is dan dat de forum-spambots er net niet goed mee om weten te gaan en dus niet in slagen je blog vol te pompen met spam.

  1. @Hugo: Ik denk dat je te snel gaat hierin. Je bent waarschijnlijk van nature een ontwikkelaar en denkt ook zo. Same here. Overzie ook de behoeftes van je klant. Niet je eigen voorkeur om in een bepaalde taal te programmeren.

    Wij werken zelf alleen maar met WordPress als we aan ontwikkeling doen. Ik weet niet hoe lang het geleden is dat je met WP gewerkt hebt maar daarmee zijn volledige websites te maken die niet onder doen voor andere websites. Ik ben benieuwd vanwaar en met welke insteek je jouw mening hier plaatst.

      • nu ben je eigenlijk nog steeds aan het trollen.. om bovendien niet in te gaan op de problemen die een gemiddelde ‘klant’ zal tegenkomen in het zelf-geschreven cms van het gemiddelde webontwikkel-bureau.. neem een voorbeeld kantoor met een stuk of 20 weernemers en hun geschatte it budget zoek op verschillende websites naar wat er te halen is voor ongeveer 1000 euro… en je weet wat voor bagger code je kunt verwachten… ik ben nog zelden cmssen tegen gekomen die aan dit soort verwachtingen (die jij blijkbaar hebt) voldoen en ik heb al redelijk vaak met webservers in netwerken te maken gehad…

  2. Natuurlijk wil elke ontwikkelaar een CMS bouwen, of wat dan ook bouwen want dat is hun werk. Ik ben het ook wel eens met Hugo dat de meeste OS CMS-pakketten rommel zijn. Ze zijn traag en onveilig. Natuurlijk is er bijna niets aan de hand als je direct update maar daar zijn natuurlijk ook kosten aan verbonden en de traagheid kan je niets aan doen.

    Met een klein zelf ontwikkeld CMS ben je, mits behoorlijk gebouwd, veiliger en kan je sneller en makkelijker veranderingen doorvoeren en nieuwe features maken (die het blijven doen na een update).

    • @N.P: Elke ontwikkelaar vind zijn eigen code het meest veilig ;-). En of iets rommel is bepaalt de ontwikkelaar zelf. Ik ken zelf alleen WP van binnen en buiten, maar hier heb ik veiligheid zelf in de hand.

      De flexibiliteit waarmee ik wensen van de klant relatief makkelijk kan implementeren is erg fijn bij WordPress. Bij veel custom CMS’en is het juist niet sneller en makkelijker mijn inziens. Daarnaast blijf je een soort van vendor lockin hebben. Dat is iets dat ik mijn klanten niet wil verkopen.

      Veiliger zeg je? Ook in jouw CMS kan ik gaatjes vinden :-).

      • Het pakket wat je het beste kent, werkt natuurlijk het beste en het snelst, of dat nu een custom iets is of een standaard CMS.

        Natuurlijk zitten er gaten in mijn code, ik heb niet de illusie dat ik iets bouw wat 100% veilig is maar de kans dat er een botje langskomt om deze gaten uit te buiten lijkt me bijzonder klein. Het is een beetje de reden waarom Linux minder last heeft van virussen dan Windows, niet omdat het veiliger is maar omdat het gewoon minder loont.

        Eerlijkheidshalve moet ik wel zeggen dat ik geen hele recente ervaring meer heb met die pakketten maar in het verleden was het erg vervelend om te upgraden als je diverse plugins had en nog wat customisations had gemaakt.

        • De botjes die ik heb gezien zijn wat dat betreft ook niet superintelligent. Die testen bijvoorbeeld of een van een lange lijst paden aanwezig is (wp-admin/wp-login.php, ?q=user enzovoort) en concluderen daaruit op welk systeem ze zitten, en wat de daarvoor bekende gaten zijn.

          Ik zou daaruit echter niet durven concluderen dat het hacken van zelfgebakken CMS-en niet tot op bepaalde hoogte te automatiseren is.

    • For what it’s worth: wanneer ik ontwikkelaars aanneem vraag ik ze of ze zelf wel eens een CMS hebben gebouwd. Wanneer ze daarop bevestigend beantwoorden, het een commerciele omgeving betrof, en ze desalniettemin met deze argumenten aankomen (“met een eigen CMS gaat het sneller en makkelijker”) is dat een reden voor mij om ze niet aan te nemen. Een software-ontwikkelaar anno 2012 begrijpt hoe hij of zij externe componenten of frameworks kan gebruiken om zo op efficiente wijze tot resultaat te komen. Wanneer je ervoor kiest om een kleine leercurve met als voordeel dat je uit een enorme verzameling add-ons, widgets en themes kan kiezen uit de weg te gaan en in plaats daarvan zelf een nieuw wiel gaat bouwen, dan moet je je even goed achter je oren krabben. Ik vind dat prima voor een hobbyist, maar in een commerciele omgeving is dit mijns inziens een vrij dodelijke insteek.

      NB en wanneer je iets zó kort door de bocht als ‘rommel’ kwalificeert, dan getuigt dat mijns inziens van een slecht inschattingsvermogen.

        • Je klinkt als een manager die geen bal verstand heeft van softwareontwikkeling. Jouw genoemde aanpak kan alleen maar leiden tot trage, kwetsbare websites.

          @Hugo: toen ik als 21-jarige student Technische Informatica begon bij te beunen als ontwikkelaar en ik een paar middagen lang op een snelheidsverbetering had zitten klussen, ging mijn manager mij voorrekenen dat hij voor hetzelfde geld een hardware-upgrade had kunnen aanschaffen die een aanzienlijk betere snelheidswinst had opgeleverd en verzocht hij mij vriendelijk om mijn focus te leggen op het daadwerkelijk leveren van toegevoegde waarde die hij niet op een andere wijze zou kunnen realiseren. Redenatie was dat mijn tijd een schaarser goed was dan processor cycles.

          Daarmee wil ik overigens in het geheel niet zeggen dat een ontwikkelaar geen oog moet hebben voor snelheid en performance, want ik weet als geen ander wat slechte code of een verkeerd ontworpen datamodel kan aanrichten. Ik wil er wel mee zeggen dat ik vind dat iedere ontwikkelaar in staat moet zijn om zijn eigen afweging te maken over wat wel en wat niet de moeite waard is om tijd aan te besteden.

          Ik kan met trots zeggen dat ik al jaren ontwikkelteams aanstuur, varierend in grootte tussen de twee en twintig man, die stuk voor stuk altijd hebben uitgeblonken in het ontwikkelen van snelle, veilige software. Zoals je ook niet je eigen webserver ontwikkelt (ik realiseer me dat jij een van de zeldzame personen bent waarbij dit een uitgesproken slecht voorbeeld is 🙂 ) word je ook niet geacht je eigen programmeertaal, library, database-omgeving of CMS te bouwen. Het gros van de webontwikkelaars maakt gebruik van Apache, jQuery, PHP, allemaal zaken die je zelf ook kan uitvinden, maar desalniettemin snapt iedereen de voordelen van het hergebruiken van dit soort technologie. Een slimme software-ontwikkelaar trekt dat een stukje door en snapt dat frameworks, CMS’en, webshops, content repositories en andere middleware bouwstenen zijn waarmee op handige wijze applicaties kunnen worden gebouwd.

          In de jaren 1995-1998 heb ik met een team een eigen web-applicatie-framework gebouwd en onderhouden, waar een paar grote, bekende B2C websites op hebben gedraaid. Groot succes maar het product is er ook aan ten onder gegaan. Eind jaren ’90 werden we links en rechts ingehaald door meer open, in grotere communities gebouwde technologie en kozen die klanten stuk voor stuk voor middleware waar de kennis breder van was gezaaid, zodat ze meer vaart konden maken met het uitbouwen van hun site. Ze weigerden om ons de bottleneck in hun vooruitgang te laten zijn. Toen pijnlijk, nu begrijp ik ze verdomde goed.

          Momenteel bouwen en leveren we overigens een niche-product op SaaS-basis en hebben we een aantal Nederlandse corporates als klant. Ik zeg absoluut niet dat een groot bedrijf geen software die volledig in-house is ontwikkeld mag afnemen. Dat doen ze met plezier en we zijn succesvol. Maar als we een portal of een content-publishing omgeving nodig hebben, trekken we in een paar dagen een WordPress- of Buddypress portal uit de grond, die we integreren met onze software. We kunnen dat kosteneffectief aanbieden puur en alleen omdat we OSS gebruiken.

          @N.P.

          Je maakt toch een grapje als je wel wilt dat ze WP en osCommerce aanbieden bij de “belangrijke klant (een bank of iets dergelijks) “?
          Maar jij maakt toch hopelijk ook een grapje als jij denkt dat een corporate klant ermee akkoord gaat wanneer de webbouwer een CMS of webshop inzet dat volledig in eigen huis is ontwikkeld ? Deze thread gaat niet over dat open source altijd beter is, deze thread gaat erover dat het in-house ontwikkelen vrijwel nooit beter is. Er is ook nog een categorie van commerciele software…

          • In de jaren 1995-1998 heb ik met een team een eigen web-applicatie-framework gebouwd
            ohoh, betekent dit dat je jezelf niet meer aan zou nemen 😉 ?

            Er is ook nog een categorie van commerciele software…
            En door wie wordt dat gemaakt dan?

            Natuurlijk moet je gebruik maken van OS frameworks/systemen maar om de volgende Amazon.com te baseren op WP zou ik niet aanraden. Maar zoals eerder gezegd, mijn ervaring met WP is al weer enkele jaren geleden dus misschien is het nu wel een state-of-the-art pakket.

            • @Hugo:

              ohoh, betekent dit dat je jezelf niet meer aan zou nemen 😉 ?
              Anytime na 2001: inderdaad. In de jaren ’90 was er geen goed commercieel (of open source) alternatief, later wel. Toen die alternatieven er kwamen werd elke poging tot zelfbouw een slechte keuze.

              Je blijft maar op WordPress hameren maar je verliest steeds uit het oog dat dit een voorbeeld is. Laat ik een voorbeeld wat dichter bij jouw huis zoeken. We werken samen in een bedrijf dat iets van digitale diensten levert. Jij staat aan mijn bureau en zegt “Ik heb geen goed gevoel bij de robuustheid en veiligheid van Apache of nginx, ik vind het niks, en ik vind de configuratiebestanden te ingewikkeld. Ik stel voor dat ik mijn eigen webserver ga ontwikkelen”. Op dat moment moet ik dus jouw persoonlijke belang, mening en voorkeur laten prevaleren en daarmee mijn klanten en bedrijf met allerlei risico’s en onhandigheden opzadelen. On-the-fly compressie: dat heb je niet nodig, en als je het toch wil dan doe je het zelf maar. Afhankelijk van één persoon. Omdat jij niet de configuratiebestanden van een standaard webserver wilt leren moet iedereen in het bedrijf de configuratiebestanden van jouw webserver leren. Sorry klanten, geen .htaccess, dat moet je ook niet willen, gebruik maar onze eigen proprietary oplossing. Hiawatha was dat indiaantje die denkt dat hij een grote krijger is, maar als puntje bij paaltje komt dan blijkt dat hij nog veel te leren heeft. [Overigens, don’t get this the wrong way: ik heb je software bekeken en je bent echt geen prutser, respect zelfs. Mijn punt is dat het voor veel bedrijven die weer diensten aan derden leveren, geen goed idee is om hun business op degelijke pakketten te baseren.]

              Je presenteert je als “ICT beveiligingsadviseur” maar het enige advies wat je volgens mij geeft, is om bepaalde zaken niet te gebruiken en in plaats daarvan jouw spullen te gebruiken. Wij van WC-Eend… Een goede adviseur kan ook adviseren hoe je een bestaande situatie veilig krijgt zonder meteen alles uit het raam te gooien.

              Dat je bovendien vraagt welke aanbieders er zijn van commerciële CMS’en begrijp ik niet. Of je hebt je er totaal niet in verdiept, of je maakt een grapje en ik snap het niet.

              Qua je framework: challenge accepted. Ik moet wel even tijd maken dus verwacht niet vanmiddag een mailtje.

              • De quote die je aanhaalt was niet van mij, maar van N.P. Hetzelfde geldt voor de vraag over de commerciele CMS-en.

                Daarnaast, het beschreven scenario is ook niet zoals ik het zou doen. Als ik niet tevreden zou zijn over een bepaalde oplossing (webserver, CMS), dan zou ik eerst inventariseren waarom ik er niet tevreden over ben, een tijd lang nadenken over een oplossing, deze gaan implementeren, testen, nog eens over nadenken, eventuele wijzigingen maken en mijn oplossing gaan gebruiken voor hobby-dingen. Pas als het een tijdje naar tevredenheid werkt, pas dan kom ik met mijn oplossing naast je bureau staan om het te bespreken als mogelijk alternatief.

                Wat betreft de challenge: prima, ik zie je bericht wel verschijnen op het forum of in mijn mailbox.

              • Je presenteert je als “ICT beveiligingsadviseur” maar het enige advies wat je volgens mij geeft, is om bepaalde zaken niet te gebruiken en in plaats daarvan jouw spullen te gebruiken.

                Onzin, ik heb klanten nog nooit geadviseerd om mijn software te gebruiken. Je komt daarmee namelijk totaal niet serieus over. Het is een beschuldiging die nergens op gebaseerd is.

                Wat ik echter wel adviseer is om kritisch te zijn tegen over de door een bouwer gebruikte middelen. Ga er niet standaard vanuit dat omdat de bouwer het gebruikt, het wel goed zal zijn. Want uiteindelijk zit jij met de troep. Ik raad ze vooral aan om het te gebruiken product eens door Secunia te halen en te zien wat het security verleden en huidige status van het product is. Met andere woorden: wees betrokken bij de zaken die een derde partij voor je gaat inzetten.

      • … is dat een reden voor mij om ze niet aan te nemen
        Ieder z’n ding natuurlijk maar er lijken me betere vragen voor een sollicitatie gesprek…

        Ik zou er anno 2012 ook niet aan denken om een CMS te bouwen maar de ontwikkelaar die mij aanraadt om een serieuze website te bouwen van aan elkaar geplakte modules WP en osCommerce die zal ik geen opdracht geven… Maar misschien hebben we andere projecten voor ogen.

      • Richard, ik ben het VOLLEDIG met je eens. Ik ben zelf programmeur, en ik weet ook best dat WordPress misschien niet het schoolvoorbeeld net programmeren is. Maar om te denken dat je het zelf beter kunt is je reinste arrogantie. Ja, omdat WordPress (om ons maar even aan het voorbeeld te houden) vaker gebruikt wordt en dus een groter doelwit is, worden lekken eerder geëxploiteerd. Maar omdate vele mensen de code zien worden lekken ook weer snel gedicht. Dit is bekend als Linus’ Law.

        De veiligheid van de zelfgebouwde systemen zijn bedrog. Security by obscurity. Of eigenlijk security through minority (of misschien beiden). Ik hoop heel erg dat de zelfbouwers nooit een belangrijke klant (een bank of iets dergelijks) hun houtje-touwtje CMS aansmeren, want een serieuze hacker (geen scriptkiddies) komt met z’n ogen dicht binnen.

        Ik vind het een uitstekende sollicitatievraag. Sterker nog, ik ga gelijk een mailtje sturen aan m’n manger om die op de lijst te zetten :). Sorry Hugo en N.P., jullie zijn niet aangenomen…

          • Met een klein zelf ontwikkeld CMS ben je, mits behoorlijk gebouwd, veiliger en kan je sneller en makkelijker veranderingen doorvoeren en nieuwe features maken (die het blijven doen na een update).

            Ik heb het niet over WordPress of osCommerce in het specifiek, maar in het algemeen over zelfgebouwde systemen tegenover algemeen beschikbare systemen, Open Source dan wel ‘proprietary’. Hoe groter de user base, hoe groter de kans dat bugs boven water komen. Jouw bewoording is in dezen een beetje sneaky te noemen omdat je “mits behoorlijk gebouwd” gebruikt. Daarmee kun je alle aanvallen pareren door te zeggen “ja, maar dan was het dus niet behoorlijk gebouwd”. Ik zou ook kunnen zeggen, “Met een veelgebruikt Open Source CMS ben je, mits behoorlijk gebouwd, veiliger etc..”. Het probleem zit ‘m in het behoorlijk bouwen. En ik denk dat het moeilijker is om in je eentje een behoorlijk CMS te bouwen dan met z’n velen.

            Dus, ja, als ik die belangrijke klant ofwel WordPress ofwel N.P.-CMS moet verkopen, verkoop ik hem WordPress, any day of the week. Dat wil niet zeggen dat je geen behoorlijk webbureau in de hand moet nemen om daar iets moois mee te maken, en die ervoor zorgt dat er support geleverd wordt, etc. Open Source wil nog niet zeggen dat het niets kost. De kosten worden alleen op een andere manier uitgegeven. En, om maar even on-topic te komen, ben je dan ook nog juridisch beter af, zoals we vandaag geleerd hebben. Want die belangrijke klant wil graag ook nog met zijn CMS verder als jij op vakantie gaat (naar de eeuwige jachtvelden, wellicht zelfs).

            @Arnoud: Hoe zit het moet code die ik als freelancer schrijf voor een webbureau. Is het auteursrecht daarvan, indien daar geen verdere afspraken over gemaakt worden, van mij of van mijn opdrachtgever? Ik las de discussie op http://www.frankwatching.com/archive/2011/01/11/auteursrecht-ook-belangrijk-bij-online-media/ maar daar kon ik niet helemaal uit opmaken hoe het is als er niets geregeld is. Dit ging over freelance fotografie. Beetje dezelfde vraag als ik eerder al stelde, als je een passant een foto van jou en je familie laat maken.

        • Maar om te denken dat je het zelf beter kunt is je reinste arrogantie.

          Dus je wilt hiermee zeggen dat het meest lekke, gare en slecht geprogrammeerde CMS ter wereld het beste is en daar niks boven kan!?!? Riiiight… En denken dat je het zelf beter kan doen is alleen arrogant als het je niet lukt.

          Sorry Hugo en N.P., jullie zijn niet aangenomen…
          Ik kan me ook niet herinneren dat ik gesolliciteerd heb. Het laatste dat ik namelijk zou willen is werken bij een bedrijf om daar vervolgens met WordPress aan de slag te moeten. Serieus, een ergere baan in de ICT kan ik me nauwelijks voorstellen.

          • Dus je wilt hiermee zeggen dat het meest lekke, gare en slecht geprogrammeerde CMS ter wereld het beste is en daar niks boven kan!?!? Riiiight… En denken dat je het zelf beter kan doen is alleen arrogant als het je niet lukt.

            Daarin zit ‘m nou juist de crux: Het gros van de zelfbouw-ontwikkelaars zijn nou eenmaal niet zo goed als ze zelf denken. Bij mijn vorige werkgever hebben we ooit voor een klant een CMS van een zelfbouwclub overgenomen. Je wil echt niet weten wat ik daarin allemaal ben tegengekomen: zo’n beetje alle klassieke beveiligingsproblemen passeerden de revue, en het systeem was ook zo inefficient dat we het in eerste instantie op een dedicated server moesten zetten om het een beetje te laten performen, en nog steeds ging het plat toen het een beetje drukbezocht werd. Na een betrekkelijk triviale aanpassing was het systeem enkele ordes van grootte sneller. Die klant had echt beter een standaard-systeem kunnen nemen, daarmee hadden ze veel minder problemen gehad en minder risico gelopen.

            Echter, een ontwikkelaar die wel weet waar hij het over heeft kan wel degelijk een veiliger en fatsoenlijker systeem bouwen. Maar hoe weet een niet ICT-savvy klant welke van de twee soorten ontwikkelaars hij voor zich heeft? Zeker als die ontwikkelaar een grote mond heeft (zeg maar: iedere ontwikkelaar 😉 ). De vuistregel “ga niet voor zelfbouw” is een hele goeie; vanwege veiligheid en ontwikkelkosten maar ook vanwege continuiteit als je later besluit toch naar een andere partij over te stappen (want dat was de oorspronkelijke context van de blogpost).

        • De veiligheid van de zelfgebouwde systemen zijn bedrog. Security by obscurity. Of eigenlijk security through minority (of misschien beiden). Ik hoop heel erg dat de zelfbouwers nooit een belangrijke klant (een bank of iets dergelijks) hun houtje-touwtje CMS aansmeren, want een serieuze hacker (geen scriptkiddies) komt met z’n ogen dicht binnen.

          Lekker niet onderbouwde bash. Maar, prima. Je uitdaging is hierbij aangenomen. Stuur je beste hacker maar af op mijn framework website: http://www.banshee-php.org/. En wanneer je er achter ben gekomen dat het je niet lukt, wees dan zo sportief om je ongelijk te accepteren.

          En voor jouw info: de belangrijke klanten uit mijn freelance tijd zijn vandaag de dag nog steeds heeeel blij met hun website op basis van mijn eigen CMS. Ze hoeven namelijk niet continue de website in de gaten te houden op beveiligingslekken. En ja, daar zitten serieuze organisaties tussen.

            • Ik ben even je robots.txt gaan nakijken. Zoekmachines mogen dus niet naar /admin en /blackhole? Interessant! 🙂 Bij /admin kan ik proberen in te loggen maar een brute-force aanval zal worden opgemerkt. En /blackhole blijkt verboden. Maar na aanroepen van /blackhole lijkt je site opeens plat gegaan te zijn. 🙂 Sorry, was niet mijn bedoeling…

              Doe eerst je huiswerk; Hiawatha heeft functionaliteit om IP-adressen vanwaar pogingen tot misbruik plaatsvinden te blokkeren. Probeer volgende keer eerst http://www.downforeveryoneorjustme.com of iets dergelijks voor je conclusies trekt 😉

              En het blokkeren van /admin voor spiders lijkt me een defense-in-depth maatregel; door het niet te laten indexeren nodig je ook niemand uit via zoekmachines om dingen te gaan proberen.

              P.S.: Het is niet netjes om (vermeende) beveiligingslekken publiekelijk online te slingeren alvorens de auteur een mogelijkheid te geven het lek binnen redelijke termijn te dichten.

              • P.S.: Het is niet netjes om (vermeende) beveiligingslekken publiekelijk online te slingeren alvorens de auteur een mogelijkheid te geven het lek binnen redelijke termijn te dichten.
                Tja, links in je robots.txt plaatsen is vaak een eerste domme fout die gemaakt wordt als het om veiligheid gaat. Het geeft immers al aanwijzingen waar zoek-engines dus niet mogen rondbladeren, dus een hacker wil er juist wel rondbladeren! 🙂 En de robots.txt opvragen is een uiterst onschuldige actie, maar kan soms al het een en ander vertellen over welke software een website gebruikt. Zie ik bij mijn eigen blog overigens ook, ook al wordt deze door WordPress beheerd. Mijn eigen site vertelt aan de gehele wereld welke links niet gevolgd mogen worden door zoek-robots. En daar zit b.v. wp-admin tussen, wat een indicatie is voor WordPress. Sowieso is dat ook geen groot geheim om te verklappen. Hetzelfde geldt overigens ook voor de gegenereerde HTML code die een framework oplevert. Banshee PHP is zich erg duidelijk aan het aankondigen. 🙂 Wat betekent dat? Dat betekent dat de Banshee site zelf misschien niet te hacken is omdat de maker ervan wel ieder lek dichtgooit dat hij tegenkomt. Alleen, honderden andere personen hebben het framework ook geinstalleerd en hebben mogelijk nog geen updates uitgevoerd waardoor er kwetsbaarheden in hun sites zitten. Doordat Banshee zich overal duidelijk aankondigt kun je via Google zoeken naar trefwoorden die Banshee dus in de HTML code plaatst en redelijk uniek zijn voor Banshee. Dat resulteert vervolgens in een lijst van websites die mogelijk Banshee als framework gebruiken. Als hacker ga je dan al die sites even langs om te kijken of ze up-to-date zijn en zoniet, dan kun je op die website naar binnen! Als 25% van de gebruikers niet regelmatig updaten en Google daar weer 10% van vindt, dan heb je als hacker bij 2500 Banshee-gebruikers dus toegang tot 10 websites. Dus is het een veilig systeem? Wel, de manier waarop het meldt dat het een Banshee-site betreft maakt het toch iets minder veilig. Op zich niet erg als het bijna niet gebruikt wordt maar als je het framework op 80% van alle Apache-webservers aanwezig is, is het een enorn interessante aanvalsvector.

                Daarom hebben hackers ook meer interesse in kwetsbaarheden in .NET, Linux, Windows, PHP en MySQL dan ik al dit soort “kleine” frameworks. Een specifieke site hacken is redelijk lastig. Maar een generieke hack uitvoeren op alle sites met een bepaalde kwetsbaarheid levert veel mogelijkheden op.

      • Het blijft een onzin-redenering. Ik ben een software ontwikkelaar en een eigen CMS systeem ontwikkelen kan in een aantal situaties beter zijn dan een bestaand systeem aanpassen. Dit is vooral het geval bij bedrijven met veel legacy-systemen waarbij diverse klant-databases aan elkaar gekoppeld zijn en de administratie zelf al vrij rommelig is. Het probleem is namelijk dat je bij legacy-systemen als ontwikkelaar moet proberen om van verschillende systemen een complete eenheid te maken. Afdeling A heeft b.v. hun klanten in een Oracle-systeem staan terwijl afdeling B weer SQL Server gebruikt. Afdeling 3 heeft daarentegen MySQL gebruikt en afdeling D heeft een eigen database-systeem ontwikkeld met CVS bestanden of zo. Moederbedrijf heeft al die afdelingen vroeger als kleine bedrijfjes ingekocht en moet nu de administratie van al die voormalige bedrijfjes veranderen in een soepel geheel. Dat kost tijd en met een standaard CMS pakket heb je niet 1-2-3 alles omgezet uit die legacy systemen naar een nieuw systeem. En dan moet je als bedrijf keuzes maken, want je wilt geen data verliezen, maar al die systemen zijn niet compatibel met elkaar.

        Een eigen CMS systeem is dan niet ideaal, maar geeft wel de meeste controle voor het migreren van de data naar een universeel geheel. Dat universele geheel kun je later weer naar een standaard-CMS pakket overhevelen, maar je hebt gewoon voor lange tijd een eigen systeem nodig waarin je eigen team de nodige aanpassingen in kan verwerken, totdat je alles eenmaal gelijk hebt gekregen.

        Een eigen CMS systeem biedt ook andere voordelen, omdat je zelf exact kunt bepalen welke functionaliteit deze precies moet bieden. Denk daarbij aan een SMS alert-systeem met een speciale SMS-box aan de server gekoppeld met bijbehorende SIM kaart. Of integratie met een telefooncentrale zodat de server automatisch gaat bellen naar b.v. verkopers zodra er een bericht binnenkomt van een potentiele klant. Denk ook aan de koppeling tussen het CMS systeem en voorraadbeheer van jezelf en dat van je leveranciers. Mocht in je eigen systeem blijken dat de voorraad op is dan kan het systeem even kijken of de leverancier wel voorraad heeft en je dus op korte termijn nog wel kunt leveren. Andere opties zijn de mogelijkheden tot het bepalen van locaties van bepaalde medewerkers, zoals directie en verkopers. En er vast nog best veel meer te bedenken dat je niet zomaar in een standaard CMS pakket terug zult vinden. Er zijn dus goede redenen om toch zelf een CMS systeem te produceren en dergelijke redenen hoor je niet snel in een interview van 45 minuten…

        • Denk daarbij aan een SMS alert-systeem met een speciale SMS-box aan de server gekoppeld met bijbehorende SIM kaart. Of integratie met een telefooncentrale zodat de server automatisch gaat bellen naar b.v. verkopers zodra er een bericht binnenkomt van een potentiele klant
          Je kan dit soort functionaliteit beter loskoppelen en aansturen met bijvoorbeeld e-mailtjes of webservices, dan dit in je CMS bouwen. Kan je het later nog eens hergebruiken of uit verschillende systemen aansturen ook. Ik hoor hier dus echt geen geldig argument. Jouw datamigaties zijn ook vrij simpel op te lossen met tools zoals Pentaho.

          @Hugo, inderdaad, ik had die quotes per ongeluk aan jou toegeschreven. Dom, excuses. Ook nadat je eerst hebt gebouwd etc en dan pas aan mijn bureau staat is jouw zelfbouw nog steeds geen alternatief. Mijn argumenten tégen (kort samen te vatten als: de rest van de wereld moet zich aanpassen in plaats van alleen jij) staan namelijk nog overeind. Een goede software engineer weet wanneer hij of zij zich moet aanpassen en de tekortkomingen van bestaande zaken kan mitigeren om ze vervolgens te hergebruiken. Dat zou tevens tot mooi gevolg hebben dat als jij zo’n pakket te instabiel of onveilig vindt, je wat zou eraan zou kunnen bijdragen met jouw verbeteringen.

          • Je kan dit soort functionaliteit beter loskoppelen en aansturen met bijvoorbeeld e-mailtjes of webservices, dan dit in je CMS bouwen.
            In welk van de vele CMS systemen die je al in huis hebt, dan? Want ik gaf al aan: meerdere afdelingen met ieder een eigen systeem dat allemaal met elkaar geintegreerd moet worden. Dat lost je niet op door er nog eens een systeem bij te proppen en dan van alles en nog wat heen en weer te blijven sturen. Vergeet bovendien niet dat ieder nieuw systeem ook weer vereist dat de gebruikers er mee leren omgaan. Dit vraagt best veel tijd. Je kunt dan beter de bestaande CMS systemen nog even blijven ondersteunen zodat de overgang langzaam geintroduceerd kan worden. Als je 20 afdelingen tegelijkertijd naar een nieuw systeem laat overstappen zitten je systeembeheerders binnen de kortste keren ziek thuis.
            Jouw datamigaties zijn ook vrij simpel op te lossen met tools zoals Pentaho
            Datamigratie is op zich ook geen groot probleem. Gebruikers-migratie is lastiger. Gebruikers kun je niet eenvoudig met een simpele update bijwerken naar de nieuwe software. Nieuwe software bij je gebruikers installeren vereist het nodige aan documentatie, handleidingen en instructeurs die les geven en gaat een stuk trager dan even een CMS systeem bijwerken. Zeker indien een bedrijf uit een lappenmand van CMS systemen bestaat is het gewoon beter om de boel eerst te analyseren en te kijken wat er overal nodig is aan data. Dan kun je gaan werken aan data-migratie en data-converties richting een meer algemeen CMS systeem. En ja, dat systeem kan prima uit herbruikbare componenten bestaan, maar omdat je met zoveel varianten aan systemen zit ontkom je vaak niet aan maatwerk. Je hebt al 20 CMS systemen in het bedrijf, dus dan is het verspilling van tijd om daar nog eentje aan toe te willen voegen die je vervolgens met de rest moet integreren. Vaak kom je uit op een oplossing waarbij diverse functies van meerdere CMS systemen met elkaar gecombineerd moeten worden. En als enkele gebruikte systemen al uit losse componenten bestaan dan zijn die mogelijk wel herbruikbaar. Maar je moet echt eens kijken naar wat voor rampzalige legacy-code er allemaal zit onder al die oude CRM systemen. En besef ook hoe krampachtig gebruikers en management graag willen vasthouden aan de software die ze al kennen.

  3. Hoe zit dat met maatwerk? Als je als klant een maatwerkapplicatie laat bouwen door een sofwarebedrijf, liggen de auteursrechten van de broncode dan ook bij het softwarebedrijf? Wat ik merkwaardig vind, is dat je als werknemer iets maakt, de auteursrechten daarvan al snel bij de werkgever liggen, want die had daartoe opdracht gegeven middels een vrij ruime opdrachtomschrijving in je contract. En volgens mij liggen de auteursrechten van een foto die ik door een toevallige passant laat maken (van mij en mijn gezin bijvoorbeeld) nog steeds bij mij. Opdracht / contract heeft volgens mij wel degelijk invloed op auteursrechten.

    Kom je niet ook in de problemen met allerlei licentievoorwaarden van Open Source code die je gebruikt, zoals bijvoorbeeld de GPL? Je mag prima GPL code combineren met je eigen (niet-GPL) code, zolang het voor eigen gebruik is. Maar op het moment dat je je werk gaat distribueren (naar de klant dus), heb je je aan de voorwaarden daarvoor te houden. Als je in opdracht van de klant werkt, en de code is eigendom van de klant, dan voorkom je die problemen.

    Maar goed, een echte lijder aan het not-invented-here-syndroom gebruikt natuurlijk ook geen (Open Source) libraries :).

    • Matthijs, die foto is dubieus. Als jij de toevallige voorbijganger helemaal vrij hebt gelaten hoe hij die foto maakt, heeft hij het auteursrecht. Het is immers zijn creativiteit. Stel jij de camera helemaal in, zoom je zoals je het hebben wil en geef je het kader aan waarin hij de foto moet nemen, dan denk ik dat je wel een case kan maken dat jij het auteursrecht zou moeten hebben.

      Ik dacht bij dat CMS eerst, dan vraag je om een eeuwigdurende onheroepbare niet exclusieve licentie in het contract in plaats van eigendom. Aleen heb ik uit dit blog geleerd dat je dan alsnog de sjaak bent als je leverancier failiet gaat en de curator tegen ale afspraken in mag gaan en de licentie alsnog mag intrekken.

      Hoe zit het met een constructie waarin de ontwikkelaar jou enerzijds het CMS onder de LGPL beschikbaar stelt en jij je er vervolgens contractueel op vastlegt het niet te verspreiden op last van een fikse boete? Waarbij de boete vervalt bij faillisement van de leverancier. Als de curator dan de overeenkomst opzegt zit je met LGPL software. En ik zie niet hoe hoe hij zo’n licentie intrekt als iedereen met een licentie het recht heeft om licenties te geven.

    • En volgens mij liggen de auteursrechten van een foto die ik door een toevallige passant laat maken (van mij en mijn gezin bijvoorbeeld) nog steeds bij mij
      Nee hoor, die liggen bij de fotograaf. Je mag als geportretteerde wel kopieen maken. Maar je mag die weer niet zelf publiceren.

      Je GPL vergelijking begrijp ik niet. Jij verplaatst hooguit het moment van overdracht.

      • De vraag is of er in het laatste geval wel overdracht is. Als de auteursrechten bij de klant liggen, vanaf het begin, distribueer ik de GPL code dan nog? En als freelancer of detachee? Als er geen distributie is dan hoe je geen rekening te houden met de beperkingen in de GPL mbt tot distributie. Maar misschien heb ik het mis en vind er nog steeds overdracht plaats, ook al is er afgesproken dat de auteursrechten van de code bij de klant liggen. Ik ben hier wel benieuwd naar, want het is volgens mij iets wat vrij vaak voor komt.

  4. FYI, ik heb gisteren en vandaag een mailwisseling met Hugo gehad. Ik heb even naar de code van zijn webserver gekeken en vond vrij snel twee heap inspection vulnerabilities en één (waarschijnlijke) source / config file disclosure vulnerability.

    In Banshee zitten path disclose, MySQL username disclosure vulnerabilities en bad practices met default admin passwords.

    De reacties die ik dan krijg zal ik niet volledig quoten want het was een privé-discussie, maar zitten in de trant van ‘tegen domme admins kan je niks doen’, ‘gevalletje RTFM’, ‘je moet ook geen users op je webserver laten’ en ‘ok dit is een probleem en ik heb het aangepast maar het is niet serieus en het is je dus niet gelukt om aan te tonen dat mijn software niet veiliger is dan andere’.

    Ik zie het anders. Ik zeg: als “manager met geen bal verstand van software-ontwikkeling” vind ik toch verdacht veel issues in de anderhalf uur die ik heb besteed.

    De waarheid zal wel in het midden liggen.

    • Goed gedaan, Richard. Je hebt aangetoond hoe kwetsbaar een open-source framework is. 🙂

      Zelf ontwikkelen tegenover hergebruik van andermans componenten… Het is lastig. Bij hergebruik kun je veel tijd uitsparen, maar kwetsbaarheden in die componenten zijn mogelijk ook bekend bij hackers. Door hergebruik krijg je dergelijke kwetsbaarheden dus in je site. Zelf je eigen, closed-source CRM pakket ontwikkelen zal niet veiliger zijn. Alle programmeurs maken fouten, dus zullen er kwetsbaarheden in zitten. Het verschil is alleen dat deze kwetsbaarheden pas bekend raken zodra hackers de site ook daadwerkelijk onder vuur nemen.

      Ik heb in het verleden wel eens een CRM pakket gebouwd. Nee, niet in mijn uppie! Bedrijfsmatig, als software-pakket om door te verkopen! Met bijbehorende ontwikkel-traject waarbij we toen nog de oude waterval-methodes gebruikten. (Tegenwoordig is iedereen aan het scrummen…) Een team van 6 man, inclusief een functioneel specialist en twee testers was hierbij verantwoordelijk voor de oplevering van dit pakket en de uitkomst was best een goed systeem. En dit is hoe veel CRM pakketten eigenlijk ontstaan. En als die werkgever van mij niet failliet was gegaan door een paar domme investeringen te doen hadden we nu misschien wel met een team van 40 man dat systeem gaan door ontwikkelen.

      • Bij hergebruik kun je veel tijd uitsparen, maar kwetsbaarheden in die componenten zijn mogelijk ook bekend bij hackers. Door hergebruik krijg je dergelijke kwetsbaarheden dus in je site.
        De term ‘kinderziekte’ is hier raker dan menigeen denkt: je moet deze fase door. Voordeel is dat nadat je die fase hebt doorgemaakt, je componenten hebt die robuust zijn. Je kan dan mijns inziens beter die componenten doorontwikkelen, dan opnieuw beginnen. Het doet me een beetje denken aan het bekende standaardisatie-grapje van XKCD.

        • Ja, de term “kinderziektes” is zeker van toepassing op eigen werk. Probleem met bestaande frameworks is dat je ook daar niet zeker bent dat de kinderziektes eruit zijn. De meest bekende frameworks hebben ook een goede documentatie van alle aanwezige kwetsbaarheden en je moet bijblijven bij de nieuwste updates omdat de populaire systemen ook de meest populaire doelwitten vormen. Kleindere, minder bekende frameworks zijn minder populair en worden dan ook minder vaak aangevallen, maar daardoor is ook minder bekend over mogelijke kwetsbaarheden in die systemen. Je eigen systeem ontwikkelen zorgt ervoor dat iedereen nog alle kwetsbaarheden moet ontdekken maar kan ook de meeste kwetsbaarheden bevatten. De truuk is dan ook om een balans tussen alles te vinden.

          Zo zou je een discussie kunnen beginnen over welke database het meest veilig is voor een CMS systeem. Dan krijg je de grote jongens zoals DB2 en Oracle samen met SQL Server en MySQL over tafel. Enkelen zullen nog Firebird/Interbase noemen en dan worden er vast nog allerlei kleinere systemen genoemd. Dan kun je weer doorslaan naar het andere uiterste, met encrypted XML bestanden of fixed-length tekstbestanden en mogelijk ook een der vele NoSQL systemen of zelfs Lotus Notes en Microsoft Access. Hoor ik nog Paradox en DBase IV? Waar het uiteindelijk om draait is om wat er uiteindelijk gewenst wordt en de ervaring van de personen die het moeten bouwen in combinatie met de beschikbare bouwtijd. Bij gebrek aan ervaring en gebrek aan tijd is het gebruik van standaard componenten het beste. Een meer ervaren team zou bestaande componenten met maatwerk aan elkaar kunnen koppelen. Een onervaren team met veel tijd kan veel tijd besteden om handige componenten bij elkaar te zoeken en aan elkaar te knopen. Een ervaren team met veel tijd kan net zogoed zelf iets bouwen. Maar ja, niemand heeft “veel tijd”…

    • Ik zie nu pas deze reactie. Wat een onzin. Path disclose, niet dus. MySQL username disclosure vulnerablities… verzin je die kwetsbaarheid ter plekke? De MySQL username is dus niet te achterhalen. En bad practices met default admin password… dat was dus dat als de admin het default wachtwoord niet veranderd, dan is dat de fout van Banshee. Ja, zo ken ik er ook nog wel een paar. Een boel stoere praat, maar Richard heeft geen bewijzen geleverd van zijn mooie praatjes. Beetje stoer doen en leugens verkondingen op een blog. Erg laf.

      • Beetje heel laat om deze discussie weer op te halen maar goed. Ik denk ook niet dat je kunt stellen dat elk zelfbouw-CMS per definitie onveilig is. Dus het kan best zijn dat Banshee heel veilig is (jammer dat het niet Open Source is maar daar zul je je redenen voor hebben). In mijn ogen is de kans dat een zelfbouw-CMS veiliger is dan een wijdverspreid systeem kleiner. Daarnaast zit je als Banshee afnemer eeuwig aan jou vast als leverancier terwijl je met een WordPress installatie bij vele internetbureaus terecht kunt. Maar misschien dat als Banshee’s user-base groeit, dit minder een probleem wordt.

      • Hugo, wil je toelichten waar Richard de mist in is gegaan? Hij heeft je code bekeken, dan is het toch reëel te vermoeden dat hij dingen heeft gezien waar hij die conclusie uit trekt. Om dat nu met “leugens” en “laf” te weerleggen vind ik dan onder de maat. Ik nam aan dat Richard geen details wilde posten omdat dat met jou afgesproken zou zijn. Maar nu nodig ik je toch uit meer detail te leveren over wat Richard dan gescreend heeft en hoe ik zijn bevindingen dan wel moet plaatsen. En @Richard aan jou geldt natuurlijk dezelfde uitnodiging.

        • Het is alweer een tijd geleden, maar in de e-mail die hij stuurde noemde hij allerlei kwetsbaarheden zonder enige beschrijving hoe en wat. Hij zou zogenaamd allerlei informatie kunnen achter halen wat niet waar bleek te zijn. Na vraag om bewijs voor zijn beweringen bleef het stil. Ook zaten er allerlei voorwaarden aan die nergens op sloegen. In de trant van “stel een gebruiker op je systeem heeft bepaalde rechten, dan kan hij bij het wachtwoord voor je database”. Op dat niveau. En ook nog eens niet Banshee-specifiek, maar meer zaken die altijd wel gelden. En hij geeft er zelf allerlei ter plekke verzonnen namen aan, zoals ‘MySQL username disclosure vulnerablity’, om het stoer en serieus te laten klinken. Voorals nog bleef het dus bij wazige praat van een manager die een keer wat stoere termen heeft gehoord.

          En ik heb niks met hem afgesproken over het wel of niet posten van gevonden zaken. Ik daag hem zelfs uit om iets serieus te vinden en te posten.

  5. De kwestie is sterk vergelijkbaar met de analoge grafische industrie van pakweg de jaren 60 en 70. Als je kleurgescheiden gerasterde kleuren litho’s liet maken door je drukker (fout nr. 1) moest je die vet betalen maar bleven ze volgens de leveringsvoorwaarden het eigendom van de drukker. Volgens de leveringsvoorwaarden konden zelfs de bewaarkosten van de litho’s aan je worden belast. Alles staat met de – al dan niet – vooraf gemaakte afspraken. Als je tenminste weet waar je juridisch mee bezig bent.

    • De/het eigendom: dat hangt er vanaf wat je bedoelt. Van Dale:

      1 (de; m) het recht om over een zaak in alle opzichten te beschikken<br/> 2(het; o; meervoud: eigendommen) zaak die men in eigendom bezit

      Bij Onze Taal meer advies:

      De eigendom is een wat formelere, juridische term. … Zo kun je bijvoorbeeld de eigendom van een huis overdragen aan iemand anders. Of je hebt de eigendom van een stuk grond. De eigendom is eigenlijk het eigendomsrecht.

      Overigens maken juristen soms nog onderscheid tussen “intellectueel eigendom” en “intellectueel-eigendomsrechten”. De laatste zijn concreter: merkrecht 123 is het intellectueel eigendomsrecht van bedrijf X, uitvinding A is het intellectueel eigendom waarvoor het IE-recht ‘octrooi’ kan worden aangevraagd, en het databankrecht is een merkwaardig stuk in de intellectuele eigendom. En ik moest nu ook drie keer kijken of de de’s en hetten wel kloppen.

      • Dit onderscheid gaat er vanuit dat er van nature een soort van “intellectueel eigendom” bestaat, en dat het octrooi daarvan slechts een soort van akte of inschrijving is. Met deze terminologie draag je dus een bepaalde zienswijze op octrooien uit discutabel is. De alternatieve visie is dat alleen dankzij dat octrooi een aantal rechten ontstaan, door de wet in het leven geroepen met een bepaald doel in het algemeen belang, en die rechten (en onderliggende doelen) zijn zeker niet gelijk te stellen zijn met het eigendomsrecht op een fysiek voorwerp.

        Vanwege de grote verschillen tussen de wereld van fysieke voorwerpen en abstracte ideeën is het gelijkstellen van eigendomsrechten uitermate problematisch; het maakt een goede rationele discussie over dit onderwerp moeilijker.

  6. Na het lezen van deze blog vroeg ik me het volgende af: Als een webbouwer zijn CMS niet af wil staan omdat hij daar goede (juridische) redenen voor heeft. De teksten en het grafisch ontwerp zijn aangeleverd en gemaakt door de klant en dus ligt het auteursrecht bij de klant. Althans daar ga ik voorzichtig vanuit, niet gehinderd door enige kennis op dat gebied.

    Stel dat ik nu de pagina door een tooltje download en lokaal opsla. Dus ik heb alle losse html pagina’s, css en plaatjes en die publiceer ik op een site, uiteraard met toestemming van de klant. Dit om hierna het hele ontwerp in een nieuw CMS te gieten om zodoende weer een werkbaar systeem te maken.

    Kan de oorspronkelijke webbouwer hier een probleem van maken? Uiteraard kan hij er een probleem van maken maar heeft hij ook enige juridische grond om op te staan? Zonder dat CMS was die “scrape” actie natuurlijk niet mogelijk.

    • Het probleem ontstaat wanneer de klant materiaal overneemt (hergebruikt) waarvan het auteursrecht bij de webbouwer ligt. In dit voorbeeld lijkt daarvan geen sprake te zijn. De content is copyright klant (nemen we maar aan) en het CMS wordt juist niet gekopieerd – aangenomen dat die CSS en Javascripten en zo deel is van het ontwerp en niet (ook) van het CMS. Je mag op zich een website downloaden.

      Het is legaal om uit een boek een scan te maken van een afbeelding waarvan het auteursrecht verlopen is, en dan mag je met die scan doen wat je wilt ongeacht het auteursrecht op het boek. Hetzelfde geldt bij de situatie van website uit CMS.

  7. @hugo “mijn framework website: http://www.banshee-php.org/. En wanneer je er achter ben gekomen dat het je niet lukt, wees dan zo sportief om je ongelijk te accepteren.” Ik heb enkele lekken gevonden het uitleggen ligt iets pijnlijker omdat je een deel van mijn code hebt gebruikt dat in combinatie met copyright strookt niet met je melding zelfbouw. en ja ik gebruik al van 2001 hashing en sleutels als eerste nog voor de copycats mijn systeem rsa genoemd hebben. Met een aangetekend schrijven en met ondertekening wil ik je site wel eens bestoken daar je autoload gebruikt zal dit niet moeilijk zijn.En die md5 heb je daar ook je copyright voor

    verder: Copyright afdwingen is te moeilijk als je het niet gnu maakt er worden te veel copy’s van mijn code gebruikt en zelfs op een solicitatie gesprek kwam er iemand met mijn code voor uit te leggen gewoon wansmakelijk.(als men dan nog een eigen naam onder zetten is het helemaal) mijn copyright is om ervoor te zorgen dat ik me kan verweren moest iemand proberen mij bestoken.

  8. en ja ik gebruik al van 2001 hashing en sleutels als eerste nog voor de copycats mijn systeem rsa genoemd hebben.

    Gaat het wel goed met je, ‘hashing en sleutels’ bestaan al wat langer dan 2001… RSA is in 1983 gepatenteerd. Ik ben benieuwd welke delen van jouw code zijn gebruikt?

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS