Gilles Gravier's rants about things in general... security, open source, privacy, java, music... in particular.
2020 FLOSS Roadmap version 2009 is out!
So the new version was published and announced about 2 weeks ago, right after the Open World Forum in Paris (quite an impressive event, with a very interesting speech from Mark Shuttleworth). Check out the new (2009 edition) of the 2020 FLOSS Roadmap! Very interesting reading!
Gilles.
Posted at 03:42PM Oct 22, 2009 by gravax in Opensource | Comments[0]
You know you've been using OpenSolaris too much when...
... when you start typing "pfexec" in Linux instead of "sudo" and wondering why it doesn't work.
Time to "alias pfexec sudo" for me.
Posted at 08:25PM Oct 16, 2009 by gravax in Opensource | Comments[2]
Why closed, proprietary platforms are to be avoided... whenever possible!
Those who know me know I am very much against Apple's commercial behavior. With the iPod, they sell a closed, proprietary platform, which is bad enough, but they also completely control what you can put on it.
The following article explains what happened to an author who wrote a nice application, and, after some updates of it, saw it banned from the Apple Store.
Apple basically has right of life or death on the software you write for their platform. Even if they don't really understand what it does (the article explains why this is the case)...
Of course, you can always jailbreak your phone (which I recommend anybody stuck with an iPhone do as soon as they can) but this voids guaranty, and some may not like it...
I chose a phone with a truly open platform : Symbian OS. Open Source. Easy to write code to. And anybody can install what they want on the phone. And it's stable! Ditch your closed phone platform. Get one that is desgined with 21st century principles!
Posted at 09:07PM May 12, 2009 by gravax in Opensource | Comments[6]
Building aMSN with audio and video on OpenSolaris - piece of cake!
I got tired of not being able to use webcam and audio with my friends on OpenSolaris... so I decided to tackle the problem. Blastwave's version of aMSN was very old... so there was no other option... get it myself and build it.
Turned out to be trivial...
Get the sources from : http://www.amsn-project.net/ and then ./configure, then gmake, then pfexec gmake install (my OpenSolaris box has already GCC and the GNU compiler suite installed). Simpler for all GNU / Linux source codes available out there.
First thing that happens when you run it is that it tells you it wants TLS to log in... so you install the SUNWtcltls package form the OpenSolaris repository with Package Manager... and in the advance preferences tab, specify that TLS is at : /usr/lib/tcl8.4/tls1.6 ... and voila... you can log in.
Of course, next thing is that there is no audio... so you figure out it wants Snack, the audio library for TCL... well, that too is available from the OpenSolaris repository through Package Manager. Just install SUNWsnack and restart aMSN. Then you can configure audio (preferences -> advanced) to use Snack...
For the webcam, it's even simpler. OpenSolaris includes USB-VC drivers for Video4Linux2, so plug in a high-end USB-VC webcam and aMSN directly supports it! Just go to the preferences->others menu in aMSN and edit the audio and video settings!
I love it when things just work!
Posted at 11:50PM Apr 26, 2009 by gravax in Opensource | Comments[5]
My first conference call with OpenSolaris's VoIP application!
Today I was scheduled to be on a conference call. I decided to be a geek and try Ekiga on OpenSolaris. It ships by default. Well, you have to install it from the default repository. It's just not called Ekiga, but Video Conference...
I started it. Gave it my Ekiga and FreePhonie account details (FreePhonie comes from my ISP and gives me SIP telephony for free to land lines all over Europe and other major countries around the planet). Once the details entered, I dialed the toll free number form Ekiga and voila!
Speaker sound was perfect. Microphone sucks on my Toshiba Tecra M2. Next time I'll test the fancy Logitech USB headset!
I love it when "technology-just-works"!
Posted at 05:00PM Apr 14, 2009 by gravax in Opensource | Comments[0]
Chosing the right license in the open source world
So you are now ready to start creating a product. This product will contain software. Software you will write, or have already written, but possibly also third party software that you will bundle with your own code, and maybe some hardware.
You need to start thinking, very early on, about a crucial element when using software.
Licensing.
You may already have made the decision on whether your software will be commercial or free, closed source, or open source... but you need to look at licensing issues in at least 2 very important places, in particular if you plan to include open source software.
Many people tend to associate open source with only the freedom aspect it brings. But it also comes with a serious amount of obligations and responsibilities.
Selecting the right license is the work of licensing experts and lawyers. But I'll try to give some ideas on how to go about making reasonably good choices in this area.
First things first. The Open Source Initiative has a definition of what an open source license is. This definition is available at : http://www.opensource.org/docs/osd/. They also do the complex task of reviewing popular open source licenses and listing the ones that match the definition. This list is at : http://www.opensource.org/licenses/. It provides a basis for selecting licenses from, at least, a limited list.
So what is that makes an open source license. Let me start by quoting the 10 points of the Open Source Definition mentioned above :
---
As you can see, that's a pretty strong definition. Lots of things that must be done, and lots that can't be done, if a license is to merit the qualification of open source.
Not everything can be called open source. Good thing there is a definition.
So. How do you pick the right license for you? What are the implications?
Well, there are 3 main types of licenses available to pick from.
Type A licenses, also refered to as “attribution licenses” are the ones with the fewest requirements. They allow unrestricted development of derived works. You can typically use type A licensed code in any way you like, embedding it into other applications with almost no constraints. Example type A licenses include the popular Apache or, the very simple, yet effective BSD (example from the FreeBSD project) license. One of my favorite ones (which I have yet to see used in common software is the WTFPL “Do What The Fuck You Want To Public License”.
One of the aspects that I've noticed about type A licensed projects is that despite the fact that the license doesn't mandate that derived works should be submitted back to the original project, they tend to generate a strong community feeling in the user / developer community and people still do contribute back to the original source commons. Which goes to show that you don't have to force people to contribute for them to do so.
Type B licenses are the ones that are normally considered as community fostering licenses. The point of these licenses is that when you take code from such a project, you have to contribute back to the project any chance you make to files from the project. You are free to add any new file covered by any license you want (as long as that license of yours doesn't conflict with the normal licensing of the original project files), but any existing file that you change needs to be contributed back to the project if required. Example type B licenses include Sun's own Common Development and Distribution License (CDDL) which covers OpenSolaris.
Many developers use type B licenses when they want to embed some open source project (say, an operating system) into a bundle (could be an appliance) which is licensed differently. Doing so, they have to keep the original open source project with its license, and thus, with source code available, even if they do modifications in the project files. But they can add their own files, drivers, applications, glue and keep those licensed as they want (even, possibly, commercially licensed).
Finally, type C licenses which tend to be project fostering licenses, are such that like type B, any file you modify from the original source commons keeps the original license, but also, any file you add to the project inherits that project's license. These license inherently seek to propagate open source by, in a way, contaminating what they touch. They are often qualified as viral licenses. Should you bundle your own software with a type-B licensed project, your own software automatically gets contaminated and turned into a type-B licensed code for which you also will have to publish source code as defined in the original project's license. This is great when you want the project community to benefit from any derived works built upon that project. But it can also have the side effect that people using code from these projects are forced into publishing their own intellectual property. Examples of type C licenses include the universally known GNU General Public License (GPL) which is used for example for the Linux kernel. Anything tightly bundled with a Linux kernel has to be licensed under the GPL as well.
In order to make this contamination aspect less constraining, there is a derived licensed based on the GPL called the GNU Lesser General Public License (LGPL). It is possible to link through specific means software to an LGPL licensed project without that software being contaminated by the original license. This enables one to bundle an LGPL project with non LGPL code and keep the licenses different for each part of the bundle. OpenOffice.org is licensed under the LGPL, enabling one to plug pieces of code into proper APIs in OpenOffice.org and keeping these plugins licensed the way initially planned.
A typical example of unplanned contamination would be an appliance vendor that makes small consumer devices that sell in hundreds of thousands of units. In order to limit costs, they elect to use a standard chip set that provides the basic functionality directly, then they pick the operating environment to put on it. For costs and simplicity, they pick en embedded Linux platform. Then they develop their own code and glue. They write device drivers for custom hardware, they write a complete GUI that directly plugs into deeply embedded aspects of the operating system, and device configuration, and they sell the whole thing as a consumer appliance. The problem is when somebody figures out that it's Linux inside... and since Linux is covered by GPL, that means that all the software that is deeply linked to the OS is also, necessarily, made GPL. First of all, they have to make the whole source code available (as per GPL, and any other open source license)... but worse, if they embedded other third party code, they can get into legal issues because that third party tool probably also must be made available under the GPL. It can get nasty. Because they didn't consider the implications in advance.
On the other side, sometimes, you WANT to use a viral license like the GPL. Sun has published the OpenSPARC processor under the GPL exactly with that viral aspect in mind. We want other companies to build fancy, successful, commercial products based on the OpenSPARC processor. We want them to not only benefit from the R&D we did to come up with the OpenSPARC processors, but also, we want them to bring their own enhancements, and contribute back to us the good work they throw into the processor. We want the next hot microcontroler based on OpenSPARC to benefit the whole OpenSPARC development efforts.
So as you can see, there are several types of licenses, each with very distinct characteristics. Choosing one isn't something you do lightly.
In order to choose the right license for you, you must first decide what you want to do with your own project. Deciding if you want to make it commercial, or not. Closed, or open source. You need also think about how you expect your users, and possible developers down the line might want to use or reuse your code into their own projects.
Then, if you are going to bundle your code with third party code, you must carefully examine the license you want for your code, and the available third party projects that fit your requirements and their own licenses. Make sure the one you pick has a license that is compatible with your selected license to avoid legal issues down the line.
As you see, choosing proper open source licenses (in products you will use, as well as in products you will develop) is not necessarily an easy task. Following the above guidelines will help you get a general idea. But probably the best single advice to give is to talk to a lawyer specialized in software licensing. They will help you pick the right license that is best for the model you have in mind for your product. Also, people like the FSF organize licensing workshops. For example, the FSF Europe is running a 'Licensing questions and other legal issues' workshop in Zurich, Switzerland on October 17th, 2008. There may be others in your region to chose from.
Posted at 07:03PM Jul 23, 2008 by gravax in Opensource | Comments[1]
OpenJDK 6 in Ubuntu Hardy!
So yesterday I had a very nice surprise. I moved my old home server from NetBSD (had been running that OS faithfully for the past 7 years - through a few hardware updates - but I've been bitten too many times by pkgsrc updates that broke most of GNOME and required heavy sessions of recompiling individual stuff to fix for my own comfort) to Ubuntu Hardy (I've been using Ubuntu on other laptops for quite some time, since version 6.04).
Basically, I first copied the 550GB of data from the 750GB disk of the NetBSD machine (since Ubuntu can't read the NetBSD filesystem natively) through the network to a new 750GB disk plugged into a Ubuntu machine... That took over 24H... Yech. Then I installed Ubuntu on a 200GB SATA disk and the new 750 GB disk in the small server that had previously been running NetBSD.
My first two steps were installing SqueezeCenter (for my Logitech Squeezeboxen music streamers) and SwissCenter (for my Pinnacle Systems ShowCenter 200 media streamer) which required some fiddling around because of Hardy's new AppArmor security scheme which messed up PHPMySQL... and Apache 2 who is new to me (the old NetBSD machine was running Apache 1.3)... I now have multimedia again at home. accessing
Then I prepared the P2P downloading stuff... aMule and Azureus... And that's where the cool thing happened. First, Azureus is directly in the Ubuntu repositories... which is nice. Second, when I installed Azureus, it naturally added the dependencies, which, to my big surprise, include... OpenJDK 6! Very nicely done! Completely transparent.
(As a note to Azureus authors : Because Azureus uses Eclipse's binary SWT for GUI, it is
not platform independent - which is stupid as it breaks one of the main
interests of using Java... so it wasn't available on NetBSD... which
is why I got used to using the excellent (and lightweight) Transmission BitTorrent GTK+ client. And as such, I guess I will, finally, stick with Transmission also on Ubuntu...)
So automatically, now, on Ubuntu, when needed, OpenJDK 6 gets installed... I'm curious to see how the updates will take place through the Ubuntu update manager. And with what delay compared to the official updates to JDK 6 from Sun. But this is very very good news for the Ubuntu users community, and for the Java world in general. From now on, one can assume that the official JDK will be available in Linux... transparently... just like that, when needed.
Java. There, for you, when, and where you need it!
My next steps include getting Apache 2 fully working with all the relevant virtual domains that I used to host... and also getting the SAMBA file server up and running for the family users on the home LAN. A few more nights of hacking fun in perspective and I'm all set!
Again... thanks Sun and Ubuntu for having made OpenJDK 6 directly available, no hassle, in Ubuntu Linux (and others, as I understand)! A beginning of a new era... Microsoft won't ship Java by default in Windows... fine. Linux will. Guess who wins? 
Posted at 03:26PM Apr 30, 2008 by gravax in Opensource | Comments[8]
Skype 1.4 on Solaris in a Ubuntu BrandZ zone!
At last! I got it working!
Since Solaris Express Developer Edition build 72 (you might have to wait for build 72 to be published), we have experimental support for Linux kernel 2.6 in a BrandZ zone!
Instructions on how to install are here...
What I did was install Ubuntu on a separate machine. Configured the repositories for Skype and Medibuntu. Installed Skype and Google Earth... then did the tar cjf from / as documented in the installation instructions for Linux 2.6 BrandZ zones... and created my zone and installed it from the .tar.gz archive on my Nevada b72 system.
When I did the zoneadm install, I got a bunch of error messages at the end... but despite that, network which was configured as DHCP in Ubuntu picks up the address I hard coded when creating the BrandZ zone (and store in /etc/zones/ubuntu.xml - my zone configuration file).
Note... I had to enable sshd in the Ubuntu zone for this to work.
And despite that, I can't just ssh into the zone... bash starts up when I do so... but doesn't give me the prompt... But I can ssh -X MyZone /command/to/run and run any X11 command...
So what I now do is run ssh -X MyZone /usr/bin/skype and I get Skype up and running.
Note that Skype 1.4 uses only ALSA and BrandZ only maps OSS... so no audio yet.
But I can chat nicely
Skype 1.3 uses OSS... And with that one, in the Ubuntu branded zone, I get proper Audio!
We are making progress!
Gilles.
Posted at 12:03PM Sep 13, 2007 by gravax in Opensource | Comments[16]
Making Money Out Of Open Source
So you're considering writing your application and making it available
in open source. But you're also hoping to make a profit from it. And,
frankly, you're wondering how you're going to make a profit by offering
a product where you make all the sources available for free. Rejoice!
Quite a few people have had this same situation before and have come up
with some pretty good ideas.
We're going to look at a few of them here.
I'm
going to assume, here, that you've already sorted out what kind of
licensing your software will be published under. If not, look for a
soon-to-come entry in my blog about open source licensing and I'll give
you some guildelines on how to pick the correct license(s) for your
project.
Here are six of the most common business models around open source.
This isn't per se
a business model. Rather, it's a way to generate indirect revenue. The
point here is to drive, actively participate in, an open source
project, to ensure that it becomes successful. If it does, you hope
that the reputation of your company will increase from it, and that it
will drive customers to you. It's not easy to live just from that, and
you might want to combine this model with some of the previous ones
above in order to ensure a viable revenue stream.
There.
You have it. Of course, this isn't a definitive list. I'm sure that the
open-source community with it's very bright minds will (probably already has) come up with new, more creative, models for making a living from their collaborative work. So will you.
Now
you have an interesting subject of reflexion while you create your
business plan that you will present to your future investors, that will
show them a proper potential for profits!
Posted at 05:58PM Jun 13, 2007 by gravax in Opensource | Comments[0]
DADVSI - La France vire au totalitarisme?
Après examen par le conseil constitutionnel, la loi DADVSI ressort encore plus durcie. Dorénavant, et de façon encore plus dure qu'initialement prévue, il sera maintenant encore plus difficile, en France, d'accéder à la culture de façon libre et indépendante de constructeurs de matériels ou éditeurs de logiciels multimédias.
Dans un grand pas en arrière, le conseil constitutionnel vient de montrer sa méconnaissance totale de la technologie du 21eme siècle ainsi que sa déconnexion complète avec les réalités des internautes.
En effet, alors que les propositions initiales de la loi DADVSI prévoyaient qu'une personne souhaitant accéder à un media légitimement acquis, mais sur une plate-forme de son choix (par exemple sur une plate-forme moins chère, ou moins sensible aux virus, ou bien avec un lecteur proposé en logiciel libre) était exonéré de poursuites, maintenant, il n'y aura plus ces provisions dans la loi. Ainsi, si je paye légitimement un media, et que je souhaite le lire sur un lecteur que j'ai crée moi même, et que pour ce faire, je suis obligé de contourner les mesures techniques de protection (qui, du coup, deviennent des mesures techniques protectionnistes) mises en place par l'éditeur afin de me contraindre à utiliser uniquement leur lecteur de media, je pourrais être poursuivi. Je n'ai plus accès à la culture de mon pays de façon libre. Je suis contraint de devoir le faire par des équipements (matériels ou logiciels) commerciaux proposes par des éditeurs qui ne sont même pas français. Elle est belle cette culture française qui passe nécessairement par l'achat et l'utilisation de produits américains pour y accéder. Quel cruelle désillusion que nous assène le gouvernement français.
Ensuite, alors que dans les propositions initiales, les auteurs de logiciels d'échanges P2P à but de travail collaboratifs étaient protégés contre des poursuites, le conseil a décidé que la notion de travail collaboratif étant trop floue, il n'était pas possible de distinguer cela. Du coup, les auteurs de logiciels P2P vont se délocaliser hors de France. La France va perdre une partie de son vivier de compétences en développement de logiciels de haute qualité. Non seulement le problème ne sera pas résolu, mais pire encore, on perdra des developpeurs qui iront s'installer dans des pays ou la législation n'est pas faite par des gens n'en ayant pas les compétences, et qui, du coup, ne travaillent que en répondant aux pressions des lobbies commerciaux.
Franchement, là, on atteint le summum. La France, qui partait pour avoir une législation progressiste, s'enfonce dans un totalitarisme tellement déconnecté des réalités qu'on se croirait revenu des décennies en arrière. Il se pose sérieusement la question de quelle attitude les internautes peuvent maintenant adopter pour faire entendre raison à un gouvernement qui a, de toute évidence, perdu le sens des réalités du monde qu'il est censé gérer. Désobéissance civile? Expatriation? Favoriser des outils non développés en France? Manifestations?
Peut-être n'est il pas encore trop tard. Mais la situation est clairement dramatique pour la culture, et pour les internautes qui souhaitent y accéder dans des conditions que notre époque moderne devrait permettre. Espérons que la folie qui a pris le conseil constitutionnel saura être renversée et que l'on reviendra a une situation plus saine. Dans un avenir proche. C'est la culture et les citoyens qui, sinon, vont payer le prix de l'incompétence.
Posted at 03:37PM Aug 02, 2006 by gravax in Opensource |
Saving as ODF, or Exporting to ODF?
Now that states around the globe are starting to mandate the use of
ISO/IEC 26300 (Open Document Format) for storing and exchanging
documents around the world, the legitimate question that arises is how
should this be made available to users of business automation software
suites?
Several approaches have been starting to appear. Native support?
Plug-in? External application? Let's look a bit at what each of these
bring to the user.
There are quite a few software suites that already offer native support
for ODF. OpenOffice.org, Staroffice, KOffice (since version 1.5), IBM's
Workspace, Textmaker, Abiword, Gnumeric, Writely. These applications
have chosen to directly manipulate ODF documents. The result is
extremely comfortable. Any document created is automatically saved in
the ODF format. Groups that have a requirement to use ODF don't need to
worry about inadvertantly saving a document in a legacy or proprietary
format. People with disabilities have simple one-step "Save" and "Open"
operations. No need for convoluted manipulations. This is the most
transparent method.
Using a plug-in can enable an application that doesn't natively speak
ODF to still operate in an environment where regulations require the
use of ISO/IEC 26300 open standard for document management. Depending
on the plug-in API for the application, the result can be made almost
as comfortable as the native support of ODF. Indeed, if the plug-in API
permits the replacement or overloading of the default "Save" and "Open"
functions, it can be just as comfortable as for native support.
Alternatively, the addition of a "ODF Save" or "ODF Open" set of
functions can bring sufficiently close functionality to satisfy
requirements. Note that with adding "ODF Save" and "ODF Open", there is
still a risk that the user may inadvertantly use the old "Save" /
"Open" functions and save the documents in the legacy / proprietary
format that is native to the application. Also, the quality of the
conversion by the plug-in is a critical factor in adoption of this kind
of system. Since the native format isn't ODF in this case, there needs
to be a conversion that is done. The risk that the conversion doesn't
work 100% is there and some documents could come out requiring some
editing in order to be as they are expected. This problem is common to
all situations where documents are converted from one format to another.
Using an external application is an easy to implement solution. In
fact, it doesn't require much work to implement at all. Just take
something that can do the conversion for you, and have it do that for
every document that you need converted, when you need it. You could
imagine doing it that directly from OpenOffice, since it is freely
available, and supports several document formats in addition to ODF.
Installing OpenOffice on a system is a cheap and easy way to get to
this external application mode. Of course, you need a few wrappers so
that you can have a command line or graphical user interface to control
document conversion. The really serious drawback here is for people
with disabilities. Since this type of process requires up to several
additional steps. So of course, it becomes much less comfortable. And
also, the risk of users deciding to not use the approved format, just
for sake of ease of use, is high, putting administrations at risk if
they are constrained by regulations to use ODF. Same limitation about
quality of converters applies here as for plug-in approach. Make sure
the conversion tool you pick is very good or your experience will be
negative, because of that tool, not because of ODF.
Another problem related to both plug-in and external application
approach is that, if users are tempted to still save in legacy format
and only convert when they need to interact with other official
entities, they will use features that are hard or impossible to convert
between their legacy / proprietary format and the ODF. They will be
tempted to rely on these features and, when it is time to convert the
documents, will have to go through great pains to make the documents
compatible between the two formats. Result will be a negative
experience.
In summary, whatever method chosen, great care should be taken to
ensure the following points:
1) Quality of the conversion. If documents get badly converted, the
interest of the approach will not be bery high.
2) Ease of use of the generation of ODF documents. The more required
steps the harder it is and will impact users with disabilities.
3) Temptation to not save in ODF format (linked to ease of use, also).
Look at the risk that non ODF documents will be generated in day-to-day
use because it's easier. That leads to predictable future problems when
having to convert them to ODF to communicate with others.
Chose what suits your needs best, and enjoy a new world of open
standards where everybody can exchange information regardless of the
application each individual or service elects to use!
Posted at 11:53AM Jul 11, 2006 by gravax in Opensource | Comments[0]
La France vote la plus mauvaise loi sur les droits d'auteurs possible
Voila,
c'est fait.
Après
un feuilleton à épisodes multiples,
après des
sessions au dernier moment pour tenter de faire passer un projet en
douce, après avoir clairement montré un
dédain
quasi total pour l'opinion du public, et des acteurs du monde libre,
le gouvernement français a fini par voter un texte de loi
désastreux.
Comme je l'ai écrit plus tôt,
ce projet va conduire à mettre en marge de la
société
toute une population d'auteurs de logiciels libres qui jusqu'a
présent pouvaient exercer leurs talents à
écrire
les applications qui font tourner l'industrie, mais aussi certains
services de l'administration française.
Ces auteurs se
voient maintenant présenter une épée
de
Damoclès. Si ils sont responsable de la création
d'un
logiciel qui s'avère être massivement utilise pour
faire
de l'échange de fichiers soumis à droit d'auteurs
(je
pense ici à des serveurs web comme Apache,
à des
serveurs de courrier électronique comme Sendmail,
à des
systèmes d'exploitation comme Linux,
NetBSD,
et tant
d'autres), alors grâce aux délires
votés la
semaine dernière, ils
seront susceptibles d'êtres
accusés de contrefaçon (entres
autres). Le ridicule atteint le
summum.
En fait, ce qui risque de se passer maintenant en
France, c'est que les auteurs de ce genre de logiciels libres
quitteront la France, pour aller s'installer et faire tourner
l'économie de pays ou la législation est plus
compréhensive, plus raisonnable, plus en phase avec les
réalités
du monde, moins soumise aux pressions
de quelques gros lobbies économiques comme l'industrie des
medias.
Comme l'était conclue l'émission de
télévision pendant l'époque du
McCarthyisme,
bonne nuit... et bonne chance. On va en avoir besoin, en France, si
on travaille dans le monde du logiciel libre.
Posted at 05:39PM Jul 03, 2006 by gravax in Opensource | Comments[5]
Loi DADVSI - Commission Paritaire Senateurs / Deputes - L'interoperabilite en question
Dans quelques jours, un petit groupe de sénateurs et de députés vont se réunir
en commission mixte paritaire, pour décider de l'avenir du projet de loi
DADVSI.
En particulier le but est de statuer sur les différences entres le projet de
loi tel que proposé par l'Assemblee, et celui retenu par le Sénat.
Les différences sont significatives. Entres autres en matière
d'interopérabilité des mesures techniques de protection. Le projet du Senat
cède aux pressions de l'industrie des media et abandonne complètement
l'attitude progressiste qu'avait adopté l'Assemblée en protégeant la
possibilité pour un auteur d'un logiciel de lecture de media de pouvoir
analyser des mesures techniques de protection mises en oeuvre dans un lecteur
de media existant afin de pouvoir créer sa propre impleméntation compatible.
Cette attitude était bienvenue car souvent, les acteurs bien établis de
l'industrie ne voyant pas d'un bon oeil cette interoperabilité forcée, les
informations necessaires pour qu'un auteur puisse creer un outil
intéroperable ne sont mises à disposition que à contre coeur, et après de
longues négociations, et souvent contre un paiement trop élevé pour un auteur
individuel de type auteur de logiciel libre.
En réaffirmant le droit à la recherche de l'interopérabilité reconnu par le
droit européen, les députés avaient, en fait, su éviter l'écueil de rajouter
une insécurité juridique à ces difficultés en indiquant clairement que les
éléments logiciels d'une mesure technique peuvent être décompilés à des fins
de recherche de l'interopérabilité, indépendamment de la protection juridique
de la mesure technique. Ils avaient aussi su créer les conditions nécessaires
au développement de l'interopérabilité en posant un principe de
non-discrimination dans la loi de façon à ce que tout acteur puisse obtenir
les informations essentielles à l'interopérabilité; quelque soit son modèle
économique (logiciel libre ou flogiciel propriétaire).
Dans ces conditions, les propositions du Sénat sur l'article 7 et sa refonte
quasi-totale sont allés dans un sens qui retire aux auteurs de logiciel libre
la possibilite de créer des lecteurs de medias compatibles avec ceux
existant, déjà simplement en interposant des mécanismes administratifs lourds
de type autorite de mesures techniques, qui ralentira les démarches des
éditeurs de logiciels libres a un point qui rendra leur action quasiment
impossible dans le monde des affaires très rapide dans lequel nous vivons
aujourd'hui.
En prévoyant de plus explicitement la possibilité pour cette autorité des
mesures techniques d'interdire la publication d'un code source, les sénateurs
ont pris l'exact contre-pied des députés, ils semblent considérer le logiciel
libre comme un modèle dangereux et le propriétaire comme la norme. Ils
pratiquent la discrimination par ignorance.
Le risque, pour la France, c'est que les éditeurs de tels logiciels se
retrouvent dans des pays plus raisonnables, comme la Norvège, au détriment de
l'industrie du logiciel en France. Tout le monde y perdra : les consommateurs
de biens culturels, les auteurs de logiciels libres - moteurs de l'innovation
technologique dans le monde des technologies de l'information. Et cela
pourquoi? Pour avoir cédé aux pressions de quelques industriels craignant que
les changements technologiques mettent en péril leur marche.
Pourtant l'industrie le montre, les mesures techniques de protection, peuvent
tout a fait exister dans un monde de logiciel libre, avec toutes leurs
sources et spécifications publiques. Alors pourquoi ne pas favoriser cette
situation progressiste ou pour tous les acteurs de l'industrie du logiciel,
des systèmes tels que les mesures techniques de protections doivent
absolument etre ouvertes pour permettre l'interoperabilite. Soit parce
qu'elles sont open source... soit parce que les auteurs de logiciels libres
peuvent les analyser a loisir afin de creer des versions intéroperables, sans
contrainte aucune.
Posted at 04:00PM Jun 20, 2006 by gravax in Opensource | Comments[0]
DADVSI – Le Sénat a Voté
DADVSI – Le Sénat a Voté
Et la situation est pire.
Le 10 mai 2006, le Sénat c'est prononcé sur le projet de loi DADVSI. Le résultat est catastrophique pour le monde de l'open source et de l'interopérabilité.
Tout d'abord, l'article 7 qui prévoyait de permettre la création de lecteurs de medias interopérables avec des produits, proprietaires, existants, quitte à pratiquer du reverse engineering si les auteurs des logiciels existants ne fournissaient pas la documentation nécessaire à cette interopérabilité a été purement et simplement retiré.
Le salut semble venir d'un article proposé par le sénateur PS David Assouline, mais au final, il y a tout autant de risques pour la communauté du logiciel libre. Voici quelques extraits, parlants, du texte, et les commentaires à leur sujet.
Le premier passage est :
«
Art. L. 335-3-1. - I. - Est puni de 3 750 € d'amende, le fait
de
porter atteinte sciemment, à des fins autres que la
recherche, à une
mesure technique efficace telle que
définie à l'article L. 331-5, afin
d'altérer
la protection d'une œuvre par un décodage, un
décryptage
ou
toute autre intervention personnelle destinée à
contourner,
neutraliser ou supprimer un mécanisme de
protection ou de contrôle,
lorsque cette atteinte est
réalisée par d'autres moyens que
l'utilisation
d'une application technologique, d'un dispositif ou d'un
composant
existant mentionné au II.
« II. - Est puni de
six mois d'emprisonnement et de 30 000 € d'amende,
le fait de
procurer ou proposer sciemment à autrui, directement ou
indirectement, des moyens conçus ou spécialement
adaptés pour porter
atteinte à une mesure technique
efficace telle que définie à l'article
L. 331-5,
par l'un des procédés suivants :
« 1°
En fabriquant ou en important une application technologique, un
dispositif ou un composant, à des fins autres que la
recherche ;
« 2° En détenant en vue de la
vente, du prêt ou de la location, en
offrant à ces
mêmes fins ou en mettant à disposition du public
sous
quelque forme que ce soit une application technologique, un
dispositif
ou un composant ;
« 3° En
fournissant un service à cette fin ;
« 4° En
incitant à l'usage ou en commandant, concevant, organisant,
reproduisant, distribuant ou diffusant une publicité en
faveur de l'un
des procédés visés aux 1°
à 3°.
« III. - Ces dispositions ne sont pas
applicables aux actes réalisés à
des fins
d'interopérabilité ou de
sécurité
informatique, dans les
limites des droits prévus par le
présent code.
Cela semble, au premier abord, favoriser l'interopérabilité. Bien sur, il va être difficile de poursuivre les auteurs de logiciels de contournement de mesures techniques de protection, car ceux-ci sont souvent dans des pays lointains, voir sont des contributeurs anonymes ou des groupes distribués sur toute la planète.
C'est aussi intéressant car semblant autoriser le reverse engineering pour l'identification de problèmes de sécurité. Et on a vu récemment des exemples frappants de mesures techniques de protection qui avaient causé par leur méthodes de dissimulation dans l'ordinateur des failles très sérieuses de sécurité. C'est donc, en partie, une bonne chose.
Mais cela se corse après.
Art.
L. 122-6-1. I. Les actes prévus aux 1° et 2°
de
l'article L.
122-6 ne sont pas soumis à l'autorisation de
l'auteur lorsqu'ils sont
nécessaires pour permettre
l'utilisation du logiciel [1], conformément
à sa
destination, par la personne ayant le droit de l'utiliser, y
compris
pour corriger des erreurs [2]. [3]
Toujours,
ici, la possibilité de
faire du reverse engineering pour identifier des bugs. Bien. En
apparence.
Toutefois,
l'auteur est habilité à se réserver
par contrat
le droit
de corriger les erreurs et de déterminer les
modalités particulières
auxquelles seront soumis
les actes prévus aux 1°. et 2°. de l'article
L.
122-6, nécessaires pour permettre l'utilisation du logiciel,
conformément à sa destination, par la personne
ayant le droit de
l'utiliser.
II.
La personne ayant le droit d'utiliser le logiciel peut faire
une
copie de sauvegarde lorsque celle-ci est nécessaire pour
préserver
l'utilisation du logiciel.
Voilà qui est intéressant. J'ai donc le droit de faire une copie de tout logiciel dont je dispose légitimement, afin de préserver l'utilisation de ce logiciel. Hélas, aujourd'hui, de nombreux mécanismes de protection contre la copie, tels SecuROM ou StarForce, vont exactement à l'opposé de ce que dit ce paragraphe, puisqu'une copie d'un CD protégé par ces mécanismes ne fonctionnera plus (le logiciel vous gratifiant d'un « veuillez insérer le CD d'origine dans le lecteur »). La seule façon pour l'utilisateur légitime d'un logiciel protégé par ce genre de mécaniste d'utiliser une copie effectuée légitimement sera d'utiliser l'un des nombreux outils qui permettent leur contournement, ou d'intenter un procès aux éditeur de ces logiciels. Belle pagaille en perspective.
III.
La personne ayant le droit d'utiliser le logiciel peut sans
l'autorisation de l'auteur observer, étudier ou tester le
fonctionnement de ce logiciel afin de déterminer les
idées
et
principes qui sont à la base de n'importe quel
élément
du logiciel
lorsqu'elle effectue toute opération de
chargement, d'affichage,
d'exécution, de transmission ou
de stockage du logiciel qu'elle est en
droit d'effectuer.
Heureusement
que les utilisateurs de logiciels peuvent examiner le fonctionnement
de ces produits sur leur environnement sans avoir à demander
l'autorisation de l'auteur. Compte tenu des exemples passés
de
dérives liées à l'utilisation,
à l'insu
de l'utilisateur, de méthodes de protection qui ont
posé
un grave danger pour l'intégrité de la machine de
l'utilisateur, il est nécessaire de permettre aux
utilisateurs
avertis de surveiller attentivement ce que fait un logiciel tournant
sur leur machine, et comment il le fait. D'ailleurs, dans le cadre du
logiciel libre, cette autorisation est explicitement donnée
par la licence, et le logiciel est accompagné du code source
permettant de s'assurer en effet que rien de néfaste ne se
fait à l'insu de l'utilisateur.
IV.
La reproduction du code du logiciel ou la traduction de la
forme
de ce code n'est pas soumise à l'autorisation de l'auteur
lorsque la reproduction ou la traduction au sens du 1°. ou du
2°. de
l'article L.122-6 est indispensable pour obtenir les
informations
nécessaires à
l'interopérabilité
d'un logiciel créé de façon
indépendante
avec d'autres logiciels, sous réserve que soient
réunies
les conditions suivantes : [4]
1° Ces actes sont
accomplis par la personne ayant le droit
d'utiliser un exemplaire
du logiciel ou pour son compte par une
personne habilitée
à cette fin ;
Si une personne est en train de faire un logiciel interopérable pour lire un media c'est sans doute qu'il n'a pas à sa disposition la plate-forme d'origine prévue par l'auteur du logiciel propriétaire. Pourquoi devrait-il alors acheter (cas de logiciels payant) une plate-forme dont il n'aura pas l'usage?
2°
Les informations nécessaires à
l'interopérabilité
n'ont pas déjà
été rendues facilement
et rapidement accessibles aux personnes
mentionnées au 1°
ci-dessus ;
Il
faudrait définir ce que veut dire
« facilement et
rapidement ». En effet, cela peut avoir pour effet
de
bloquer le marché . Si un film sort mondialement
à une
date unique mais que pour le lire chez soi il faut obligatoirement un
lecteur propriétaire qui ne tourne que sur une seule
plate-forme. Les possesseurs d'autres plate-formes devront se
créer
des lecteurs interopérables pour pouvoir accéder
à
ce film. Hélas, la société qui le
publie peut
décider de faire traîner les choses... 1 mois? 2
mois? 6
mois? Est-ce que les utilisateurs de plates-formes alternatives
doivent être victimes, alors, d'une culture à deux
vitesses? Le fait de devoir attendre que les auteurs de logiciels
propriétaires daignent bien vouloir publier les informations
d'interopérabilité va avoir pour effet de
ralentir
l'accès à la culture à toute une
tranche de la
société.
3°
Et ces actes sont limités aux parties du logiciel d'origine
nécessaires à cette
interopérabilité.
Voilà
un élément qui semble, enfin, justifié.
Les
informations ainsi obtenues ne peuvent être :
1° Ni
utilisées à des fins autres que la
réalisation
de
l'interopérabilité du logiciel
créé
de façon indépendante ;
Il
va falloir définir ce que
signifie, ici, « crée de façon
indépendante ».
2°
Ni communiquées à des tiers sauf si cela est
nécessaire
à
l'interopérabilité du logiciel
créé
de façon indépendante ;
Voici
un boulet tiré directement
en direction de la communauté du logiciel libre. En effet,
les
informations permettant de créer un logiciel
interopérable
se retrouvent intégralement dans le source (public, donc,
puisqu'on parle d'open source / logiciel libre) du dit logiciel.
Est-ce que les auteurs de logiciels open source
interopérables
avec les logiciels propriétaires vont automatiquement se
trouver coupables, au titre de cette loi, d'avoir
« communiqué
à des tiers » les
« informations ainsi
obtenues »?
3°
Ni utilisées pour la mise au point, la production ou la
commercialisation d'un logiciel dont l'expression est
substantiellement similaire ou pour tout autre acte portant
atteinte
au droit d'auteur.
Ici,
en une phrase, on casse tout le
travail effectué. En effet, si on veut créer un
logiciel interopérable avec un lecteur de media, alors il ne
doit pas être utilisé en tant que lecteur de
medias?
Cela enlève automatiquement tout
l'intérêt de
créer un logiciel interopérable. Ceci, plus le
point
juste au dessus, signe l'arrêt de mort des logiciels lecteurs
de medias open source interopérables avec les produits
similaires propriétaires. Beau travail de protectionnisme.
V.
Le présent article ne saurait être
interprété
comme permettant
de porter atteinte à l'exploitation
normale du logiciel ou de causer
un préjudice injustifié
aux intérêts légitimes de l'auteur.
Toute
stipulation contraire aux dispositions prévues aux II, III
et
IV
du présent article est nulle et non avenue.
Cela semble, à priori, raisonnable, mais il va falloir définir quels sont les « intérêts légitimes » des auteurs (ou, plus probablement, des détenteurs de droits). Ainsi, si l'intérêt légitime est de contraindre les utilisateurs à utiliser un produit commercial particulier pour lire ses medias, alors, le fait de créer des lecteurs interopérables ne nécessitant plus le verrouillage sur ce produit commercial particulier va « causer un préjudice injustifié aux intérêts légitimes de l'auteur »... donc, la encore, sous des semblants de raison, on cède au protectionnisme des auteurs de logiciels propriétaires.
Le pire, la dedans, c'est qu'on a bien vu et démontré qu'il était possible de faire des logiciels de type DRM en open source, en publiant toute l'information nécessaire à la création d'implémentations interopérables. Alors pourquoi ne pas se rendre à l'évidence et accepter ce besoin, légitime, des utilisateurs de medias, les citoyens consommateurs de biens culturels, de pouvoir, en effet, avoir accès à leur culture par le moyen qui leur convient le plus? Pourquoi favoriser une culture verrouillée par les intérêts et outils de quelques groupes industriels, plutôt que de permettre un accès, dans le respect des droits légitimes des auteurs, à toute la population, indépendamment de ses choix technologiques?
Posted at 02:41PM May 11, 2006 by gravax in Opensource | Comments[0]
Le Sénat français en train d'examiner le nouveau projet DADVSI
Toujours plus de propositions dangereuses pour les éditeurs de logiciels
Voilà... C'est maintenant en cours d'examen au Sénat. Le projet issu des votes des parlementaires a encore été modifié et, de nouveau, on se trouve dans une situation ou, comme avant, on constate une très mauvaise compréhension du monde du logiciel, et en particulier du logiciel libre. Certains amendement proposés, comme, par exemple, le numéro 26 de Mr Thiollière proposent ceci : « Art. L. 336-2. – Lorsqu'un logiciel est principalement utilisé pour la mise à disposition illicite d'oeuvres ou d'objets protégés par un droit de propriété littéraire et artistique, le président du tribunal de grande instance, statuant en référé, peut ordonner sous astreinte à l'éditeur du logiciel toutes mesures né cessaires à la protection desdits droits et conformes à l'état de l'art. » Le gros problème ici est que dans le monde du logiciel libre, on ne peut rien imposer à qui que ce soit. Le principe même du logiciel libre est qu'il est développé par un groupe non nécessairement structuré de personnes ayant un intérêt commun. Il n'est pas forcément possible d'identifier un éditeur (moral ou physique) et, de plus, les développeurs peuvent être répartis sur plusieurs pays. Ensuite, dans le cas d'un logiciel libre, par sa nature même, qui consiste à mettre à disposition de l'utilisateur final le code source même du logiciel, des mesures techniques telles que mentionnées dans l'amendement ne seraient jamais mises en oeuvre par l'utilisateur final qui, bien évidemment, commencerait avant même toute utilisation du logiciel, par les retirer pour ne plus en entendre parler. Et il est impossible d'empêcher ce retrait car l'utilisateur final a toute liberté de faire toutes modifications souhaitées au code d'un logiciel libre qu'il choisit d'utiliser.
Autre retour en arrière, l'amendement 73 propose le retrait pur et simple de l'article 7. Cet article (7, donc) proposait, initialement, de permettre, à des fins d'interopérabilité, que les développeurs de logiciels de lecture de medias puissent accéder aux information (documentation, APIs) leur permettant de lire des medias codes par une mesure technique de protection tierce. Ainsi, une personne ayant acheté un media code pour ne fonctionner qu'avec un lecteur d'une certaine marque pourrait, soit utiliser un logiciel tiers, soit développer soi même un logiciel lui permettant d'utiliser légitimèrent ce media sur une autre plate-forme que celle prévue à l'origine. Un peu comme quelqu'un qui a acheté un CD il y a 15 ans, peut, même si ça n'avait pas été prévu à l'époque, aujourd'hui, le lire sur son PC. L'article 7 prévoyait, de plus, que si les APIs ou la documentation ne sont pas disponible (par exemple dans le cas d'un éditeur de logiciel récalcitrant) il serait possible a un développeurs tiers de procéder à une décompilation ou tout autre procédé adéquat (« reverse engineering »), du logiciel propriétaire de lecture du media pour permettre d'en extraire les informations lui permettant de créer un logiciel interopérable avec ces medias. Ainsi, avec l'article 7, on garantissait que la culture n'était pas réservée aux possesseurs de lecteurs de medias spécifiques, mais vraiment (comme la culture devrait l'être) accessible a tous, dans le respect des droits de l'auteur. Ceci est d'autant plus important que Sun a montre avec DReaM que l'on pouvait mettre en oeuvre un système de mesures techniques de protection (DRM en Anglais) qui soit sous forme de logiciel libre (open-source) et donc permettant a tous de créer librement des implémentations interopérables pour des lecteurs de medias. Il n'y a donc pas de raison de vouloir a tout prix empêcher l'interopérabilité de systèmes de protection de contenu soumis à droits, sauf pour des considérations purement protectionnistes d'éditeurs de logiciels propriétaires.
Le risque est grand que le Sénat vote une série de lois qui ne soit pas en phase avec les réalités techniques du marche, et, donc, ne soit pas applicables, et distinguent la France pour les mauvaises raisons dans le monde des éditeurs de logiciels, libres ou propriétaires.
Posted at 11:44AM May 10, 2006 by gravax in Opensource | Comments[0]
Today's Page Hits: 122