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.

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

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

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

The open source driver is generally of lower performance because of the lack of information, making it difficult for the programmers to make use of the hardware capabilities. They need to go through a long and difficult process of reverse engineering in order to guess the way the hardware works.

However, the binary drivers have had their own troubles. These problems have practical, moral and legal roots. The first issue is that it has to be maintained separated from the kernel. Any changes to the internal kernel structures can make the driver worthless because it cannot be used in the next kernel release unless the vendor releases a new version. Also, the driver needs some “glue” that has to be created for each specific version of a kernel, even when there are no changes to any internal kernel structures. As the programmers that create the linux kernel drivers are no linux kernel experts and work separated from that community, several problems caused by the incorrect programming of the binary modules have caused more than a headache to this community, to the point that binary modules now “taint” the kernel and are no longer supported by the community (nor by vendors). This is the right thing to do in my opinion: since they cannot fix the binary module, they refuse to look at any problem with kernels running that code. Since the linux architecture is monolithic, a programming error in the driver can cause problems in supposedly unrelated parts (file system corruption for example). Vendors have improved their code and the drivers have improved, but they are nontheless a potential problem.

Second, the moral issue: people wanting to run a completely free operating system on their boxes will not want to be forced to install a binary-only driver in order to make use of their hardware. Not much to discuss there.

Third, the legal issue: the linux kernel is  released under the GPLv2 license. This does not allow the creation of binary-only derivative works. So the question is: are binary-only modules derivative works? The answer seems to be that if the modules are created to be used inside the linux kernel, the make use of the internal structures and thus are effectively derivative works. There are some cases where the answer is less clear, but the general idea is that binary only drivers should not be allowed.
So it comes as good news that at least one vendor (Intel) is announcing full support for open source drivers for their cards. And Intel is the biggest player in that market.

The study not only looks at the usage but also into the reasons behind it, contribution to the OSS community and others. Contrary to the 2003 version, this time the vendor lock-in was said to be an issue among the institutions. The study is definitively worth a look.
One of the results states that 56% of the FE institutions use Moodle. This is consistent with the feeling you get about the issue here in Chile, but I would not be surprised that the usage percentage would be higher here (mostly because of the lack of legacy systems and because licensing costs tend to have a greater impact).

If we assume as a fact that software enforcing DRM will exist in the future, I would rather like to have the code available, and being able to reproduce the compilation exactly as to generate the same binary that has been signed as “trusted”. That way, at least I would have enough information to choose whether I could trust the system enough or not, and this would set abuses on the part of publishers to a minimum. This does not mean that the code should be under the GPL, though. So up to this point there is really no problem.

There are some issues, though, where I’m not so sure about. One phrase in particular states:

“However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.”

I wonder what this implies. Let’s take The GIMP as an example, as it is a useful program, not implementing any DRM schemes and working on the Microsoft Windows platform. Suppose that the GIMP is available under GPLv3 and keeps to be compatible with the MS-Windows platform. What if the next version of MS-Windows implements a DRM scheme in which an application has to be signed before it may access a certain file? This would imply a key generated based on the object code, and thus somebody should make the key available. The question is: who? Apparently, the people distributing (conveying according to the new wording in GPLv3 beta 2) the code. So, as these people have nothing to do with the release of a new MS-Windows version, how on earth are they supposed to distribute the key? Until the existence of that new version, everyting worked smoothly. Now, because of some action of a third party, The GIMP can no longer be redistributed, because the Corresponding Source is impossible to be made available without the collaboration of somebody not related at all (and, probably interested in avoiding the availability of The GIMP)? And by way of the “Freedom or death” clause, if one cannot guarantee every right stated in the GPL, the software cannot be conveyed anymore, to nobody. That just doesn’t make sense to me. Seems to me like the perfect denial-of-service activity in the software development field: create a new feature on a system, and magically it makes some competing software illegal.

If, on the other hand, the case mentioned above resolves to The Gimp being available to anybody, including the ones who use that new DRM implementing MS-Windows version, then the fight against DRM is lost. Because the GIMP will then be subject to the DRM rules and the GPLv3 would have nothing to say against it. In the case of the TiVo, it would not be possible to distribute something which is GPLv3′d and prohibiting the system to run, but only because the system is conveyed as a unit. If the hardware plus the DRM-enabling components (hardware plus software) is distributed by some different party, either we have the case in the previous paragraph, or the GPLv3 would not avoid tivoization. Both outcomes are unacceptable for a free software license that intends to avoid tivoization.

I sympathize with the opponents of DRM technologies. The motivation for them is mainly to extend the established (and in many ways already too wide) rights by adding a technological measure. It doesn’t seem right to use technology to narrow even more the usage you can make of information, and the result is unfair, benefiting the powerful over the weak and/or scattered ones.However, it also doesn’t seem right to impose an ethical view by the usage of software, through the licensing of that software. It would be OK to keep the freedom to use a certain software (avoiding tivoization as Stallman puts it) and thus avoid DRM for that case. But are we certain we aren’t shooting ourselves in the foot?

En fin, es exactamente la solución que hubiese generado cualquier desarrollador de software Open Source. Así que los usuarios de productos privativos no están mejor en ese sentido de lo que están usuarios de software Open Source.

La evolución del software se ha comparado con la teoría de evolución de las especies de Darwin. Básicamente se puede resumir en que las especies (o el software) que mejor se adapta a los cambios es el que prevalecerá por sobre los demás. Veamos qué ha sucedido en esta semana con el cambio anunciado por Apple:

• Adobe ha anunciado que no proveerá binarios para Mac sobre Intel de sus programas en sus versiones actuales: hay que esperar la siguiente versión. Lo mismo ocurre con Macromedia, ahora adquirida por Adobe. Adobe recomienda a los usuarios profesionales no utilizar Mac con Intel mientras ellos no tengan sus versiones nuevas (probablemente durante el año 2007). Los no profesionales que inviertan en memoria extra pueden utilizar Rosetta, pero no podrán tener soporte.
• Microsoft señala que la solución oficial es utilizar Rosetta para poder ejecutar versiones actuales de Office. Internet Explorer está descontinuado de todas maneras, así que ni se menciona.
• OpenOffice.org ha anunciado la disponibilidad de OpenOffice 2.0.1 para mac sobre Intel (en alpha aún), siendo la primera suite que ofrece ser ejecutada sin el castigo de rendimiento que significa utilizar Rosetta.

Creo que está claro quién se adapta mejor y más rápido a los cambios, no? Como consecuencia, también ofrece un mejor servicio a los clientes, quienes, por lo demás, no les pagan licencias de uso.

• Me imagino que un sistema que entrega llaves para decriptar contenido (como un e-mail encriptado) a un programa en base a algún criterio, y si no cumple con ese criterio (por ejemplo, confianza en que no reenviará ese e-mail decriptado a toda la dirección en la agenda) no se le entrega la llave, debiera poder licenciarse bajo GPLv3.
• Un criterio bien puede ser que exista una firma del binario por alguien que certificó el programa, sea el usuario mismo o alguien externo.

Si parece aceptable un esquema así, entonces es aceptable que ese programa esté en un sistema de DRM, y con eso no se logra el objetivo de desincentivar el uso de software libre en sistemas con DRM. Pero supongamos que no se considera aceptable el esquema. En tal caso, tampoco sería aceptable el sistema de manejo de mails encriptados que describí en el artículo anterior. Eso limitaría el campo de acción de cualquier programa derivado de código GPLv3, que es una consecuencia poco afortunada por decir lo menos.

Veamos entonces en qué nos afectaría la redefinición de “código fuente”. El sistema que menciono en el post anterior permite que se instale cualquier programa sin necesidad de una llave. Tampoco se requiere una llave para la ejecución del software. Simplemente, cuando se ejecuta un software no firmado (o el sistema operativo, o cualquier programa en la cadena, no está firmado), no se tiene acceso a ciertas llaves de decripción. Por lo tanto, el objetivo de “evitar el recorte de las libertades por mecanismos de hardware” no se cumple, y tampoco se cumple el “desincentivar sino impedir el uso de software libre en sistemas con DRM”.

Lo que nos resta es entonces que cualquier esquema de DRM no puede contener directamente ningún código que esté licenciado bajo GPLv3. Cualquier fabricante tendría por lo tanto que desarrollar su propio driver y software de manejo de claves para poder utilizar DRM, y sobre eso instala sin problemas software GPL. Vale la pena el costo que se está asumiendo solamente para obligar a algunos fabricantes a desarrollar su propio software? Sobre todo considerando que es muy poco probable que esos fabricantes ocuparan software GPL para eso, me parece que no.

Cuál es el costo del que hablo? Pues que muchos evitarán utilizar esa versión de la GPL por no estar de acuerdo. Y de paso, la GPL se estará “ensuciando” al salirse del marco técnico y definiendo qué cosas no se pueden hacer con el software. Comenzamos con “no se puede utilizar en sistemas DRM”, pero por favor cuál es exactamente la diferencia con “no se puede utilizar en la creación de material pornográfico”, “no se puede utilizar para generar documentos con errores de ortografía” o “no se puede utilizar para publicar ideas que vayan en contra del gobierno chino”?