Reading the latest Linux Kernel developers' position Linux Kernel developers' position about the GNU General Public License version 3 drafting process, I tend more and more to follow their position on the subject. I was already not in favor of the extended clause about Patent into the draft version 3. The reason behind was not the one followed by the kernel developers. My main concern is to justify the existence of the patent system for computer program. Validating the system, not really existing in EU, could be quite dangerous and open the gates to justify its creation. The section 7. of the GNU General Public License is clear enough and while not playing directly in the patent field. The section 11. of the current draft of the GPL version 3 is more difficult to understand and could be used as an argument to not use the GNU General Public License and/or block the use of the patent system as a defensive tool (ok, not always a good idea). But excluding the possibilty for potential developers to use the latest version of the free software license is limiting the potential extension of free software… I'm also wondering why the potential geographic limitation (like the ITAR restriction) is included by default in the draft. I still don't understand why is by default ? The less potential ground for creating restriction seems better for free software.
Other free software authors are willing to keep the GNU General Public License version 2 only, like BusyBox… Will you use the "or later" clause or the v2 only clause ?
Update : The current view of Alan Cox about the draft of the GPL version 3 is quite interesting. The vagueness of the GPL version 2 was an advantage as the FSF was doing his own and clear interpretation of the license. If the FSF is trying to be objective in the next version, we start to have a very fixed free software license where FSF couldn't "extend" when required (and the lawyers will have the final word). I'm pretty sure that the final interpretation of the version 2 of the license at the FSF was not really fixed at the date of its publication. I hope that the FSF will enhance the latest revision to something more flexible… for them.
Update2 - 2006-11-27 : A potential update in the current GPL version 3 draft is quite interesting. The latest "deal" between Novell and Microsoft using software patents to create a kind of isle between part of the free software. That problem could be fixed in the updated draft of the GPL version 3. That has been stated by Richard Stallman during a conference - http://www.fsfeurope.org/projects/gplv3/tokyo-rms-transcript:
[Section: The Novell and Microsoft example]
However, there's another way of using software patents to threaten the users which we have just seen an example of. That is, the Novell-Microsoft deal.
What has happened is, Microsoft has not given Novell a patent license,
and thus, section 7 of GPL version 2 does not come into play.
Instead, Microsoft offered a patent license that is rather limited to Novell's customers alone.
It turns out that perhaps it's a good thing that Microsoft did this now, because we discovered that the text we had written for GPL version 3 would not have blocked this, but it's not too late and
we're going to make sure that when GPL version 3 really comes out it will block such deals.
We were already concerned about possibilities like this, namely, the possibility that a distributor might receive a patent license which did not explicitly impose limits on downstream recipients but simply failed to protect them.
What if one company pays Microsoft for a patent license where Microsoft says "Alright, we won't sue you, but we're just not making any promises about your customers if they redistribute it".
We had already written a downstream shielding provision into GPL version 3 saying
that if you convey the program, and you are benefiting from a patent license that is not available, that does not extend to the downstream users,
then you have to do something to shield them.
This is, it turns out, inadequate in two ways. First of all, "shielding them" is vague. We're replacing that with a specific list of methods, and second, once again it assumes that the distributor has received a patent license,
so the Microsoft/Novell deal cunningly does not give Novell the patent license, only Novell's customers.
Well, now that we have seen this possibility, we're not going to have trouble drafting the language that will block it off. We're going to say not just that if you receive the patent license, but if you have arranged any sort of patent licensing that is prejudicial among the downstream recipients, that that's not allowed.
That you have to make sure that the downstream recipients fully get the freedoms that they're supposed to have. The precise words, we haven't figured out yet. That's what Eben Moglen is working on now.
Yes, such text introduced in the license will continue to support software patent but on the other hand, it starts to block the illegitimate usage (if there is any legitimate use of software patent ;-).
After the ridiculous legal battle from CopiePresse, I made a very quick-and-dirty Python script to archive the latest article from a well known french-speaking news site in Belgium. The script is valid for any website providing an RSS/RDF feed. Here is an example containing the archived article. I don't know if a bot from a search engine company will crawl the archived articles ;-) I hope that the belgian press editors will come back to reality in the following weeks…
As a belgian citizen, I voted today in Les Bulles for the local and provincial elections. It took me five minutes (including the way by foot to the local school) to do my vote. The process of the vote was controlled by randomly selected local people (this year, including steph). It's the classic voting system : two papers and a red pencil, nothing more. Efficient (if the red pencil is broken, the replacement could be done by a human able to carry twenty grams), under constant review (the process can be controlled by any human having two eyes (one is possible too;-))), fast (two papers : one the local election and one for the provincial election)… So I was very happy to still use the classical paper voting. Computers were invented in order to ease the use/access of information or speed up operation. Are the computers useful for voting ? I don't think so. They don't bring too many advantages compared to the paper-based voting. The principal advantage (the only one ?) is to obtain quickly the results (mainly useful for the media and the politicians not really for citizen). For the rest, it's very expensive, not easy (possible? just think about the article of Ken Thompson about Reflections on Trusting Trust) for reviewing, difficult to replace when broken, setup is more important than installing a pencil, difficulty of accessibility and has a multitude of dependencies (just think about electrical power and helpdesk). Only some organizations (poureva in Belgium) are fighting against the electronic vote. I hope that more and more citizen will understand the risks with the electronic voting systems. Yes, fraud is possible in paper-based voting but it's more easy on a large scale in an electronic voting systems as all the voting office received a black box. Vote for paper-based voting, nothing else !
To assure honest elections, we need physical ballots that can be used for a recount. Richard Stallman
As you are maybe aware, I have a kind of interest in Netflow for some security monitoring projects. The past days, I was looking in the different methods to export Netflow on dedicated devices in a dynamic network connectivity. First, what do I mean by a "dynamic network connectivity" ? It's a connectivity where you have not that much control over the allowed protocols or communication mechanisms able to cross that network. The typical example is an Internet connectivity over a GPRS network or in a hotel room. You have for example only HTTP access and nothing more. It's often very difficult to know what will be the protocol in such environment. For a project in the area of emergency, this is very comment to have such "dynamic environment". We decided in a project to use Netflow version 5 and ipfix as a common method to monitor ip flows. The major issue in the project is that we cannot rely on a full tcp/ip connectivity to Internet or other IP networks. The idea was to use the common available protocols in such environment to "tunnel" netflow. The two main protocols often available are : DNS (name resolution) and HTTP. In the beginning, I was planning to use DNS-based transport mechanism. The DNS client (on the monitored device) is sending specific request to a specific domainname maintained by a specific nameserver. In order to overcome the DNS limitation (e.g. : the size of the UDP packet or the query method available), I was planning a method like the one used by the Malware database. The idea was to split each PDU of a Netflow datagram into a sequence of DNS queries. I quickly discovered with a small prototype using dpkt that was the wrong way. Two many DNS queries for a small amount of Netflow datagram in another word, too much overhead. But I left the approach due to the fact that a majority of DNS servers are discarding some requests using a "GPRS¨ provider (to limit DNS tunneling or use of bandwidth ?). So the remaining transport mechanism in a "dynamic network connectivity" is HTTP and very often proxified. As the first testing version is using Netflow version 5, the protocol used by the Netflow exporters, in that case, is UDP. I found a way to encapsulate UDP using HTTP with firepass (and it works quite well for non-interactive protocols like Netflow). I didn't want to go in the direction of a full-featured VPN/Tunnel/IP-over-HTTP as the cost of setup could be quite important and it's not very welcomed in such "dynamic environment". I'll use a similar Netflow-over-HTTP approach for the following weeks and keep you inform of any evolution.
Blog entry also available on the flowog site
Security and Free Software ?
This week, I made a very quick presentation at a free software conference about the result of the hack.lu 2006 (a computer security conference in Luxembourg that I co-organized with other members of the CSRRT-LU). They were asking me about the status of Free Software in the world of "computer security". Sorry to say that but security is not a default feature in software. Sofware is essentially unsecure, crappy and unstable. This is valid for free software and proprietary software. The main and essential benefit of free software is its ethical value not its practical value.
At first glance people, listening to the FUD spread by media, found the statement strange as they were quite sure that free software is inherently secure. This is plain wrong; Software is software and designed, often by default, to be crappy. Of course, Free software is providing some advantages (the famous 4 freedoms) over proprietary software to make it less crappy, more stable and more secure. But the authors and users of free software must use the possibilities offered by those freedoms to build better software. It's clearly not an easy task as the software is not alone in that hostile environment. Just take a look at the presentation of Wietse Venema to build a "simple" file shredder… you'll see that's near impossible to write such software (and by so, you have to think about other paths).
We are all writing unsecure, unstable and crappy software. Some knows that but a majority will never notice.
![[FSF
Associate Member]](http://www.foo.be/fsfbutton-adulau.png){kind=small}
