The consequences are interesting, particularly regarding dual licensing. One of the issues (whether it is a problem or a benefit depends on your point of view) regarding dual licensing is that the original licensor cannot embrace code from an external contributor, even if that code is available under the original license, and distribute it both under the original license and under the other, presumably proprietary, license. This is due to the original work of that external contributor being also covered by copyright, unless that contributor voluntarily and explicitly grants the right to re-license the contribution. This does not happen with patents, since the external contribution does not necessarily include any patented aspects.

As Larry Rosen puts it: “Free for Open Source, everyone else pays”. Who would they pay? Only those who own the patents necessary to use the software.

If, and only if, the granting of a patent implies a real technological achievement, this actually makes sense. Those who contribute something fundamental and far from trivial may gain interesting profits.

However, let us look at the other side of the coin: the potential contributors to the open source project. They will have less incentives to involve themselves in improving an existing software if they do not get the same ability to decide what can be done to the resulting copyrighted work. This is not a problem as long as the overall incentives are enough for them to participate. The question is: is it? In what circumstances will it be enough, when would it not be?

On the other hand, patents are far more limited in time compared to copyrights, which could be a (wrong but useful) way to correct the far exceeding time frames in force for copyright. Any licensing scheme based exclusively on patents would be quite interesting in this regard.

But from a user’s perspective, it is quite unclear which patents are needed to use a certain software, creating some sort of uncertainty. With copyright, you know exactly and can be certain which code is included. No one can assert claims later on because you needed some code to get it to work: you would know because the software would not be working.

While any person or company may state claims on which patents they consider necessary to license a certain software, new claims may arrive later on, on behalf of any party, which might or might not have licensed the software to third parties. Some questions seem necessary to be asked: Is it necessary to get a copy of the software from every licensor who offers the software, just to be sure I have permission from everyone’s potential patents? In any case, this would not impede any third party from making claims on the software for patents not previously mentioned nor licensed under the open source license.

Whatever the case, for this scheme to work it is necessary to first making sure that the initial assumptions are met: patents should only be granted to specific, non trivial (or rather only to really amazing) advances in technologies. This is currently not true, and even if all participants agree on their own to follow the best intentioned guidelines, any third party with a broad, trivial or otherwise dumb patent could make claims that would hurt this line of development.

However, the actual license that implements the ideas of Larry Rosen, the Open Software License (OSLv3), actually imposes the same principle of retribution (copyleft) on the copyrighted source code. Thus, the original author may not take a modified version and distribute it under a proprietary license. What the original author may do is to distribute the modified version under the same license, say OSLv3, and additionally provide permission to use the patents under a different license. This would allow a third party, who receives the copyright permissions from the OSLv3 and additional patent rights, to create a proprietary version of the software, but not to distribute it. I would find it far more interesting to use the patent licensing instead of the copyright licensing, and not in addition as is done in the OSLv3. And I repeat, all of this provided that we first fix the patenting system and after such a fix software patents do make sense, which is far from clear right now.

1. Respecto del cambio del voto del INN como miembro “O” a “P” del Subcomité 34 y conforme a los antecedentes que se tienen:

• Carta de la CCE de fecha 6 de agosto ofreciendo colocar a disposición del Comité y del INN recursos para participar como miembro “P”.
• Carta respuesta del INN enviada con fecha 13 de agosto a la CCE.
• Que las obligaciones que involucra este cambio son:
  • Votar todos los borradores de los documentos o normas en discusión, enviando observaciones (en ingles) a los mismos, cuando se estime necesario.
  • Participar en reuniones internacionales, en la medida de lo posible.
• Seguimiento de las materias que elabora y estudia este Subcomité y las que a futuro se determine como prioritarias.
• Que el INN delega parte de la responsabilidad de la Secretaria Técnica del Comité Espejo JTC1/SC34 a la organización que estime formar el Comité, la cual debe ser representativa de todos los sectores involucrados.
• Que se firmará un convenio de cooperación entre la CCE y el INN, para los efectos de la constitución del Comité Espejo de ISO/IEC JTC1/SC34.

Se acuerda por unanimidad del Comité aceptar lo ofrecido y cambiar la participación en
ISO del INN, para este Subcomité, a miembro “P”.

Sin embargo, por el momento Chile no ha votado en los dos últimos temas relacionados con este comité. Tal como dice Andy Updegrove en su artículo, la mínima muestra de civilidad sería votar “abstención”, dado que es posible abstenerse cuando no ha habido tiempo para revisar los antecedentes. En cambio, cuando no se vota y la cantidad de países que no presentan su voto son un 50% o más, el tema queda automáticamente fuera.
En otras palabras, el único aporte que hemos hecho hasta el momento en el JTC-1 es demorar el proceso de estandarización de iniciativas que tuvieron la mala suerte de llegar justo después de la discusión del OO-XML. Esperemos que esta situación se revierta y sea solamente algo pasajero producto de la organización necesaria para hacer llegar los votos, porque esto no nos deja bien parados.
En todo caso, en el sitio web de la Cámara de Comercio Electrónico de Chile no hay rastros de cumplir con el compromiso que se adoptó en la reunión del 21 de Agosto, y tampoco he recibido invitación alguna a discutir sobre los temas que estamos actualmente bloqueando.

UPDATE (25/10/2007): me tocó estar hoy en la mañana en una reunión con José Antonio Barriga y le toqué el tema, dado que aparece como miembro del directorio de la Cámara de Comercio Electrónico. Por lo que me dice, hay un esfuerzo que se está haciendo para definir exactamente cuál va a ser el funcionamiento, sobre todo después de que el INN planteara justamente esa redefinición. De todas formas, el objetivo de la Cámara es participar activamente en los temas en los que actualmente aparecemos bloqueando la discusión. Pero dados los recursos que existen, la idea es definir las áreas en las cuales hay interés y posibilidades de participar activa y correctamente, y en ellas emitir opiniones, pero de todas formas dar los votos de abstención en los otros temas para no convertirse en un obstáculo a los estándares a nivel mundial. Ojalá eso se pueda resolver lo antes posible, porque también se acerca el deadline para la discusión sobre el OO-XML.

“Este principio económico es el que sustenta la política de neutralidad tecnológica adoptada precisamente por los países más avanzados en tecnologías de la información del mundo.”

Sin embargo, yo no he sido capaz de encontrar un ejemplo en el cual un país avanzado en TI (tampoco algún país poco avanzado) haya efectivamente definido una política de “neutralidad tecnológica”. Puede ser mi poca capacidad o voluntad de buscar, pero tampoco he recibido hints en un artículo sobre neutralidad tecnológica en el cual busco justamente eso: qué es lo que se entiende por ese término. ¿Alguien allá afuera ha visto detalles? Supuestamente este tipo de políticas debieran ser públicas y de fácil acceso.

1. si existe o no pago por parte del estado hacia el oferente
2. si existe o no un costo asociado que deberá solventar el estado
3. si existe o no un beneficio directo para el oferente por haber sido elegido

Es bastante evidente que en el primer punto, si existe un pago (puede ser a partir de cierto monto y no cambiaría mucho la lógica), entonces debe haber un proceso transparente de adjudicación.
En el segundo caso pueden surgir mayores discrepancias. Pero al fin y al cabo, el estado debe velar por los recursos de los ciudadanos y por ende debe fijarse que “aceptar regalos” no se transforme en algo más caro que simplemente decir “no, gracias”.
El tercer punto es quizás un poco menos directo, pero pienso que es igualmente válido. El estado administra diversos recursos ajenos, ya que son de los ciudadanos, y está obligado a actuar en el mejor interés de éstos. Cuando el estado toma la decisión de utilizar un servicio por sobre otros, puede estarle generando un gran valor al oferente de ese servicio. Ese es el caso del acuerdo, y por lo mismo debiera haber un proceso de adjudicación transparente y amplio, en el cual otros actores también puedan postular a obtener el beneficio de obtener ese valor si están dispuestos a prestar el servicio.

… has never been an FSF project, and in fact has never even been a “Free Software” project.

Whether the kernel is or is not a Free Software project is arguable, because it depends on how the developers feel about it or what their intentions are. But what can we say about the set of software grouped under the label of “Free Software” and the set of software gropued under the label of “Open Source Software”? This is far more objective, although not absolutely objective.

We can certainly say that Free Software is software available under a license that fits the Free Software Definition, and that Open Source software is likewise the software available under a license that fits the Open Source Definition. By looking at both definitions, it seems hard to find a license that would fit one definition and not the other, making both sets roughly equivalent.

But let us also compare the list of software licenses that the FSF blesses as Free Software Licenses and compare that list with the software licenses blessed by the OSI as Open Source licenses. The FSF also publishes a list of licenses that are considered to be non-Free Software licenses, whereas the OSI only publishes accepted licenses.
It turns out that there are around 30 licenses (depending on how you count the different versions of the same license) that are accepted by both groups, 32 licenses accepted by the FSF that are not mentioned by the OSI and 22 licenses accepted by the OSI which are not mentioned by the FSF. Then we have some special cases:

• Python: the FSF separates the python license versions into three groups, of which two are compatible and one incompatible with the GPL, though all classified as Free Software
• Perl: the “Perl License” is not evaluated by the OSI. However, since this “disjunctive license” specifies that the licensee may choose either the Artistic License or the GPL, and both are accepted by the OSI, we can deduct that the Perl license should be considered Open Source without a doubt.
• Eiffel Forum v1: does not appear explicitly accepted in the FSF, the document only states that this license is incompatible with the GPL. The conclusion is that it is considered a GPL-incompatible free software license, while version 2 is a GPL-compatible free software license.
• Academic Free License: the FSF accepts versions 1.1 and 2.1, the OSI only mentions acceptance of version 3.0.

And finally we have three licenses that are accepted by the Open Source Initiative and explicitly rejected by the Free Software Foundation: the “Artistic License”, the “Nasa Open Source Agreement” and the “Reciprocal Public License”. However, in both cases the reasons to reject the licenses are not based on failing to fulfill some requirement in the Free Software Definition.

• Artistic License: the FSF does not accept the original artistic license, because of its vagueness, but accepts a modified veresion. However, according to the FSF, “the problems are matters of wording, not substance”.
• Nasa Open Source Agreement: the FSF objects to the requirement that the changes made to the software be the contributor’s “original creation”. However, the Free Software Definition does not require the right to include any third party code. There is no substantial difference between right 3 of the FSD: requiring “the freedom to improve the program, and release your improvements to the public” and the third condition of the OSD stating “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”.
• Reciprocal Public License: there are two criticisms on behalf of the FSF:
  1. the licensee has to notify the licensor when she publishes a modified version of the code. This is not in contradiction with the Free Software Definition, so there is no reason to deny this license. Other much stronger restrictions (such as copyleft or the prohibition of modifying files in the LaTeX license) are accepted by the FSF.
  2. there is a limit on how much anyone can charge for the source code. This does however not limit the amount of money you may charge for the distribution of both the binary and the source code, or for the binary on its own. And it also does not contradict any of the freedoms in the Free Software Definition.

As a conclusion, we can say that the set of software that fits the Free Software Definition and the set of software that fits the Open Source Definition is essentially equivalent. Some exception may exist depending on the interpretation, but there would be no point in assuming that one is the subset of the other.

1. Is it appropriate under U.S. law for the judge to do this?
2. If the spamhaus.org is revoked, how will spamhaus and its users respond?
3. If U.S. judges can revoke domain name registrations, what are the international implications?

As for question 1, I reserve my opinions. The important fact is that, however small, there is a chance that a judge will eventually rule that some domain name has to disappear. So let us just assume that it might happen and continue with the other two. My bet i: there would be a proliferation in the usage of alternative root servers for the Domain Name System (DNS), probably lead by Spamhaus and its users. ICANN would loose its position, which is fragile at best. This would have a high cost for all Internet users (see RFC 2826 for details), as it would make the ‘Net a less reliable place.

You might think of it as a social or political revolution, but in this case, as in many others, there would be no winners, we would all loose to some extent. So, while accepting a loss just to make someone else loose more is no recommendable practice, my intuition says that it’s precisely what would happen in this case. I assume that is what Felten is thinking when he writes:

The result wouldn’t be pretty. As I’ve written before, ICANN is far from perfect but the alternatives could be a lot worse.

Data matters. It shouldn’t be an afterthought. It will outlive your applications.

The differences of FLOSS, Open Standards and Open Services and Open Infrastructure are very interesting, since each of these has its particularities. You would not want to make an open standard free for everyone to change on their own will as many times as they want, since one of the value of standars is that software that implements it can interoperate, so it should be chasing a moving target. On the other hand, anyone should be able to participate in the definition of a standard, but without having the design by committee effect of creating a bloated and far from ideal result by including everyone’s opinion. Bob Sutor has given it a thought, as has Bruce Perens who even has come up with a proposed definition of the open standards concept on which I have commented previously in spanish.

Similar differences apply to both Open Services and Open Infrastructure. On the latter, I personally think that FON is something close to the model of how this concept should be like, specifically when considering the Linus way of using it. The basis here is: I give you mine so you let me use yours. This has been the basis of several widely used iniciatives, ranging from subscription libraries to public goods and infrastructure managed by governments. So why should we not apply these principles to our IT infrastructures, with the benefit that this does not depend on a government making decisions for all of a country’s citizens, and not being bound to any geographic region? This topic have been addressed by Jon Udell and Tim O’Reilly, and we can look at projects like BOINC that take a different path than FON.
To conclude: FLOSS, Open Standards, Open Services and Open Infrastructure do have some relations but also meaningful differences. Their use and development in the future is something to keep an eye (and actively work) on.

Update: there is an interesting discussion about what a specific kind “open service” (they talk about web 2.0 sites that enable people to share content) should look like, triggered by Lessig’s post “The Ethics of Web 2.0” and a nice followup by Tim O’Reilly “Real Sharing vs. Fake Sharing“.

In the absence of regulation, software liability, or some other mechanism to make unpatched software costly for the vendor, “Patch Tuesday” is the best users are likely to get.

[...]

Last week, a hacker developed an application called FairUse4WM that strips the copy protection from Windows Media DRM 10 and 11 files.

[...]

So Microsoft wasted no time; it issued a patch three days after learning about the hack. There’s no month-long wait for copyright holders who rely on Microsoft’s DRM.

You can read more about this article on this blog entry.

One of the things I would like to spread a lot more than it is known is the fact that we have very similar requirements in Chile to the ones being put forward in Massachsetts’ Enterprise Technical Reference Model. The requirements are defined in the supreme decree number 77 and supreme decree number 81 (both available in spanish only), issued in the context of the State Reform and Modernization project.

One of the issues that the State Reform and Modernization is aiming to achieve is the interoperability among governmental entities and with the citizens. This is in itself a complex topic and limiting it to file formats alone would be an unwise oversimplification. But file formats are one of the requirements that are needed and the supreme decrees 77 and 81 address them.

Supreme Decree 77

This decree, signed off on June 3rd 2004, addresses the efficiency of electronic communications among government bodies and between them and citizens. It defines that the government bodies need to specify their file formats and media compatible with their systems, and requires that special readers and applications can be required only when necessary and if those readers and applications are freely available (as in free beer). Also, the file formats have to be compatible, which is further specified in the Supreme Decree 81.

Supreme Decree 81

This decree, also signed off on June 3rd 2004, establishes the minimal technical requirements for governmental bodies handling electronic documents. It referrs to generating, sending, receiving, processing and storing electronic documents. Basically, all electronic documents have to be available in a XML format, following an XML Schema definition. All of the used Schemas have to be publicly available and of free access (as in free beer). The documents have to be self-contained and follow the general rules of being:

• flexible and extensible
• perennial
• interoperable
• having a multiplatform system

Similar requirements are made for repositories, transport of documents and signatures. The requirements start in 2004, 2006 and 2009, depending on the specific government body.Just as Sam writes in this entry on Massachusetts, the Microsoft XML document format does not satisfy the minimal requirements of the Supreme Decree 81. Interestingly, these supreme decrees have not had much public exposure nor criticism. Hopefully this does not mean they will be ignored.