Gilles Gravier's Weblog

Gilles Gravier's rants about things in general... security, open source, privacy, java, music... in particular.


Main | Next page »
Thursday Oct 22, 2009

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.

Friday Oct 16, 2009

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. :)

Tuesday May 12, 2009

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!

Sunday Apr 26, 2009

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!

Tuesday Apr 14, 2009

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"!


Wednesday Jul 23, 2008

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.

  • How do you plan to license your own software within your product 
  • What license applies to the third party software you are bundling and how does it interact with, or impact your own 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 :

---

The Open Source Definition

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

The license must not discriminate against any person or group of persons.

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

No provision of the license may be predicated on any individual technology or style of interface.

---

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 : Unrestrictive licenses 
  • Type B : File-based licenses 
  • Type C : Project-based licenses 

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.

Wednesday Apr 30, 2008

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? :)


Thursday Sep 13, 2007

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.


 

Wednesday Jun 13, 2007

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.

Dual license


Under a dual license model, you would publish your product in 2 ways. One would be an open source license, say GPL, CDDL, BSD, so free to download and use and modify. The other would be a different license, possibly a commercial one. In this case, you would probably elect to bundle, with your original software, additional features that bring value-add, justifying that a customer might want to purchase that bundle rather than download the purely free open-source block.

Some of the features that you could consider bundling might include :

  • Multiple dictionnaries for spell checking (case of Sun's Star Office, compared to OpenOffice.org which only comes with one dictionnary by default).
  • Fancy administration tools
  • Enterprise-class management / monitoring

Picking the right set of additional commercial features is critical to generating demand for the commercial version of your product, so should be the fruit of very serious thinking.

Subscription


Here, you aren't really selling a product, but rather services around your products in order to make it useable in enterprise deployments. So for example, you'd be looking at offering services like :

  • Support
  • Training
  • Installation
  • Integration
  • Customization

Your typical customer running a mission critical sales server would not want to do that without a very efficient support service available to help them fix things if their system breaks down smack in the 15 days before christmas when they make 80% of their yearly revenue... And they will pay for that kind of support.

Some companies like JBoss (now part of Red Hat) have become very popular using just that model.

Sun now offers most of its software products also under that model. You download and use Solaris for free, but we'll offer you world-class support contracts to ensure proper response to incidents should they happen.

Hosted

Think "Utility Computing". Some of your customers just don't want to run a datacenter. Let's face it, their company isn't in the business of running computers, it's selling the products they make or trade. So why invest hundreds of thousands of dollars in running a datacenter when others can do it for you. Well, that's where you come in. You make your software available for free. Fine. You even give away the sources. Better. But you (directly on your site, or through a partner hosting company) offer also that software as a service, for a fee.

Sun develops a free Grid Engine. You can download it. You can use it. But we've built a grid for you that you can connect to, and purchase CPU cycles on, in order to upload your applications on it, or use the ones we provide, to run your enterprise on by processing your data sets.

Companies like SalesForce.com also have a similar model

Consulting


This is one very nice area of the open-source community where everybody benefits from the work done. This model has led to the creation of many local businesses, as well as whole divisions of global comsulting firms, that specialize in delivering consulting services around existing open-source software. They will take a set of products that they consider being interesting by their standards, and offer a whole set of services around them

This is interesting in many cases, but here is a particular example of where it benefits the original software author. Suppose that the software author is a local company in, say Europe. They don't have the size to distribute and, more importantly, support, their product all over the planet. But if their product is sufficiently interesting, chances are that they will have users on every continent. So what do they do? Probably nothing... because in places where there are enough users that have shown a need for proper services around the products, there will likely be some small, local, but highly competent groups of people that will set up a structure to distribute, and more importantly support with services like first level support, integration, training... your product. You might even want to consider striking a partnership deal with these local structures and make some money off of it, to your mutual benefits.

Near where I work in Geneva, there's a small company called LynuxTraining. They do just that with their sister company LynuxSolutions.

Embedded


Some companies have found that they could build a very fancy product, but that they could gain a lot of time by not re-inventing the wheel, but, rather, by re-using something already available. In most cases, this will be something like an infrastructure component. Think about it. If you are going to build a computer, will you design your own CPU? Probably not (though in some cases, this has been known to happen). Well, same applies to things like an operating system. If you are going to build an appliance, you might want to use an existing operating system. You will pick that OS according to the needs of your appliance. Do you need real-time? You might pick something like QNX. If you're building an extremely secure security appliance, like AppGate's Security Server, you would pick Sun's ITSEC EAL 4+ certified Solaris 10. You might even want to build a vertical solution for office automation based on the open-source OpenOffice.org. Be careful what license governs the product you pick to embedd, as you might be forced to give away some or all of the source code of additional code you've written to make your whole product due to license contamination issues.

Stewardship


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!

 

Wednesday Aug 02, 2006

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.

Tuesday Jul 11, 2006

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!


Monday Jul 03, 2006

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.



Tuesday Jun 20, 2006

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.

Thursday May 11, 2006

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?



Wednesday May 10, 2006

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.




Today's Page Hits: 49