Nederlands (NL-nl)English (United Kingdom)
Auteursrecht en Open Source
Written by Felienne Hermans   

Verslag geschreven door Rico Huijbers.

Deze Open Source library ziet er nuttig uit, maar wat moet ik doen om deze in mijn software te mogen gebruiken? Waarop geldt eigenlijk precies allemaal auteursrecht? Wat moet ik in een End User License Agreement zetten, en hoeveel heb ik daar aan? Het zijn een paar vragen waar iedere ontwikkelaar wel eens tegenaan loopt.


In een uitermate interessante avondsessie legt ICT-jurist Arnoud Engelfriet ons uit hoe het licentierecht en auteursrecht van toepassing zijn op software. Deze rad pratende voormalig informaticus heeft zich toegelegd op het recht in de digitale wereld; een wereld waarin het nogal eens onduidelijk kan zijn hoe de regels die vanzelfsprekend lijken in de fysieke wereld, uitgelegd dienen te worden.

Arnouds verhaal begint bij de End User License Agreement. Iedereen kent ze wel, deze pagina's vol tekst waar iedere computergebruiker zijn schouders bij ophaalt en maar op "Volgende" klikt. De meeste van deze overeenkomsten zijn echter volslagen rechtsongeldig! Je hoort ze ter hand gesteld te krijgen vóór je een product aanschaft, dus de EULA op je nieuw gekochte computer zie je veel te laat. Bovendien is iedere verpakking die verkondigt dat je "door te openen akkoord gaat met de voorwaarden" die er IN zitten natuurlijk klinkklare onzin. Vaak wordt deze EULA door de fabrikant gebruikt om aansprakelijkheid af te wenden voor fouten in de software. Maar als er voor onbeperkt gebruik van software betaald wordt, is er sprake van een koop en kan de klant garantie claimen op fouten in de software! Sterker nog, deze klant heeft zelfs het recht om het stuk software dat nu zijn eigendom is, tweedehands verder te verkopen. Iets wat de fabrikant natuurlijk liever niet ziet gebeuren!

Volgens Arnoud zijn rechters eigenlijk net Exception Handlers: ze worden aangeroepen worden als het niet meer duidelijk is hoe de regels toegepast moeten worden. Ze zullen dan de wet interpreteren naar redelijkheid en billijkheid om in een geschil tot een eerlijk oordeel te komen. Hoewel het een favoriete tijdsbesteding is van iedere computernerd om door middel van technische truukjes om om de regels heen te komen, vertelt Arnoud ons over zijn "giecheltest": als bij het uitleggen van je verdediging je toehoorders beginnen te giechelen, zal een rechter zich hierdoor niet laten overhalen.

De volgende vraag is welk werk eigenlijk auteursrechtelijk beschermd genoemd mag worden. Dat de broncode auteursrechtelijk beschermd is snappen we allemaal wel. Maar zijn binaries dat ook? En het uiterlijk van de applicatie? De regel is dat alles waarvoor creativiteit aan de dag gelegd wordt, auteursrechtelijk beschermd is. Voor een User Interface moet dan eerst aangetoond worden dat dit op zichzelf een creatief werk is. Min-of-meer letterlijke vertalingen van een auteursrechtelijk werk (zoals een compiler doet, of lex en yacc, of zelfs het vertalen van een leesboek) vallen onder het auteursrecht van het oorspronkelijke werk. Het wordt weer wat discutabeler als bij deze vertaling creatieve elementen worden toegevoegd, zoals een implementatie van de standaard C library. Gelukkig doen compilerfabrikanten in zo'n geval expliciet afstand van hun auteursrecht.

Het laatste onderwerp van de avond was softwarelicenties. Als je software in handen krijgt mag je deze in principe voor jezelf gebruiken, maar zonder licentie heb je niet het recht om de software verder te verspreiden. Voor Open Source software zijn er licenties in een heleboel smaken, van de allereerste academische licenties (MIT, BSD) die je alle vrijheid geven om met de software te doen wat je wil, tot de zogenaamde "copyleft" licenties (GPL, Affero GPL), en natuurlijk er tussenin (MPL, LGPL, EPL). Copyleft licenties, met als grootste voorbeeld de GPL, verplichten de ontvanger om bij verdere verspreiding van software die een "afgeleid werk" vormt, de broncode mee te leveren. Hiermee probeert de Free Software Foundation, onder aanvoering van Richard Stallman, alle software zogenaamde "vrije software" te maken, om zo een wereld te scheppen waarin wij controle hebben over onze computers, in plaats van grote bedrijven. Helaas blijkt het erg moeilijk om te definiëren wat nu precies een afgeleid werk is. Statisch linken is dat zeker, maar is dynamisch linken dat ook? Of gebruik maken van een API? Of een plugin schrijven in een GPL-gelicenseerd werk, zoals WordPress? Deze vragen zullen eerst ooit juridisch aangevochten moeten worden voor we hier een antwoord op krijgen.

Zoals je merkt is auteursrecht in het digitale landschap een onderwerp met veel nuances, waar nog uren over gediscussiëerd kan worden. Helaas was deze avond daar te kort voor, maar we willen Arnoud in ieder geval bedanken voor zijn heldere uitleg en scherpe inzichten!

Trouwens: vanwege hun dubieuze rechtsgeldigheid spaart Arnoud bordjes met daarop "De directie stelt zich niet aansprakelijk voor eventuele schade". Als je er eens ergens zo één op een rommelmarkt tegenkomt, kun je hem daar heel blij mee maken :)


 
Free talk with Philippe Kruchten
Written by Arne Timmerman   

You're all cordially invited to a free talk with Philippe Kruchten next wednesday, December 19th, from 15:30 to 16:30. The talk on cognitive biases in software development will take place at the TU Delft, EWI, Lipkens room.

Over the years we've identified some of the strategies and tactics software architects use during the design of new, bold, large software-intensive systems: divide-and-conquer, brainstorming, reuse, etc.. But we also observed some strange tactics, biases, reasoning fallacies that creep in and pervert somehow the design process. They go by simple, funny or fancy names: anchoring, red herring, elephant in the room, post hoc ergo propter hoc, non sequitur, argumentum verbosium, etc. This talk will do a little illustrated catalogue of these games, with examples, and how they sometimes combine onto subtle but elaborate political plots. In other words, this talk is about cognitive biases and how they affect software development.

Philippe Kruchten

Philippe Kruchten is professor of software engineering, in the department of Electrical and Computer Engineering of the University of British Columbia, in Vancouver, where he holds an NSERC Chair in Design Engineering. He teaches software engineering, more specifically software project management, and two interdisciplinary project courses on innovation, entrepreneurship, system engineering. Philippe does research in software architecture and software processes, with a handful of graduate students, and many collaborators around the world. He is known as Director of Process Development (RUP) at Rational Software, and developer of the 4+1 view model.


 
Report Global Day of Coderetreat AMS 2012
Written by freek   

This review was written by Linda van der Pal and is cross-posted from the Duchess blog on http://jduchess.org



Yesterday I traveled through the cold over icy pavements to the office of Mirabeau in Amsterdam to join my fellow coding enthusiasts for a day of mad coding. There I was joined by about twenty others and even eight children. The younger children set out to learn the Scratch programming language, while the older 'kids' went off to play with the game of life. For them (including me) the day was divided into iterations of about 45 minutes. In our first iteration we attempted to write the game using TDD as if you meant it. Which has three easy rules.

1. The code is written in the test
2. You may only extract a method when you get duplication
3. You may only extract a class when several methods share the same state, that is not shared by yet other methods.

This turned out to be rather hard to do as it's contrary to the way most of us work all the time. This iteration I joined someone who was programming in Python, as I hadn't brought my own laptop. We didn't get very far, as we found it rather hard to determine what our first test should do. It took us at least fifteen minutes to get started properly. In the end we only had two test methods determining whether a cell was dead or alive (although there was no real concept of cell yet) and four test methods to determine if two cell were neighbors. After the 45 minutes were done, we had to delete our test and then discussed what approached we had all tried. Some had, like us, chosen the bottom-up approach, while other had chosen a top-down approach and had started with a complete board.

As most people found this round very hard, we did another round with the same constraints. This time I joined someone who was using JavaScript. We got a bit further during this round, as we'd done some of the groundwork in the previous round. Again we went for the approach of determining if two cells were neighbors. We even got so far as to attempt to wrap around the edges of the board. But there we made a slight error in our formula while redesigning (as it was real refactoring) and had failing tests when the 45 minutes were over. Once again we had to delete our code. But when we discussed a bit more about what we had been doing, we decided that we had been going about the wrong approach and that it would be better if we had asked what the neighbors of a certain cell were, as this would be much easier to calculate and much more useful.

After the second round, it was time for lunch. But not before the younger children gave a little demo of what they had been doing during the morning. It turned out that what they had built on the demo laptop had not been saved properly, but the laconic answer was "Oh, no matter, I'll just build it again." Which is something we can all learn from, I'm sure! And indeed the demo was quickly put together again and they showed us some animals flying over the screen and turning around when they got to the edge of the screen. Very impressive when compared to our own paltry results of the morning!


After an excellent lunch I was curious about Scratch myself and so I skipped an iteration to go see what the kids were up to. They were just starting with a game of their own. They were going to make a game where a character had to catch something and would score points if he did, and lose points if he didn't. The requirements of such a game were quickly established and written on a whiteboard. Then the kids paired up and set to write the game. After about an hour they all had most of the requirements implemented.

I left them to it, and went back to another iteration of coding. This time I joined up with someone coding in C# and the constraint was not to return anything. Which was once again quite contrary to my own coding style. And also could not be combined with the TDD as if you meant it style we had been using before. Fortunately my partner had quite some experience with delegates and we passed our one-liner assertions on to the methods under test. At the end of the iteration it turned out we had the most tests of all the groups and as we hadn't yet deleted our code right away (as we were supposed to) we code showcase it to the rest of the group.

For the final round of the day I got to program in Java (which is the language I use daily) with the constraint not to use any conditionals. So no for-loops, no while, and most importantly no if. This turned out to be such a conceptual leap that we couldn't really code test driven anymore. But after some pondering we figured out that you could put the conditional rules of the game in a map. Where you could simply look up the answer of whether a cell would live or die by passing in the number of living neighbors it had. We then counted the number of living neighbors by putting all the neighbors in a list and determining the frequency of living cells in it. We were sure that the frequency method must use conditionals under water, but it saved us from using conditionals ourselves. We ran out of time one final time, but at least we could save our code this time. Once again we discussed the results at the end of the round. This time the results were even more varied, as the solution really depended on what kind of constructs the language offered.

Then it was time for the kids to showcase their games and they were really impressive. One pair had created a game with a squirrel in a forest who had to catch nuts (yet avoid the spiky chestnuts). One team had a shark in the sea catching fish. The third team had created a ghost who had to catch dinosaurs. And the fourth team had a crab running to catch apples. If you want to play their games, you can at: http://scratch.mit.edu/users/codeerfeest


Then it was time for a last cup of coffee, a short evaluation round, a handing out of code smell cards by QWAN, and finally to say goodbye. All in all it was a great day, and I can't wait for the next one.

Foto's

 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 4 of 30

Meetings

Prijzen sponsors

JetBrains logo



Pictures

Bekijk alle foto's van Devnology op Flickr.

Why meet up?

Devnology meetings are aimed to bring together passionate developers to exchange ideas and experience, to discuss and network - geek to geek.

About us

We focus on concepts of software development. For new developments we will dig into the underlying principles and concepts and try to place this in a broad perspective of existing platforms and solutions. Read more...