What’s Free/Libre/Open Source Software?

1. What’s Free/Libre/Open Source Software?
From SME Guide

It may be a surprise to discover that the software market that we take for granted, based on the idea of “shrinkwrapped” packages that are easy to buy directly by the user is relatively recent. In the beginning, software was bundled with hardware by the manufacturer. Due to the complexity and cost of development (and the relatively limited power of those first computers), to the business models of the manufacturers (based on selling hardware), and to other factors, users freely shared source code and advice, in a collaborative way that led to the creation of user groups like SHARE (Society to Help Avoid Redundant Efforts, founded in 1955 and centered on IBM systems) and DECUS (for Digital Equipment computers and later for HP systems), both still alive. Code was also commonly shared in academic journals, like the famous “Algorithms” column of the “Communications of the ACM” journal.

With the “unbundling” process (the separation of hardware and software catalogues) the first “packaged” software products appeared on the market in the 1970s. With the advent of the first personal computers (the Apple II, the IBM PC and many others) the shrinkwrapped software market become the most familiar to users, being still today a significant part of the overall IT landscape. It is important however to notice that such market represents only around 25% of the total value of the software market, with the remaining composed of custom software developed under contract and software developed in-house [OECD 02].

FLOSS[1] as a licensing model

Building on a tradition laid by academic institutions like MIT, Richard Stallman founded in 1983 the Free Software Foundation (FSF) to find a way to preserve the freedom of users to study, understand and modify software, in direct link with the hacker culture of openness and sharing of information. The objective of the FSF was to create a complete reimplementation of the Unix operating system, at that time an important refrence for most large companies and research centers. With this purpose Stallman and many others created a complete development and execution environment, for which in the late 1980s the kernel (the underlying core of an operating system) was the only missing component. This gap was filled soon, in 1991, by two different teams: the effort lead by Linus Torvalds developed the Linux kernel, while William and Lynne Jolitz wrote a series in the Dr. Dobbs Journal on how to port BSD Unix to i386-based PCs, creating the basis for a complete, free operating system for modern personal computers [DB 00].

The Free Software Foundation places a strict emphasis on the underlying “four freedoms”:

* The freedom to run the program, for any purpose (freedom 0)
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this
* The freedom to redistribute copies so you can help your neighbor (freedom 2)
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

For this reason, the FSF created a set of “free software licenses”, and among them the GPL (general public license) and LGPL (lesser general public license) that are the most widely used, both in terms of number of projects and in number of lines of code covered.

Unfortunately, in many situations the term “free software” is frequently interpreted as “gratis”, that is, with no price; a fact that forced the FSF to introduce the slogan “free as in free speech, not as in free beer”. The free software environment moved at a significant pace, up to the development of complete user environments such as GNOME and KDE, and to the design in 1998 of the “open source” trademark, created to present a more pragmatic alternative to the somewhat “political” orientations of the FSF. The Open Source definition is based on a similar set of conditions:

“Free Redistribution 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.

Source Code 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.

Derived Works 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.

Integrity of The Author’s Source Code 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.

No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons.

No Discrimination Against Fields of Endeavor 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.

Distribution of License 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.

License Must Not Be Specific to a Product 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.

License Must Not Restrict Other Software 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.

License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface.”

Both groups maintain a list of licenses that comply with the terms of the Free Software Definition, or the list of conditions for using the term “open source”.In fact, there are more than 50 licenses identified as “open source” or “free software”, but fortunately they can be classified in a very simple way as [Sun 06, UU 05]:

* “provide credit”: use, modification, redistribution are allowed, but credit to the original author is due, if redistributed. Examples: BSD license, Apache License v2.
* “provide fixes”: use, modification, redistribution are allowed, but source code for any changes must be provided to the original author, if redistributed. Examples: Mozilla-style licenses (Mozilla Public License).
* “provide all”: use, modification, redistribution are allowed, but source code of any derived product must be provided, if redistributed. Example: GPL.

When code from different projects is mixed and redistributed, the issue of license compatibility becomes important. An extremely detailed matrix with licensing compatibility with regards of GPL (including the recently released GPLv3 license) is available at [Fed 07]; in any case, whenever a product is released or distributed, it is advisable to ask advice of an attorney with expertise in FLOSS licenses and intellectual property (a similar advice applies to proprietary software releases).

FLOSS as a development model

While FLOSS as a definition covers exclusively the licensing regime, by extension the “openness” of the code introduced the possibility of sharing development efforts among different groups, in a way similar to those of the early user groups of the sixties. In this sense, Eric Raymond introduced in his seminal paper “The cathedral and the bazaar” the concept of shared development, contrasting this “bazaar” style where every developer is free to choose on what part of the code to work, in contrast to the “cathedral” or formalized development approach that is rigid and structured [Raym 00].

While the concept took hold quickly, the reality is that collaboratively developed projects tend to be executed in a continuum between cathedral and bazaar; for example, for most projects there is a formal structure (with many sub-projects, more open to external contributions) while other are strictly formal (for example, projects that use FLOSS code in a certified environment, such as avionics or safety-critical systems). The important point raised by Raymond is the fact that both coding and ancillary activities like bug fixing and production of documentation can be shared in a large community, creating in a sense “virtual software houses” that in a voluntaristic way provide effort and resources; this helps also in the leverage of a large community of expert users, that can contribute back in a significant way, as shown in [VH 03, VH 05].

When such collaboration takes place, it may be not only in the form of source code, as for example is commented in [Jul 06]: “In the year 2000, fifty outside contributors to Open Cascade provided various kinds of assistance: transferring software to other systems (IRIX 64 bits, Alpha OSF), correcting defects (memory leaks…) and translating the tutorial into Spanish, etc. Currently, there are seventy active contributors and the objective is to reach one hundred. These outside contributions are significant. Open Cascade estimates that they represent about 20 % of the value of the software.”

A similar view has been presented in [Sei 06], where one of the leaders of the KDE project[2] presented the elements that collectively contribute to KDE:

* Artwork
* Documentation
* Human-computer interaction
* Marketing
* Quality Assurance
* Software Development
* Translation

If overall software suitability to the task is considered, it is clear that non-code contributions are as important as source code.For example translations, documentation and overall quality are vital for the software to be adopted by end-users worldwide.

Another example comes from [Mue 07], where the number of participants within individual Openoffice.org subprojects were counted:


As it can be inferred from the area graph, there are roughly as much non-code contributors than those working on product development and related projects (that are directly related to source code).

This form of collaboration can happen even between competing companies. For example, news about potential security vulnerabilities are commonly shared among different competing Linux vendors. As an example, Mark Cox of RedHat (a widely used distribution of Linux) analyzed the results of two years of incident responses, and found that the largest share of information was coming from the other peer FLOSS distributors [Cox 07].

In more recent years, companies started the adoption of this collaborative model to develop software and services, sometimes supplementing the volunteer communities and sometimes starting new projects and providing substantial resources to its continuation. This later stage (the commercialization stage) is more focused on the sustainability of business models adopted by said companies, and is the main focus of chapter 6.

1. ↑ Richard Stallman and the FSF introduced the term “free software”. Later, the Open Source Initiative proposed “open source software”, allegedly to avoid the linguistic uncertainty associated with the English term “free”, specifically used by the Free Software Foundation to preserve the underlying concept of freedom. The “libre software” term was introduced for the same reason, and used specially in Europe. The term “FLOSS” was introduced by Rishab Gosh in the context of EU-funded project “Free/Libre and Open source software: survey and study” started in 2002 as a catch-all term for free software and open source as described in this section. In this report we will use mainly the term FLOSS.
2. ↑ KDE is a complete user desktop environment, created originally as a libre alternative of the Unix CDE environment, and later evolved to encompass libraries, end-user software and training material.


Posted in FOSS. Tags: . 6 Comments »

Modern Foundations of Computer Networks

Modern Foundations of Computer Networks

Fall 2008


Computer networks are everywhere these days. A recent field in the intersection of Electrical Engineering and Computer Science, Computer Networking is now a scholarly subject substantiated on a body of fundamental results which shed light on the operation of current networks and guide the design of next-generation ones. This course provides a gentle introduction to some of the modern foundations of Computer Networking, including: basic network algorithms; an algebraic theory of optimal paths; an algebraic theory of routing; network calculus; and network coding. These topics have an algorithmic and abstract algebra backdrop which confers unity to the course. Their beauty and relevance is illustrated with a number of applications concerning the Internet, notwithstanding their applicability reaching far beyond Computer Networking.


This is an entry-level graduate course on the fundamentals of Computer Networking. It has as prerequisites undergraduate-level courses on linear algebra, calculus, algorithms and data structures, and computer networks. Previous knowledge of abstract algebra is not assumed.

Instructor: João Luís Sobrinho

Classes: Thursday from 17:00 to 18:30, and Friday from 9:30 to 11:00, room LT5, 4th floor of the North Tower.

Grading: Each student is expected to write a 8-pages essay and give a 40-minutes presentation on a topic related to the course. Grading will be based on homeworks (50%), and the written essay and the oral presentation (50%).


· Basic algorithms on directed graphs

o Digraphs, paths, cycles, and arborescences

o Breadth-first search and depth first-search algorithms

· Weighted shortest paths

o Fixed-point equations: existence and uniqueness

o Bellman-Ford-Moore, Dijkstra’s, and Floyd-Warshall algorithms

o Going from a sequential to a distributed algorithm: distance-vector routing protocols and variants, and link-state routing protocols

o Applications to intra-domain routing in the Internet

· Networks and dioids

o Four less-than-classical network problems: a flow problem; 2th-shortest-paths; widest paths; enumeration of paths

o Orders and algebras: monoids, semi-rings, and dioids

o Fixed-point equations on dioids: existence and least solution

o Generalized Jacobi, Gauss-Seidel, Dijkstra’s, and Gauss-Jordan algorithms

o Tons of applications

· Networks and routing algebras

o Fixed-point equations: existence and uniqueness

o A sequential algorithm to solve the fixed-point equations

o Generalized distance-vector and link-state routing protocols

o Applications to quality-of-service intra-domain routing and to policy-based inter-domain routing in the Internet

· Network flows

o Flows and residual networks

o Max-flow Min-cut theorem

o Ford-Fulkerson method and Edmonds-Karp algorithm

· Connectivity

o Directed multigraphs

o Disjoint paths and trees: Menger’s and Edmonds’ theorems

o Algorithms for disjoint paths and trees

o Applications to video broadcast in the Internet

· Network calculus

o Min-plus calculus: integrals and convolutions

o Arrival curves and token buckets; service curves and schedulers

o Applications to integrated and differentiated services in the Internet

· Network coding

o More on algebras: rings, fields, finite fields, and vector spaces

o Linear network codes: existence and construction

o Applications to video multicast in the Internet

Lectures Schedule:


Notes will be prepared by the instructor during the course. The following additional references are helpful.

· Basic algorithms

o Thomas Cormen, Charles Leiserson, Ronald Rivest, and Clifford Stein. Introduction to algorithms, 2th edition. The MIT Press 2001 [Part VI, Chapter 22]

· Weighted shortest-paths

o Thomas Cormen, Charles Leiserson, Ronald Rivest, and Clifford Stein. Introduction to algorithms, 2th edition. The MIT Press 2001 [Part VI, Chapter 24 and 25]

o Leslie Lamport, “An assertional correctness proof of a distributed algorithm,” Science of Computer Programming, 2(3) December 1992

o Jeffrey Jaffe and Franklin Moss, “A responsive distributed routing algorithm for computer networks,” IEEE Transactions on Communications, 30(7) July 1982

· Networks and dioids

o Michel Gondran and Michel Minoux. Graphes, dioides et semi-anneaux, Editions Tec & Doc, Paris, France, 2001 [Chapters 1 and 4] (There is a 2008 English translation)

· Networks and routing algebras

o João L. Sobrinho, “An algebraic theory of dynamic network routing,” IEEE/ACM Transactions on Networking, 13(5), October 2005

· Network flows

o Thomas Cormen, Charles Leiserson, Ronald Rivest, and Clifford Stein. Introduction to algorithms, 2th edition. The MIT Press 2001 [Part VI, Chapter 26]

· Connectivity

o Jorgen Bang-Jensen and Gregory Gutin. Digraphs: theory, algorithms and applications. Springer, 2002 [Section 7.3 and 9.5]

· Network calculus

o Cheng-Shang Chang. Performance guarantees in communication networks. Springer 2000 [Chapters 1 and 2]

o Jean-Yves Le Boudec and Patrick Thiran, “A short tutorial on Network Calculus I: fundamental bounds,” in Proc. ISCAS 2000

· Network coding

o Christina Fragouli, Jean-Yves Le Boudec, and Jorg Widmar, “Network coding: an instant primer,” ACM SIGCOMM Computer Communication Review, 36(1), January 2006

o Sidharth Jaggi, Peter Sanders, Philip A. Chou, Kamal Jain, Ludo Tolhuizen, “Polynomial-time algorithms for multicast network code construction,” IEEE Transactions on Information Theory, 51(6), June 2005


Ten myths about free/libre open source software

In 1999, Tim O’Reilly, founder of a popular open source-oriented publishing house, gave a keynote speech to an audience of Fortune 500 executives called “ten myths about open source software”. As those myths are still perceived today, as shown by recent reports [CIO 07, ED 05, Forr 07], and are still perceived as a barrier towards FLOSS adoption, we will try to provide here a SME-oriented and pragmatic answer to all of them.


* 1 Myth #1: It’s a Linux-vs-Windows thing.
* 2 Myth #2: FLOSS is not reliable or supported.
* 3 Myth #3: Big companies don’t use FLOSS.
* 4 Myth #4: FLOSS is hostile to intellectual property.
* 5 Myth #5: FLOSS is all about licenses.
* 6 Myth #6: If I give away my software to the FLOSS community, thousands of developers will suddenly start working for me for nothing.
* 7 Myth #7: FLOSS only matters to programmers, since most users never look under the hood anyway.
* 8 Myth #8: There is no money to be made on FLOSS.
* 9 Myth #9: The FLOSS movement isn’t sustainable, since people will stop developing free software once they see others making lots of money from their efforts.
* 10 Myth #10: FLOSS is playing catch-up to Microsoft and the commercial world.

Myth #1: It’s a Linux-vs-Windows thing.

Most recent debates about FLOSS were focused on an all-or-nothing perception. For example, when introducing FLOSS in a company, a full software migration is often considered as necessary. This, and the fact that there is limited knowledge of FLOSS projects except for a few very widely known ones (like Linux, Apache, OpenOffice.org), created the perception that most FLOSS is designed and targeted as a direct competitor of Microsoft products. The reality is that there is an enormous number of active projects in practically any IT field, including business-specific (such as ERP systems), being most of them cross-platform, capable of running Microsoft Windows, Apple’s OSX (which is itself based on more than 300 open source projects) or Linux. As can be found in Appendix 1, there are more than 18,000 FLOSS projects that are stable and mature for adoption by SMEs.

Myth #2: FLOSS is not reliable or supported.

This myth is based on a common perception that FLOSS is exclusively developed by volunteers in a non-coordinated or unstructured way. There are many errors in this view:

* the volunteer perception: while volunteer contributions are a significant part (and sometimes the majority) of large scale projects, around 50% of developers have received a financial compensation for working on FLOSS projects, either directly paid to improve the projects or paid to support them. This has been shown in recent studies [Gosh 05, Gosh 06] and can be inferred directly by the fact that in the software industry at large, 68% of software products include directly FLOSS-derived code.

* paid programmers are better: even for the percentage of contributions that are coming from volunteers, it is commonly perceived that those should be of inferior quality, as there is no financial incentive to produce quality software. This ignores the fact that intrinsic incentives are in many cases more effective than monetary compensation [Gosh 06], and the fact that sometimes users are interested in improving the software that they are using [VH 03]. This second effect, called user-driven innovation, has been shown in past research to be a significant force. For example, around 25% of innovations in fields like software security, printed circuit boards CAD systems and library software were designed and introduced by advanced users. The same effect provides a fundamental design feedback, as large project collects both good and bad experiences in using the software (for example, the Ubuntu Linux “Testimonial and Experiences page[1]” that allows for a form of user-driven “steering” of the project and the identification of trouble points.

* there is no support: most large scale project are related to companies that provide paid-for support, in a way similar to that of proprietary software companies. The availability of source code and the modification rights gives also the additional advantage that support can be obtained even for projects that are no longer active, in stark difference with proprietary software where no code escrow clause was included in the acquisition contract.

* FLOSS is inherently unreliable: many believe that FLOSS, as developed in an open and unstructured way, is inherently of lesser quality when compared to proprietary software. The reality is that most FLOSS projects are organized in a semi-strict structure, and only very modular projects are inherently “bazaar-style”, allowing for large scale internal decoupling. In any case, the impact of FLOSS-style development has been assessed in several research papers, and for example in [Suc 04] we found: “The hypothesis that open-source software fosters more creativity is supported by our analysis. The growing rate, or the number of functions added, was greater in the open-source projects than in the closed-source projects. This indicates that the open-source approach may be able to provide more features over time than by using the closed-source approach. Practitioners interested in capturing market share by providing additional features should look to the open-source methodology as a method to achieve this. In terms of defects, our analysis finds that the changing rate or the functions modified as a percentage of the total functions is higher in open-source projects than in closed- source projects. This supports the hypothesis that defects may be found and fixed more quickly in open-source projects than in closed-source projects and may be an added benefit for using the open-source development model.” This is consistent with results from vendors of software defect identification tools, such as Reasoning, that found that while the bug density ratio in initial project releases is on par with proprietary developments, it improves rapidly and for some projects defect densities are significantly lower than that of the average proprietary code [Reas 06a, Reas 06b][2]. This was confirmed by other studies like the reports from Coverity.

The fact that FLOSS is overall reliable can be also inferred by surveys like [CIO 07], where 79% of respondents answered positively to the question “My company’s experience with open source products other than Linux has been so good we plan to expand their use”.

In this sense, it should be no surprise that several FLOSS projects have received safety certifications, or have been used in medical devices, control systems and avionics. For example, the VISTA system is a large scale electronic health care system, developed by the US Department of Defense for its own veteran hospitals, and now used in more than 1000 hospitals and clinics in the US alone, along with many other installations across many countries. Other examples include the use of Linux in Siemens Magnetic Resonance Imaging systems used in diagnostics, the use of the open source ADACORE environment in in-flight avionics, the FIPS-140 certification of two of the most important encryption toolkits (OpenSSL and NSS), and many more.

If we take as an example the IEC 61508 safety integrity levels [Daf 06-2]:

the UK Health and Safety Executive, in a study from 2002 [HSE 02] found that Linux was robust enough, and that it could be certified up to SIL3 with limited effort. This would make it amenable for use in air traffic control displays, railways control systems and process plant control.
Myth #3: Big companies don’t use FLOSS.

The easiest myth to dispel: apart from the large IT companies that are actively promoting open source software like IBM, HP, Sun, Oracle, and others, about 86% of Fortune 1000 companies are deploying or testing FLOSS, and a similar percentage is found in Europe [Aug 04]. Of those, 35% or more are deploying more than 20% of their systems as FLOSS, and 11% of companies report more than 20% of their applications as FLOSS. While usage in server-centric and IT infrastructure is more common, around 26% of large companies are mentioning the use of Linux on the desktop, and a much larger percentage are reporting the use of some other FLOSS packages, such as OpenOffice.org and Firefox on Windows desktops. A curious fact also evident from other surveys is that many companies and public administrations are not aware of their internal use of FLOSS, sometimes for simple ignorance of the licensing terms and sometimes because the product is offered or embedded in what seems like a traditional proprietary offering (for example, many security and networking products, or enterprise products like VMware ESX server, use FLOSS internally).

Myth #4: FLOSS is hostile to intellectual property.

There are several aspects that are referenced to this myth:

* The GPL license is “viral”: the most widely used license does have a specific clause which mandates that when a software product that is derived from GPL software code is redistributed, the entire product must comply with the conditions of the GPL. This has prompted some companies to claim that “the viral aspect of the G.P.L. poses a threat to the intellectual property of any organization making use of it”[3]. The reality is that for most scenarios, this clause simply provides a way to prevent appropriation of code without giving back contributions or credit, which is one of the reasons why many developers prefer the GPL to other licenses. Simple use of FLOSS in itself does not require any change to the license of internally developed software, and most companies routinely run proprietary software on top of GPL-licensed code like the Linux kernel.

* The free software community steals the intellectual property of other companies: this is mainly the byproduct of a legal case, in which the SCO company claimed in 2003 that IBM improperly included copyrighted material in the Linux kernel. In the original claim, it was mentioned that IBM “put SCO’s confidential and proprietary information into Linux, the free operating system”[4] and that several millions of lines of code of the Linux kernel were stolen from SCO’s Unix source code. Now, four years later, the judges have thrown out most of the claims, leaving less than 300 lines of code (mostly standard interface code) still under evaluation, out of more than 6 million lines of code of a modern Linux kernel. Recently Microsoft issued similar statements, with Microsoft’s CEO Steve Ballmer[5] claiming that “that product (Linux) uses our patented intellectual property”, and later numbering how many patents Linux and other FLOSS products were infringing Microsoft’s intellectual property. The reality is that structured FLOSS projects do have strict policies for accepting patches and external contributions. As an example, the Eclipse project has a strict due diligence process, that covers external contributions, code rights assignments, code review and license compatibility. The Eclipse Foundation also uses automated tools to check for code copying, keyword scanning for words with legal significance and a controlled release review prior to updating the code [Cam 06]. Similar processes are in place in other FLOSS projects [Rig 06].

Myth #5: FLOSS is all about licenses.

While in a strict sense a FLOSS project is defined by its license, most aspects of open source are really related to the openness and collaborative aspects of the development, as described in chapter 1.

Myth #6: If I give away my software to the FLOSS community, thousands of developers will suddenly start working for me for nothing.

There is no guarantee that simply “dumping” source code on the web will make a FLOSS project appear, and there have been several examples of such behavior to be even negative (because the community may see this as “garbage dumping”). The reality is that for some collaboration to happen, there must be first of all a good communication, interaction strategy and effort in place. In addition, investing in community creation and dissemination efforts increase the probability of a bidirectional effort sharing. It is important to mention that surveys like OSSWatch or [CIO 07] found a significant proportion of companies and public administrations (between 14% and 25%) contribute back patches or participate actively in FLOSS communities.

Myth #7: FLOSS only matters to programmers, since most users never look under the hood anyway.

The fact that most users are not interested in the source code does not imply that having the source code available in itself is useless. Several positive aspects can be identified:

* The availability of the code allows end users to eventually pay someone for modifications or continuing maintenance even when the original FLOSS project disappears or becomes inactive.

* “Under the hood” there is not only code, but many non-code artifacts that are vital to a project, like translations, documentation, examples, etc. Many users can contribute in such aspects even if they are not programmers.

* For some projects, having the code available allows for a significant cost reduction or increases dramatically the flexibility of the offered solution. For example, in a project called MuleSource (a sophisticated middleware system) it was found that 64% of users perform at least one source code modification.

Myth #8: There is no money to be made on FLOSS.

Even many researchers have proclaimed in a way or the other that the freely available nature of the code precludes any potential commercial exploitation. For example, in [Hahn 02]: “The GPL effectively prevents profit-making firms from using any of the code since all derivative products must also be distributed under the GPL license”. This of course collides with the economic results obtained by companies like HP (that in 2003 reported more than 2.5B$ in Linux-related revenues), or the 400M$ revenues reported in 2006 by RedHat. In [Gosh 06] it is evaluated that:

* Defined broadly, FLOSS-related services could reach a 32% share of all IT services by 2010, and the FLOSS-related share of the economy could reach 4% of European GDP by 2010.

* FLOSS directly supports the 29% share of software that is developed in-house in the EU (43% in the U.S.).

* FLOSS potentially saves industry over 36% in software R&D investment that can result in increased profits or be more usefully spent in further innovation.

* The notional value of Europe’s investment in FLOSS software today is Euro 22 billion (36 billion in the US) representing 20.5% of total software investment (20% in the US).

Similar measures are predicted by independent consulting groups like Gartner: in [Gar 06] it is predicted that two years from now, around 25% of the total software market will be FLOSS-based (either through external providers, or by internal developments).


Another relevant aspect is that since most companies adopting FLOSS report significant cost savings, these can be directly transferred to external professional services or incorporated as additional profit margin. For example, in [Inf 07]:


In a survey of 800 IT managers, InfoWorld found that of all the FLOSS adopters, those collecting the most significant benefits are those that deploy more open source products, with 24% of the “large users” (more than 100 products) reporting savings of more than 60%. It is also interesting to notice that only a very small percentage (<9%) reports that there are no savings or that costs have increased compared to proprietary software.
Myth #9: The FLOSS movement isn’t sustainable, since people will stop developing free software once they see others making lots of money from their efforts.

This is connected to the view of myth #2, the idea that FLOSS is developed by volunteers, and that companies can only profit in a parasitic way from the code that is developed for free. As discussed in that part, the reality is that in most projects companies and volunteers participate in a collaborative and non-competitive way; also, the most widely used license (the GPL) forced companies to reciprocate their efforts by making dissemination of the source code mandatory whenever there is dissemination of code derived from GPL projects.

Myth #10: FLOSS is playing catch-up to Microsoft and the commercial world.

The concept of software innovation is really rooted in two different aspects: technical innovation and field innovation. While technical innovation is mostly invisible to the user, “field innovation” (for example a new kind of application) is highly visible. Maybe because of this it is widespread the perception that most FLOSS software is sort of a copy of some other (desktop) oriented proprietary application.

The reality, on the contrary, is that most proprietary software is non-innovative in this aspect. While very few examples of new concepts (like Dan Bricklin’s spreadsheet idea) can be found, most applications are matched to the tasks that people performs daily, and as such there is a strong disincentive to innovate. There are very few studies comparing FLOSS with proprietary software in a replicable and objective way, and one of those is [Kli 05]:


The end result is that from a field innovation point of view, around 12% of the projects in the sample are considered innovative, a percentage that is comparable to that of the proprietary software market. As for the technical innovativeness, the already cited [Suc 04] found that “The hypothesis that open-source software fosters more creativity is supported by our analysis. … This indicates that the open-source approach may be able to provide more features over time than by using the closed-source approach.”

Other research, like [ARC 07], found “the enterprises using office packages alternative to Microsoft are more innovative (average index 0.2) than those using Microsoft only (average index 0.15). The correlation between innovation and the use of free/open-source software at the corporate level is confirmed also in international comparative studies conducted by researchers from Harvard University”[6].

1. ↑ http://ubuntuforums.org/forumdisplay.php?f=103
2. ↑ “At a defect density of 0.09 defects per KLOC, the version of MySQL we inspected has a defect density that is about six times lower than the average of comparable proprietary projects.”
3. ↑ As mentioned by Craig Mundie, Microsoft’s vice president, in a talk at New York University’s Stern school of Business in 2001. Other representatives of Microsoft like Bill Gates said that “[the GPL] it makes it impossible for a commercial company to use any of that work or build on any of that work”, and Steve Ballmer “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches … if you use any open-source software, you have to make the rest of your software open source” (interview at Chicago Sun-Times, 2001).
4. ↑ The transcript of the initial complaint and a full list of case documents (along with significant analysis) can be found in the GrokLaw site, at http://www.groklaw.net
5. ↑ http://blogs.zdnet.com/hardware/?p=154


Posted in FOSS. Tags: , . 6 Comments »

The Invention of the Ethernet – Local Area Networks – Robert Metcalfe

By Mary Bellis

I came to work one day at MIT and the computer had been stolen, so I called DEC to break the news to them that this $30,000 computer that they’d lent me was gone. They thought this was the greatest thing that ever happened, because it turns out that I had in my possession the first computer small enough to be stolen! – Robert Metcalfe on the trials and tribulations of inventing the Ethernet.

The ethernet is a system for connecting computers within a building using hardware running from machine to machine. It differs from the Internet, which connects remotely located computers by telephone line, software protocol and some hardware. Ethernet uses some software (borrowed from Internet Protocol), but the connecting hardware was the basis of the patent (#4,063,220) involving newly designed chips and wiring. The patent* describes ethernet as a “multipoint data communication system with collision detection”.

Robert Metcalfe was a member of the research staff for Xerox, at their Palo Alto Research Center (PARC) where some of the first personal computers were being made. Metcalfe was asked to build a networking system for PARC’s computers. Xerox’s motivation for the computer network was that they were also building the world’s first laser printer and wanted all of the PARC’s computers to be able to print with this printer.

Robert Metcalfe had two challenges: the network had to be fast enough to drive the very fast new laser printer; and it had to connect hundreds of computers within the same building. Never before had hundreds of computers been in the same building — at that time no one had more than one, two or maybe three computers in operation on any one premise.

The press has often stated that ethernet was invented on May 22, 1973, when Robert Metcalfe wrote a memo to his bosses stating the possibilities of ethernet’s potential, but Metcalfe claims ethernet was actually invented very gradually over a period of several years. In 1976, Robert Metcalfe and David Boggs (Metcalfe’s assistant) published a paper titled, “Ethernet: Distributed Packet-Switching For Local Computer Networks.”

Robert Metcalfe left Xerox in 1979 to promote the use of personal computers and local area networks (LANs). He successfully convinced Digital Equipment, Intel, and Xerox Corporations to work together to promote ethernet as a standard. Now an international computer industry standard, ethernet is the most widely installed LAN protocol.

* U.S. Patent #4,063,220 – Ethernet Patent
Multipoint data communication system with collision detection.

Thông báo ôn tập môn Mạng máy tính

Buổi ôn tập môn Mạng máy tính:
– Lớp MMT1 : 3/12
– Lớp MMT2 : 1/12
Nội dung :
– Công bố điểm giữa kỳ, giải quyết các thắc mắc, hướng dẫn ôn tập
– Trình bày báo cáo (nếu có)
Yêu cầu :
– Mang các slide bài 12,13,14 (photo)
– Chuẩn bị trước các câu hỏi
– Nộp các bài tập lớn (bản in, file .doc, chương trình)

Posted in Courses. Tags: , . 1 Comment »