Less may be more: Copyleft, -right and the case law on APIs on both sides of the Atlantic

Abstract: Like any relatively young areas of law, copyright on software is surrounded by some legal uncertainty. Even moreso in the context of copyleft open source licenses, since these licenses in some respects aim for goals that are the opposite of 'regular' software copyright law. This article provides an analysis of the inheritance effect of the GPL-family of copyleft software licenses (the GPL, LGPL and the AGPL) from a mostly copyright perspective as well as an analysis of the extent to which the SAS/WPL case affects this family of copyleft software licenses. In this article the extent to which the GPL and AGPL inheritance clauses have a wider effect than those of the LGPL is questioned, while both the SAS/WPL jurisprudence and the US Google case seem to affirm the LGPL's “dynamic linking” criterium.

A paper by Walter van Holst published in IFOSS Law Review.

Table of content

• Introduction
• Legal framework as provided by the GPL family
• Roles of the GPL family of licenses
• Bare licenses based on copyright law
• Analysis and application to libraries
• Linking mechanisms
• Transformation and derivation in case law
• Conclusion

READ THE PAPER

_________________________

License and attribution
This paper was published in the International Free and Open Source Software Law Review, Volume 5, Issue 1 (MARCH 2013). It originally appeared online at http://www.ifosslr.org.
This article should be cited as follows:
Holst, Walter van  (2013) 'Less may be more: Copyleft, -right and the case law on APIs on both sides of the Atlantic', International Free and Open Source Software Law Review, 5(1), pp 5 – 14
DOI: 10.5033/ifosslr.v5i1.72
Copyright © 2013 Walter van Holst.
This article is licensed under a Creative Commons NL (Netherlands) 2.0 licence, no derivative works, attribution, CC-BY-ND available at http://creativecommons.org/licenses/by-nd/2.0/uk/.
As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.

Open source alternatives for small businesses

Is it safe to use? What alternatives do I have? Is it easy to install?
These were some of the questions asked by Amandeep, a New Delhi based owner of a small scale clothing company, when I pitched to him a few open source solutions that could make his day-to-day operations more efficient. For someone without any IT background (but a sharp business sense), these were brilliant and relevant questions. The answers to these questions won't just help Amandeep, but if shared broadly may help reduce the apprehension of a significant number of small scale business owners, especially in India. My interactions have shown that a lot of these businesses are looking to grow, enhance their productivity, and most importantly, save costs.

Approximately 7,500 miles away from Amandeep in New Delhi lives Nabeel Hussain. Nabeel, a graduate of Conrad Business, Entrepreneurship and Technology Centre, is a new product development and digital marketing specialist actively engaged in Waterloo, one of the top entrepreneurial ecosystems in the world. As an entrepreneur, he is always faced with the challenge of managing limited resources while building traction. He has a plethora of technology solutions at his disposal, and the technical know-how to utilize these solutions. Additionally, he has a robust support system to advise and guide him to the best available solution that fits his needs. For Nabeel, open source solutions provide an inexpensive alternative for crafting early stage prototypes for his ideas and validating them with customers. From using WordPress and its library of plugins, to venturing into OpenShift Origin and Joomla, he has the knowledge to make use of top notch technology to reduce risk, manager resources, and build traction for his venture.
These two different scenarios indicate a categorical gap in the knowledge of entrepreneurs when it comes to adopting open source solutions. Although there is some geographic gap between the entrepreneurs in the developed and the developing world, as well as a gap that spawns from business exposure/experience, the problem is wider than that. There is a difference in productivity and efficiency between entrepreneurs who utilize open source solutions and those who do not. The situation becomes clear when we look at those small scale business owners who are technology pros versus those who are not.
A significant number of businesses, in India in particular and in the developing world in general, are of a mom-and-pop business nature. Based on my recent interactions with these small scale business owners, I see widespread misconceptions pertaining to open source software. The questions that Amandeep from New Delhi asked me are critical in nature. In order for small scale businesses to adopt open source solutions, it is vital to address these misconceptions.

Is open source software really safe?

The question arises from the basic process that is followed to write code using open source way. If any hacker can read your code, then why can't they use the knowledge to their personal benefit? Most of those sorts of malicious attempts fail because there are a lot of committed people looking over the source code, finding problems, and fixing them. More eyes tame bugs quickly. And security by obscurity is no security at all. What strikes me at this point of time are the words of security expert Bruce Schneier, "Public security is always more secure than proprietary security…For us, open source isn't just a business model; it's smart engineering practice."
Developing code in an open source fashion is an expression of a technique. Software, in our world, should be treated as a service which can be customized based on the specific needs of a user, rather than merely as a product.
I know a lot of people involved at different levels of open source projects. All of them are driven by their commitment to reach technical and professional excellence, and to add to the existing body of technology knowledge. The entire ecosystem of open source is built on that commitment. The Linux operating system, for example, with its proven track record of stability and security, forms the backbone of complex infrastructures and data centers world over. The same benefits that help Linux and other open source tools succeed at the enterprise level can be reaped by small businesses, too.
A couple of months back, I read Thomas Friedman's The World is Flat. An otherwise helpful and insightful book, the author seems to host a thought process that open source is contrary to the developers' right to make a profit. A lot of people who think that way do not see the forest for the trees. They see free software, they see Linux, but they miss the multi-billion dollar ecosystem that surrounds open source. Its true that Brian Behlendorf, the person who orchestrated Apache web server, did not make a dime off it, but the immense value that this server has added to the economy and the legions of small to medium size businesses that use this infrastructure is an important contribution. Free software developed by a community is not tantamount to insecurity.

Are there quality alternatives available?

Gone are the days when open source was produced only by the engineers, for the engineers. From word processing to calendar applications to servers and to setting up telephone communication networks, small businesses can benefit hugely from open source solutions. Let us take the example of word processing, an activity that almost all small businesses, irrespective of their field, carry out.
Microsoft Word is the premium software in the area but it is cluttered with features that a lot of small businesses won't ever use. The bloating of Microsoft Word has cost its simplicity. There are easy to use, simple, free, and open source word processors available out their. A few of these that I have been using (and suggesting to small businesses) as an alternative to Microsoft Word are:

1. Apache Open Office: This software primarily consists of six tools for managing office tasks, namely: Writer as a word processor, Calc as a spreadsheet tool, Impress for multimedia presentations, Draw for diagrams and 3D applications, Base as a database tool, and Math for creating mathematical equations.
2. AbiWord: Developed in 1998 with the help of gtkmm, this open source word processor includes both simple word processing features to sophisticated features like multiple views, page columns, and grammar checking.
3. LibreOffice:This is my favorite and always at the top of my recommendation list for anyone looking for a free and efficient word processing suite. Although the features are similiar to those of ApacheOpen Office, LibreOffice is better when it comes to community support.

There are dozens of other excellent alternative solutions to proprietary software and thousands of open source projects that can serve small businesses. It can sometimes be difficult to select the software which best matches specific needs, but there are plenty of people globally willing to help you make those decisions and help take small businesses down the path to an open and productive future.
_______________________

Originally posted 17 Feb 2014 by Aseem Sharma under a CC by-sa license; see source.

Call to all open source communities: Emphasize inclusion

As a woman in open source, I have found that the values of community, open development, and flat organizational structure appeal equally to both men and women. The ability of local organizers to freely define what type of culture they are building allows them to adapt in order to appeal to the surrounding culture, while striving to improve access. 
The gender balance in the field of design is the opposite of the FOSS community, because the majority of visual artists are female. In art, gender is discussed openly as an aspect of the theory used to explain visual communication. For example, part of the typical peer-review process is critique, the goal of which is to contextualize visual communication by discussing the culture, gender, identity, economics, and psychological factors which influenced the artwork, so the artist can understand how they personally fit into the community in which they practice. I began as an outsider to both technology and the FOSS community, so it was both interesting and frustrating to realize that much of the communication and organization of FOSS communities was framed without acknowledgement to the diversity of communication styles and the backgrounds of potential community members.
In 2011, I was accepted to the OPW to work on high contrast icon themes for the GNOME desktop. This started my deep dive into the fascinating world of Linux. Having access to an open code base, sharing my work in the open, and receiving constant feedback from the community was overwhelming at first. The learning curve was steep, but the excitement I felt about having access to open knowledge, the support of a community dedicated to sharing knowledge freely, and to pushing the boundaries of what we did kept me coming back for more even on the most frustrating days.
My OPW internship brought me into the FOSS community. It also taught me to talk freely about my experiences as a woman in the computer science field, and sometimes that means knocking on the same doors over and over until you are let in. Sometimes it means acknowledging that communication styles needs to shift in order to emphasize inclusion. Other times it means speaking up about what your community values and how to allocate resources to benefit all participants equally. OPW was the first door to open for me, and my involvement showed me that persistence, hard work, and enthusiasm can bring success no matter who you are or where you start from.
As time went on I became involved in coding for GNOME. In 2012, I started to contribute to GNOME’s Documents application, which was the first application to be developed in the new GNOME 3 style. Because the style is still in its early stages, the themes and widgets are being prototyped in the applications before they are integrated into GTK+ (the widget library) and the standard desktop themes. Last summer I wrote my own GNOME application: a sound recorder for the desktop. I started by planning my code to fulfill the requirements of a series of mockups by a community member. I went on to code the application as a Google Summer of Code (GSoC) project.
During the initial development phase I worked with Reda Lazri (the original designer), Sebastian Dröge (a GStreamer core maintainer who mentored me), Hylke Bons, and Garrett LeSage (both of whom are community members and design for GNOME). GSoC allowed me to immerse myself in GNOME’s developer community and learn about the code base from core contributors.
When a fellow GNOME contributor, Jim Campbell, suggested that we start a group to focus on GNOME and GNU/Linux, I saw it as a way to give back to my community and work to increase diversity. The FOSS community in Chicago is small, and for the first year I was the only woman who attended our events. From the beginning we emphasized that our group was open to anyone who was interested in participating by adopting a code of conduct. As time went on our community began to grow and started to be more representative of the larger community here in the city. Engaging women has happened slowly but without any special intervention on our part.
We invite members to bring their projects to hackfests and share their knowledge by giving talks. People have come to work on GTK+ bindings for the Go programming language, documentation for Gedit, the fundraising campaign for MediaGoblin, and the website for the Open Science Framework, among other things. Talks have ranged from a recent SaltStack tutorial, which our members participated in using their own four-server demo environments running on server space donated by Rackspace—to talks on Wayland, Emacs, and personal data security. All of the projects and presentations center around the use of open source technologies. Our role as organizers is to encourage participation and free exchange of ideas and resources among participants.
Being a woman in computer science is both an exciting and challenging experience. To me it means being exposed to emerging technologies, solving new and difficult problems, and working to promote Free and Open Source Software (FOSS) in my local community.
I think that outreach can be successfully addressed using the same template as other questions in open source: by recognizing diversity as a key element of success, by facilitating transparency and equal access to knowledge, and by letting the community organize itself around a shared vision. Having women who are visibly engaged in and promoting involvement in the community seems to be one way to send a clear message that women can participate and succeed in FOSS.
_______________________

Originally Posted 6 Feb 2014 by Meg Ford here; license CC by-sa.

The European Union Public Licence (EUPL)

Abstract: The EUPL is an OSI-approved free or open source software licence, copyrighted by the European Union. It was drafted by the Commission as from 2005 and launched in January 2007 as a share alike (or copyleft) style licence. At the end of 2012, about 500 projects have been licensed under the EUPL by European institutions, Member States and the private sector. A new version 1.2 of the EUPL has been drafted in 2013 and the European Commission reported that it will be published before the end of the year 2013. What makes the EUPL unique is its multilingual working value, specific warranties, references to the Court of Justice of the European Union and its provisions related to licence compatibility, making its copyleft “variable” for facilitating interoperability.

A paper by Patrice-Emmanuel Schmitz published in IFOSS Law Review.

Table of content
1. Origin of the EUPL
2. EUPL and Licence Proliferation
3. The EUPL Used as a “Reference”
4. Rights Granted by the EUPL v1.1
5. What Made the EUPL v1.1 Specific?
6. Changes Planned in the EUPL v1.2
7 How is the EUPL's Variable Copyleft Implemented?
   a) The Normal Copyleft Reuse Under the EUPL
   b) Exception to the “Normal Copyleft” (Reuse in Other Copyleft Works)
   c) Exception to the Exception
Conclusion
References

READ THE ARTICLE

_________________________________

Licence and Attribution
This paper was published in the International Free and Open Source Software Law Review, Volume 5, Issue 2 (December 2013). It originally appeared online at http://www.ifosslr.org.
This article should be cited as follows:
Schmitz, Patrice-Emmanuel (2013) 'The European Union Public Licence (EUPL)', International Free and Open Source Software Law Review, 5(2), pp 121 – 136
DOI: 10.5033/ifosslr.v5i2.91 
Copyright © 2013 Patrice-Emmanuel Schmitz.
This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND available at
http://creativecommons.org/licenses/by-nd/2.0/uk/ 
As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.

The Women of OpenStack talk outreach, education, and mentoring

Image credits: The U.S. National Archives

In the open source world, a women-only event seems counter-intuitive. Yet I am finding reasons for such events the more I attend them.
At the OpenStack Summit, a twice-a-year event where OpenStack contributors get together to plan the next release, the Women of OpenStack group has set up events where we invite the women first. Men aren't excluded, but our hope is to get more OpenStack women together. I can hardly capture the value of getting together with other women in OpenStack at the Summit, but here goes. 

Why do we get together apart from the rest of the conference?

We have a couple of themes for our meetups. We talk about outreach to more women, especially in education as early as elementary school and definitely through college. Also, we meet our GNOME Outreach Program for Women interns in person for the first time! That’s a huge reason for these in-person gatherings: getting to know each other personally. But we also want to find concrete ways to make our meetings meaningful, so we talk about a few tracks for our goals: outreach, education, career planning, and mentoring. We come up with ideas for our goals, and we keep discussing them at each Summit. It’s like a design summit session for women of OpenStack. And, in between Summits we stay in touch via LinkedIn.

We look for speaking opportunities for women in the cloud. We have held workshops geared towards outreach to women, introducing lots of technical women to OpenStack. For example, this past year Iccha Sethi, Jessica Lucci, and I ran a workshop at the Grace Hopper Open Source Day, and Anita Kuno, Lyz Krumbach Joseph, and Ryan Lane ran a CodeChix workshop. We generally forge the bonds that hold together a common minority by talking about schools, parenting, gin as a vegetable, shoes, traveling wardrobes, and how does this OpenStack Neutron plug-in work, anyway?

We get to know each other. I sat down across from a woman who mentioned she works at IBM in Austin. I said, "Oh, I work at Rackspace in Austin." She said, "Where do you live?" I said, "Oh, in northwest Austin." She said, "Wait, where do you live!?" As it turns out, we both have fourth graders who go to the same neighborhood school! It’s a small world with tight connections in Austin for high-tech women. It seems impossible with the numbers game we’d know each other’s schools, streets, neighborhoods, and so on, but in reality we’re rare enough birds of a feather that it is natural for us to get together and get know each other well. We can talk about families, parenting, all in a technology setting, without any concerns for: "Is it okay to talk about this here?" We are glad to share. There are so few of us that we need to be diligent about our outreach and staying connected.

This year we had a question at the OpenStack Summit related to under representation of minorities in a panel with the OpenStack Technical Committee. I couldn't quite gather my thoughts to talk about it on the panel, but I blogged about it later because it's vitally important as we grow as a community. We need to be hyper-vigilant about impostor syndrome, uncovered by researchers who found that many high-achieving females believe they are not intelligent and that others over-evaluate them. Believe me, I have to fake it to make it daily. This is part of the reality of questioning whether you belong in open source, whether you have leadership potential, and whether you have the technical chops.

Our culture as a community may reward the most confident, but in reality as we grow as a community it’s important to understand that some cultures do not view confidence in the same way, and some people do not naturally exude confidence. We’re also looking at English-as-a-second-language (ESL) increasing in prevalence in our community, and a former Outreach Program for Women intern, Anita Kuno, recently edited our Technical Committee charter to be gender-neutral. These efforts matter. These gatherings give us a chance to question the normal in a safe arena. We are also able to track numbers of women attending OpenStack Summits. We won't know if we're improving if we don't track it, and we can't improve if we don't start somewhere.

The best way I can think to describe why it matters for women to network with other women is there's an establishment of trust, that this community is also your community. We don't tend to walk into a room full of all-women in open source events. More often you walk into a room, try to figure out just where to sit, try to find someone else you recognize and can talk to, and see if you know any regulars from other areas. With small networks of women in open source, my vision is that we'll walk into the room and just know we belong. Then we won't ask questions like: "How can we get more women in open source?" We'll ask: "How can we get more people in open source?"
_______________________

Originally Posted 3 Feb 2014 by Anne Gentle here.

The free software definition (What is free software?)

The Free Software Definition

The free software definition presents the criteria for whether a particular software program qualifies as free software. From time to time we revise this definition, to clarify it or to resolve questions about subtle issues. See the History section below for a list of changes that affect the definition of free software.

“Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.
We campaign for these freedoms because everyone deserves them. With these freedoms, the users (both individually and collectively) control the program and what it does for them. When users don't control the program, we call it a “nonfree” or “proprietary” program. The nonfree program controls the users, and the developer controls the program; this makes the program an instrument of unjust power.
A program is free software if the program's users have the four essential freedoms:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (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 distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

A program is free software if it gives users adequately all of these freedoms. Otherwise, it is nonfree. While we can distinguish various nonfree distribution schemes in terms of how far they fall short of being free, we consider them all equally unethical.
The rest of this page clarifies certain points about what makes specific freedoms adequate or not.
Freedom to distribute (freedoms 2 and 3) means you are free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere. Being free to do these things means (among other things) that you do not have to ask or pay for permission to do so.
You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.
The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.
The freedom to redistribute copies must include binary or executable forms of the program, as well as source code, for both modified and unmodified versions. (Distributing programs in runnable form is necessary for conveniently installable free operating systems.) It is OK if there is no way to produce a binary or executable form for a certain program (since some languages don't support that feature), but you must have the freedom to redistribute such forms should you find or develop a way to make them.
In order for freedoms 1 and 3 (the freedom to make changes and the freedom to publish the changed versions) to be meaningful, you must have access to the source code of the program. Therefore, accessibility of source code is a necessary condition for free software. Obfuscated “source code” is not real source code and does not count as source code.
Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours — a practice known as “tivoization” or “lockdown”, or (in its practitioners' perverse terminology) as “secure boot” — freedom 1 becomes a theoretical fiction rather than a practical freedom. This is not sufficient. In other words, these binaries are not free software even if the source code they are compiled from is free.
One important way to modify a program is by merging in available free subroutines and modules. If the program's license says that you cannot merge in a suitably licensed existing module — for instance, if it requires you to be the copyright holder of any code you add — then the license is too restrictive to qualify as free.
Freedom 3 includes the freedom to release your modified versions as free software. A free license may also permit other ways of releasing them; in other words, it does not have to be a copyleft license. However, a license that requires modified versions to be nonfree does not qualify as a free license.
In order for these freedoms to be real, they must be permanent and irrevocable as long as you do nothing wrong; if the developer of the software has the power to revoke the license, or retroactively add restrictions to its terms, without your doing anything wrong to give cause, the software is not free.
However, certain kinds of rules about the manner of distributing free software are acceptable, when they don't conflict with the central freedoms. For example, copyleft (very simply stated) is the rule that when redistributing the program, you cannot add restrictions to deny other people the central freedoms. This rule does not conflict with the central freedoms; rather it protects them.
“Free software” does not mean “noncommercial”. A free program must be available for commercial use, commercial development, and commercial distribution. Commercial development of free software is no longer unusual; such free commercial software is very important. You may have paid money to get copies of free software, or you may have obtained copies at no charge. But regardless of how you got your copies, you always have the freedom to copy and change the software, even to sell copies.
Whether a change constitutes an improvement is a subjective matter. If your right to modify a program is limited, in substance, to changes that someone else considers an improvement, that program is not free.
However, rules about how to package a modified version are acceptable, if they don't substantively limit your freedom to release modified versions, or your freedom to make and use modified versions privately. Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable; you're already making other changes to the program, so you won't have trouble making a few more.
Rules that “if you make your version available in this way, you must make it available in that way also” can be acceptable too, on the same condition. An example of such an acceptable rule is one saying that if you have distributed a modified version and a previous developer asks for a copy of it, you must send one. (Note that such a rule still leaves you the choice of whether to distribute your version at all.) Rules that require release of source code to the users for versions that you put into public use are also acceptable.
A special issue arises when a license requires changing the name by which the program will be invoked from other programs. That effectively hampers you from releasing your changed version so that it can replace the original when invoked by those other programs. This sort of requirement is acceptable only if there's a suitable aliasing facility that allows you to specify the original program's name as an alias for the modified version.
In the GNU project, we use copyleft to protect these freedoms legally for everyone. But noncopylefted free software also exists. We believe there are important reasons why it is better to use copyleft, but if your program is noncopylefted free software, it is still basically ethical. (See Categories of Free Software for a description of how “free software,” “copylefted software” and other categories of software relate to each other.)
Sometimes government export control regulations and trade sanctions can constrain your freedom to distribute copies of programs internationally. Software developers do not have the power to eliminate or override these restrictions, but what they can and must do is refuse to impose them as conditions of use of the program. In this way, the restrictions will not affect activities and people outside the jurisdictions of these governments. Thus, free software licenses must not require obedience to any nontrivial export regulations as a condition of exercising any of the essential freedoms.
Merely mentioning the existence of export regulations, without making them a condition of the license itself, is acceptable since it does not restrict users. If an export regulation is actually trivial for free software, then requiring it as a condition is not an actual problem; however, it is a potential problem, since a later change in export law could make the requirement nontrivial and thus render the software nonfree.
Most free software licenses are based on copyright, and there are limits on what kinds of requirements can be imposed through copyright. If a copyright-based license respects freedom in the ways described above, it is unlikely to have some other sort of problem that we never anticipated (though this does happen occasionally). However, some free software licenses are based on contracts, and contracts can impose a much larger range of possible restrictions. That means there are many possible ways such a license could be unacceptably restrictive and nonfree.
We can't possibly list all the ways that might happen. If a contract-based license restricts the user in an unusual way that copyright-based licenses cannot, and which isn't mentioned here as legitimate, we will have to think about it, and we will probably conclude it is nonfree.
When talking about free software, it is best to avoid using terms like “give away” or “for free,” because those terms imply that the issue is about price, not freedom. Some common terms such as “piracy” embody opinions we hope you won't endorse. See Confusing Words and Phrases that are Worth Avoiding for a discussion of these terms. We also have a list of proper translations of “free software” into various languages.
Finally, note that criteria such as those stated in this free software definition require careful thought for their interpretation. To decide whether a specific software license qualifies as a free software license, we judge it based on these criteria to determine whether it fits their spirit as well as the precise words. If a license includes unconscionable restrictions, we reject it, even if we did not anticipate the issue in these criteria. Sometimes a license requirement raises an issue that calls for extensive thought, including discussions with a lawyer, before we can decide if the requirement is acceptable. When we reach a conclusion about a new issue, we often update these criteria to make it easier to see why certain licenses do or don't qualify.
If you are interested in whether a specific license qualifies as a free software license, see our list of licenses. If the license you are concerned with is not listed there, you can ask us about it by sending us email at <licensing@gnu.org>.
If you are contemplating writing a new license, please contact the Free Software Foundation first by writing to that address. The proliferation of different free software licenses means increased work for users in understanding the licenses; we may be able to help you find an existing free software license that meets your needs.
If that isn't possible, if you really need a new license, with our help you can ensure that the license really is a free software license and avoid various practical problems.

 

Beyond Software

Software manuals must be free, for the same reasons that software must be free, and because the manuals are in effect part of the software.
The same arguments also make sense for other kinds of works of practical use — that is to say, works that embody useful knowledge, such as educational works and reference works. Wikipedia is the best-known example.
Any kind of work can be free, and the definition of free software has been extended to a definition of free cultural works applicable to any kind of works.

Open Source?

Another group has started using the term “open source” to mean something close (but not identical) to “free software”. We prefer the term “free software” because, once you have heard that it refers to freedom rather than price, it calls to mind freedom. The word “open” never refers to freedom.

History

From time to time we revise this Free Software Definition. Here is the list of substantive changes, along with links to show exactly what was changed.

• Version 1.122: An export control requirement is a real problem if the requirement is nontrivial; otherwise it is only a potential problem.
• Version 1.118: Clarification: the issue is limits on your right to modify, not on what modifications you have made. And modifications are not limited to “improvements”
• Version 1.111: Clarify 1.77 by saying that only retroactive restrictions are unacceptable. The copyright holders can always grant additional permission for use of the work by releasing the work in another way in parallel.
• Version 1.105: Reflect, in the brief statement of freedom 1, the point (already stated in version 1.80) that it includes really using your modified version for your computing.
• Version 1.92: Clarify that obfuscated code does not qualify as source code.
• Version 1.90: Clarify that freedom 3 means the right to distribute copies of your own modified or improved version, not a right to participate in someone else's development project.
• Version 1.89: Freedom 3 includes the right to release modified versions as free software.
• Version 1.80: Freedom 1 must be practical, not just theoretical; i.e., no tivoization.
• Version 1.77: Clarify that all retroactive changes to the license are unacceptable, even if it's not described as a complete replacement.
• Version 1.74: Four clarifications of points not explicit enough, or stated in some places but not reflected everywhere:
  • "Improvements" does not mean the license can substantively limit what kinds of modified versions you can release. Freedom 3 includes distributing modified versions, not just changes.
  • The right to merge in existing modules refers to those that are suitably licensed.
  • Explicitly state the conclusion of the point about export controls.
  • Imposing a license change constitutes revoking the old license.
• Version 1.57: Add "Beyond Software" section.
• Version 1.46: Clarify whose purpose is significant in the freedom to run the program for any purpose.
• Version 1.41: Clarify wording about contract-based licenses.
• Version 1.40: Explain that a free license must allow to you use other available free software to create your modifications.
• Version 1.39: Note that it is acceptable for a license to require you to provide source for versions of the software you put into public use.
• Version 1.31: Note that it is acceptable for a license to require you to identify yourself as the author of modifications. Other minor clarifications throughout the text.
• Version 1.23: Address potential problems related to contract-based licenses.
• Version 1.16: Explain why distribution of binaries is important.
• Version 1.11: Note that a free license may require you to send a copy of versions you distribute to the author.

There are gaps in the version numbers shown above because there are other changes in this page that do not affect the definition or its interpretations. For instance, the list does not include changes in asides, formatting, spelling, punctuation, or other parts of the page. You can review the complete list of changes to the page through the cvsweb interface.

__________________________

Copyright © 1996-2002, 2004-2007, 2009, 2010, 2012, 2013 Free Software Foundation, Inc. This page is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License. Taken from www.gnu.org/philosophy/free-sw.en.html.

The Open Source Definition

Introduction

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

 

1. 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.

 

2. 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.

 

3. 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.

 

4. 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.

 

5. No Discrimination Against Persons or Groups

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

 

6. 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.

 

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

 

8. 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.

 

9. 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.

 

10. License Must Be Technology-Neutral

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

_________________________

original source: http://opensource.org/osd; license: CC by

The quest for strategies to monetize free software

I’ve discussed recently with a friend of mine photographer, illustrator and animator about the status of GIMP, Inkscape and Blender. The good news is that professionals increasingly know about these free software tools, which is already a great step forward compared to the past years. Pierpaolo acknowledged how powerful all of them are but also noticed how different they are all from other similar software in the same field. It occurred to me that while other desktop tools like Open/LibreOffice have ways to raise money to finance the development of new features, improve the user experience and interface, etc Gimp and Inkscape are primarily developed by volunteers (Blender’s development is financed by the non profit Blender Foundation through grants and donations). This whole led me to think again about how hard it is for free software projects to invest time and energy in refactoring the GUI when there are so many cooler things to add to the core functions of the software (think of the eternal complaint about quadricromy support in GIMP). Would these be interested in improving their UI if they had more money available or if they had actual ‘customers’ instead of users?

When I was thinking about all this I learned that Sourceforge released a new program to fund development of free/open source software with a revenue sharing program called DevShare. Reading the press release, DevShare offers free software developers the option to bundle extra software with their downloads and share revenues with SourceForge. When a user downloads FileZilla for example, she’s offered the option to install also another piece of software with FileZilla. SourceForge is not the first site to offer bundled downloads but it does it with a better approach, avoiding traps. They looked at best practice policies to avoid confusing end-users with misleading installation flows and promises to provide clear documentation and procedures to uninstall undesired applications.

The revenue sharing with the developers is what is most interesting to me: developers who voluntarily decided to join similar programs are often required to spend time integrating their applications with third party installers, and have limited control over what and how that’s offered to their end-users. SourceForge’s program on the other hand seems to be very open and transparent towards the developers. I’ll be following the evolution of the program, hoping that free lance open source developers find motivation.



FileZilla installer (left) and
FileZilla bundle HotspotShield (right)

_________________________________________

An article by Stefano Maffulli; originally published on 16 July 2013 under a CC by license; taken from here.

What is Copyleft?

Copyleft is a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well.
The simplest way to make a program free software is to put it in the public domain, uncopyrighted. This allows people to share the program and their improvements, if they are so minded. But it also allows uncooperative people to convert the program into proprietary software. They can make changes, many or few, and distribute the result as a proprietary product. People who receive the program in that modified form do not have the freedom that the original author gave them; the middleman has stripped it away.
In the GNU project, our aim is to give all users the freedom to redistribute and change GNU software. If middlemen could strip off the freedom, we might have many users, but those users would not have freedom. So instead of putting GNU software in the public domain, we “copyleft” it. Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. Copyleft guarantees that every user has freedom.
Copyleft also provides an incentive for other programmers to add to free software. Important free programs such as the GNU C++ compiler exist only because of this.
Copyleft also helps programmers who want to contribute improvements to free software get permission to do so. These programmers often work for companies or universities that would do almost anything to get more money. A programmer may want to contribute her changes to the community, but her employer may want to turn the changes into a proprietary software product.
When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away.
To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program's code, or any program derived from it, but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.
Proprietary software developers use copyright to take away the users' freedom; we use copyright to guarantee their freedom. That's why we reverse the name, changing “copyright” into “copyleft.”
Copyleft is a way of using of the copyright on the program. It doesn't mean abandoning the copyright; in fact, doing so would make copyleft impossible. The “left” in “copyleft” is not a reference to the verb “to leave”—only to the direction which is the inverse of “right”.
Copyleft is a general concept, and you can't use a general concept directly; you can only use a specific implementation of the concept. In the GNU Project, the specific distribution terms that we use for most software are contained in the GNU General Public License (available in HTML, text, and Texinfo format). The GNU General Public License is often called the GNU GPL for short. There is also a Frequently Asked Questions page about the GNU GPL. You can also read about why the FSF gets copyright assignments from contributors.
An alternate form of copyleft, the GNU Affero General Public License (AGPL) (available in HTML, text, and Texinfo format), is designed for programs that are likely to be used on servers. It ensures that modified versions used to implement services available to the public are released as source code to the public.
A compromise form of copyleft, the GNU Lesser General Public License (LGPL) (available in HTML, text, and Texinfo format), applies to a few (but not all) GNU libraries. To learn more about properly using the LGPL, please read the article Why you shouldn't use the Lesser GPL for your next library.
The GNU Free Documentation License (FDL) (available in HTML, text and Texinfo) is a form of copyleft intended for use on a manual, textbook or other document to assure everyone the effective freedom to copy and redistribute it, with or without modifications, either commercially or noncommercially.
The appropriate license is included in many manuals and in each GNU source code distribution.
All these licenses are designed so that you can easily apply them to your own works, assuming you are the copyright holder. You don't have to modify the license to do this, just include a copy of the license in the work, and add notices in the source files that refer properly to the license.
Using the same distribution terms for many different programs makes it easy to copy code between various different programs. When they all have the same distribution terms, there is no problem. The Lesser GPL, version 2, includes a provision that lets you alter the distribution terms to the ordinary GPL, so that you can copy code into another program covered by the GPL. Version 3 of the Lesser GPL is built as an exception added to GPL version 3, making the compatibility automatic.
If you would like to copyleft your program with the GNU GPL or the GNU LGPL, please see the license instructions page for advice. Please note that you must use the entire text of the license you choose. Each is an integral whole, and partial copies are not permitted.
If you would like to copyleft your manual with the GNU FDL, please see the instructions at the end of the FDL text, and the GFDL instructions page. Again, partial copies are not permitted.
It is a legal mistake to use a backwards C in a circle instead of a copyright symbol. Copyleft is based legally on copyright, so the work should have a copyright notice. A copyright notice requires either the copyright symbol (a C in a circle) or the word “Copyright”.
A backwards C in a circle has no special legal significance, so it doesn't make a copyright notice. It may be amusing in book covers, posters, and such, but be careful how you represent it in a web page!
__________________________

Original source: www.gnu.org/copyleft/copyleft.en.html
Copyright © 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
This page is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.
 

The Italian government publishes the official guidelines for adopting FOSS in the public sector

We already know that the Italian legislative system is often more complicated than others. In 2012 an innovative legislative action finally stated that the FOSS options should take precedence over the proprietary ones in the public sector.
But a new and very clear law is not alwasy enough to make a revolution really effective.
So the Italian government decided to designate a technical commission composed of some experts of computer science and computer law, and the spokespersons of IT companies (such as Microsoft, Oracle, IBM) and the main FOSS communities active in Italy (suche as Debian, LibreOffice).
Now this commission closed their work and we finally have the guidelines. They are published as Circolare 63/2013 (Guidelines for the comparative evaluation as defined in Article 68 of the Italian Digital Public Administration Act).

If you lose the previous episodes, read these articles:

- another blogpost of mine (originally published on August 2012 on my blog): Free and open source software takes precedence. By law! 
- a peer-reviewed article (by Simone Aliprandi and Carlo Piana) published in March 2013 on International Free and Open Source Software Law Review] 
-  another article on the same topic by Guglielmo Troiano: Free software and comparative evaluation in the Italian Public Administration
- press release by Free Software Foundation Europe:
Italy puts Free Software first in public sector

for Italian readers:
- Se non basta la legge, ecco le linee guida
- Il software libero ha la priorità. Per legge

Free and open source software takes precedence. By law!

[this post - orinally posted on my blog on August 29, 2012 - has induced two further items:
- an updating blogpost posted on December 13, 2012
- a peer-reviewed article (co-author: Carlo Piana) published in March 2013 on International Free and Open Source Software Law Review]

With the recent changes made ​​to Article 68 of the Codice dell'amministrazione digitale* by Law 134/2012 (approved by the Italian Parliament on August 7, 2012), every Italian public administration is formally obliged to choose open source software wherever possible.

Here is an English translation of the main part of the article:

Only when the comparative analysis of technical and economic aspects demonstrates the impossibility to adopt open source solutions or any other software solution already developed (at a lower price) within the public administration system, the acquisition of proprietary software products is allowed.

Before this modification has become effective (August 12, 2012), Italian public administrations could select between 5 options:

a) develop a solution internally
b) reuse a solution developed internally
c) obtain a proprietary license of use
d) obtain an open source license
e) a combination of the above

Now the rule is that option c) above is not allowed anymore by default: “free or open source software” is an overriding option.

Some issues are still not so clear, for instance time and manner for the implementation of this new principle (not a little point!). However it is a very nice goal and a good start for a truly open e-government system.

* it is the most important Italian act about e-government

A few links:
- the entire text of Art. 68 (comparing old and new version)

- an article by me about this topic [only in Italian]

The Farfalla Project: an open and cloud solution for accessibility

By this post, I'd like to introduce you the Farfalla Project: an innovative solution for web-accessibility, entirely based on a cloud and interoperable techonology. It is an independent project, launched by an Italian researcher named Andrea Mangiatordi (Bicocca University of Milan) and released as free and open source software under a GNU Affero General Public License.
Here some basic information from the official website:

Farfalla is a web application for enhancing accessibility of any website. It is meant to be easy to configure and to use.
We want to provide users with a lightweight and flexible solution, which can be always available in the cloud, for free.
Because we think that accessing information on the Web is a right for all.
You can try it right now: you only have to click on the bar on the upper-right part of this page to select a profile. Every profile allows accessing different kinds of resources, from text magnification to an onscreen keyboard. We will add more tools in the future, so if you can’t find anything useful, you could try contacting us and explaining your needs. We would be glad to help!
You can participate to Farfalla project and substain it in various ways. It largely depends on what are your needs and skills.
If you are a user and you are willing to give and get help, you can use our bugtracker. Through it, you can tell us what doesn’t work and what you want to be looked into at first.
If you are a developer and you are interested in supporting this project, you can subscribe to the developers mailing list.

The project won two important international awards: the Judges Award for the Microsoft Web Accessibility Challenge 2011 during W4A2011 and the first prize at Lifted by the Cloud: Visions of Cloud Enhanced Accessibility (a challenge by the USA Federal Communications Commission).

If you are webmaster, you can improve the accessibility of your website by adding this solution as a new feature. Think about it.

Free software and comparative evaluation in the Italian Public Administration

The on-going debate regarding the use of free and open source software in the Italian Public Administration (PA) seems to be coming to a satisfactory conclusion. Italian public administrations are now obliged to give priority to free and open source software. This preference, however, cannot be given without a "comparative assessment". One of the tasks of the Agency is indeed to establish procedures and criteria that will help to justify their choices in the acquisition of computer programs. In this light, last January the Agency for Digital Italy (Agenzia per l'Italia Digitale) convened a workgroup for all interested stakeholders, focusing on implementing the new software comparative assessment requirements pursuant to art. 68 of the Digital Administration Code (Legislative decree no. 82/2005). Their work was completed last month. Now, the Agency will launch a public consultation and will adopt a final text for the guidelines. These guidelines will provide the Italian PA with all the operational tools for the acquisition of software.
Public administrations in Italy and elsewhere in the European Union are expected to provide efficient services to businesses and citizens, to share software solutions, to discuss best practices, and to generally share their experiences. These are the goals of the Programme on Interoperability Solutions for European Public Administrations (ISA), a programme established by the European Commission.
That said, every public body has the same freedom that any non-public body has in determining whether to acquire, develop, and release software under conditions of free and open source software. This is due to the fact that all public administrations in Italy are obliged to distribute to any other public administration all software which has been developed by or for them, in source code and without any charges (called the Reuse Rule). This fits perfectly in an all-free software workflow, where distribution under the Reuse Rule is not restricted to the Italian public administrations, but is public, to everybody.
The purpose of the Italian PA, of course, is to serve the community and citizens according to the PA’s own goals and skills. For this reason, even when it engages or partners with external instrumental bodies, including those of non-public nature (such as joint ventures or wholly owned companies), the activity of the PA is never directed at making profits or at the acquisition of a market position. The activity may be carried out only to achieve the satisfaction of the public interest, and this is confirmed by the Reuse Rule.
As such, when a public administration makes, designs, develops, and distributes software, the value of the software is not of a commercial nature. The value lies in its use, namely in the ability to make the administrative apparatus and the fulfillment of its own mission more efficient. In other words, for that public administration and the Italian PA as a whole, software is not a product. Rather, it is a service.
For the public administration, it is important that the software works only for the purpose for which it was procured. Beyond that, its value is irrelevant. As such, the return on investment is measured essentially in terms of efficiency. Efficiency which, in turn, must be measured both in immediate terms (saving of resources with an equal output or increased output utilizing the same resources), in long-term savings (lower cost for the update, adaptation, migration to the achievement of obsolescence or the appearance of more efficient systems), and in terms of positive effects to the general or local economy (spillover effects).
The recent changes ensure that public administrations have the right to acquire software under conditions of free and open source software. There is no doubt about this. Both in the case of a pure acquisition of pre-packaged software (generic), as a simple office application (typical examples: an Internet browser, a word processor, an email client or an operating system), but also if the software is being acquired by the Italian PA through ad hoc customization, where there is a substantial economic investment and in which the software is subject to the rules on re-use.
All of these concepts have been upheld by the Italian Constitutional Court in 2010, with Decision no. 122 of March 22. In essence, free and open source software does not refer to a particular technology, brand, or product, but rather expresses a legal feature. What differentiates free and open source software from proprietary software is the different licensing rights of the programs. Decisions about the adoption of one or the other contractual setting belongs to the user, hence, to the Italian Public Administration—which now has a strong preference for the free and open source software way.
_________________

an article by Guglielmo Troiano (website); original source posted 11 Nov 2013 and available on www.opensource.com under a CC by-sa license.

You may also be interested in "Free and open source software in the Italian public administration: fundamental law principles" by Simone Aliprandi and Carlo Piana: read the article.

No predatory pricing in Free Software, the Android case

Google has many legal problems, for some of them I take full credit. Antitrust is one of the most troublesome battlefield for them. Recently, a coalition of competitors under the name of FairSearch has taken on Google on different fronts, including a new antitrust complaint directed to Android. I have written a position paper for FSFE, in my position as General Counsel, urging the Commission to reject it.I feel I owe some explanation, since I have been, and still am, quite vocal against Google lately. On previous occasions, I had to reply to criticism (almost the same parties) that I was double tongued, now I speak out in anticipation. Any contradictions? Not quite. The advantage of speaking out one's heart is that your words can't be used against you. A few years ago already discussed Oracle and Google, defending both in the light of antitrust problems that layed in front of them. For Oracle, I have done my part, or more than that. Now that the same company is within the odd company that forms FairSearch, I find myself in the opposite field.
It's not easy, some very good friends are on the opposite side with a prominent stance. I don't question their motives, which, knowing them, are entirely well-meaning; I would like to affirm that mine and FSFE's are good, and IMHO true. In the same blog post, actually in the very paragraph above, I discussed Google, predicting we would have ended up more or less as we stand now. That was 4 years ago. In the meantime, Google has done the right thing, promoting Android, which passed from being laughed at to being characterized as "dominant" (yes indeed!). Android is Free Software.
The complaint by FairSearch that we contest is (among other grounds), in a nutshell, that because Android is Free Software, it is gratis, the competition in the proprietary field cannot match this level of pricing, therefore market has less alternatives, thus the consumer suffer from this lack of competition. Now, say what? Surely Google has incentives that comes from its main business, but who says that there is a need to preserve the proprietary competitors, to have competition? Can you cite one example of a proprietary vendor of mobile OS? Yes you can, only one, though. Who is in FairSearch? Precisely, the same company. Now, again, read my blog post "Let's Keep Eye on the Ball", wasn't I clairvoyant?
Our points to dismiss the action are, in a nutshell:

• The right price for a Free Software application is zero;
• Any company must be free to release its own software as Free Software. The only condition being that there are no hidden conditions that can be used to make un-free what is released free (this happens by using patents, can't be done using copyright except for future releases):
• Android is as open as it can be. Proprietary bits are mainly connected to drivers that are provided as such by hardware vendors. Suboptimal, but understandable. Even Linux has them;
• Android can be easily forked. This provides an incredible peer pressure. If you look at the proprietary alternatives (why do I even use the plural?) you can only take what they give you;
• Android can be easily personalized. This is the "bloatware" that many vendors feed you to differentiate their offer. But this means that you can make it what you like. Including putting a Facebook interface (bleah!) on it;
• Google cannot control Android through patents. Google is a licensee of OIN. The main complainant is currently doing the exact reverse: attempting to control its competitor and make it unattractive price-wise by imposing very high patent royalties for questionable reasons. In fact, it is making more money with Android than with its own creation, despite having soft merged with one of the leaders of the smartphone sector, Nokia, which had to scrape both its two (!) Free Software operating systems, to the tune of hundred of millions of "marketing contributions".
• Inded, this is de facto a continuation of the global patent war in mobile, where Google is on the right side, and Microsoft, Apple, Nokia and a fleet of trolls on the wrong one. Time to get rid of (software) patents, by the way.

Here is the text of FSFE's press release:

In a recent antitrust submission to the European Commission, a Microsoft-led coalition falsely claimed that the distribution of Free Software free of charge hurts competition. FSFE has written a letter to the European Commission's competition authorities to refute this claim, and make it clear that Free Software is critical for an open, competitive IT market.
In its letter, FSFE urges the Commission to consider the facts properly before accepting these allegations at face value. "Free Software is a boon for humankind. The only thing that it is dangerous to is Microsoft's hopelessly outdated, restrictive business model," says Karsten Gerloff, FSFE's president.
The so-called "FairSearch" coalition is essentially asking the European Commission to favour a restrictive business model over a liberal one. This is exactly the opposite of what competition regulators should do in order to achieve a fair and open market.
"Free Software is not about price, it's about liberty, a guarantee of competition and vendor independence. Asking to cripple Free Software in order to allow proprietary vendors to sell their locked-down systems is just absurd" says Carlo Piana, FSFE's General Counsel. "The most substantial threat to competition in the mobile space today are software patents, and we have repeatedly urged antitrust authorities to address this problem," he adds.
FSFE asks the European Commission to dismiss the "FairSearch" coalition's unfounded claims regarding predatory pricing, and not make them part of whatever steps it decides to take in response to the group's filing.

_______________________

an article by Carlo Piana
(original version published in Carlo Piana's blog on 29/07/2013; license: CC by-sa 3.0)