Hombros de Gigantes (Shoulders of Giants)http://www.hardings.cl/blog
Ideas, opinions and references relating IT, FLOSS and Security (among others).Thu, 17 Apr 2008 15:59:33 +0000enhourly1http://wordpress.org/?v=3.0.5Open Source Licensing based on Patents rather than Copyrighthttp://www.hardings.cl/blog/2008/04/17/open-source-licensing-based-on-patents-rather-than-copyright/
http://www.hardings.cl/blog/2008/04/17/open-source-licensing-based-on-patents-rather-than-copyright/#commentsThu, 17 Apr 2008 15:53:47 +0000Jens Hardingshttp://www.hardings.cl/blog/?p=105This is a very interesting proposal by Larry Rosen and Fred Popowich as explained in an interview on linux.com.

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.

]]>http://www.hardings.cl/blog/2007/08/08/%c2%bflicitar-o-no-licitar/feed/5Free Software and Open Source Softwarehttp://www.hardings.cl/blog/2006/12/01/free-software-and-open-source-software/
http://www.hardings.cl/blog/2006/12/01/free-software-and-open-source-software/#commentsFri, 01 Dec 2006 19:14:04 +0000Jens Hardingshttp://www.hardings.cl/blog/2006/12/01/free-software-and-open-source-software/The main difference among the free software and open source software concepts are the motivation of the people identifying with each (that is why I tend to use the term FLOSS when I do not want to be specific about either group. From time to time the question of whether some software is open source or rather free software appears. For example, Linus said that the Linux kernel:

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

]]>http://www.hardings.cl/blog/2006/12/01/free-software-and-open-source-software/feed/0Intellectual Property or Exclusion Rights?http://www.hardings.cl/blog/2006/11/15/intellectual-property-or-exclusion-rights/
http://www.hardings.cl/blog/2006/11/15/intellectual-property-or-exclusion-rights/#commentsWed, 15 Nov 2006 13:58:57 +0000Jens Hardingshttp://www.hardings.cl/blog/2006/11/15/intellectual-property-or-exclusion-rights/I am sitting in a seminar dealing with promotion of access to knowledge, mainly through the use of open licenses that provide much more access then the minimum required by law. It has become more clear than ever yo me that the term “intellectual property” is very misleading.
Several arguments say that the term is basically propaganda, just as the term “piracy” is when applied to infringement to copyright and similar laws. But it should be enough to see how misleading it is to go and change it.
Several critics of the term suggest no alternative name for “Intellectual Property”, argumenting that there is no reason why you would have to group the several unconnected legal constructs (copyrights, patents, trademarks, industrial secrets) that form the group. I disagree. If you want to refer to all those legal constructs in a single name, you should just figure out what they have in common. It turns out all of them have something in common that is also very characteristic: they provide exclusion rights (whether they are justified or not). One single person gets the right to exclude everybody else to do or use something under certain circumstances.
Sure, it does not sound the same when you talk about limitations to intellectual property than about limitations on exclusion rights. In the first case, we would naturally feel compelled to reject any limitation on a protection and instead increase the protection as far as we can, right? if there is something in need of protection, why would we take it away? In the second case, we would feel inclined to limit the exclusion rights, because to exclude everybody from using or doing something requires strong and persuasive arguments. This is also the reason why the principles justifying exclusion right have been largely forgotten at WIPO and they now just try to increase the “protection” offered, no matter what the consequences or whether the initial goals are being met or even come closer.
I will stop using the term “Intellectual Property” wherever possible and replace it with the term “Exclusion Rights” which describes the grouped legal constructs more accurately.
]]>http://www.hardings.cl/blog/2006/11/15/intellectual-property-or-exclusion-rights/feed/1Killing domain names as means to enforce court rulingshttp://www.hardings.cl/blog/2006/10/12/killing-domain-names-as-means-to-enforce-court-rulings/
http://www.hardings.cl/blog/2006/10/12/killing-domain-names-as-means-to-enforce-court-rulings/#commentsThu, 12 Oct 2006 16:11:12 +0000Jens Hardingshttp://www.hardings.cl/blog/2006/10/12/killing-domain-names-as-means-to-enforce-court-rulings/Ed Felten asks interesting questions regarding the Spamhaus.org case. You can read his post for details, but basically, Spamhaus.org has ignored a ruling in which it should pay a plaintiff for damages and publish a declaration stating that it has erroneously published the plaintiff in its “spammers” lists. It might be possible that a court rules that Tucows (as the registrar managing the domain registration) and/or ICANN has to withdraw the name assignment of Spamhaus.org, so that the domain ceases to exist. Felten’s questions are:

Is it appropriate under U.S. law for the judge to do this?

If the spamhaus.org is revoked, how will spamhaus and its users respond?

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.

]]>http://www.hardings.cl/blog/2006/10/12/killing-domain-names-as-means-to-enforce-court-rulings/feed/0FLOSS, Open Standards, Open Services and Open Infrastructurehttp://www.hardings.cl/blog/2006/10/05/floss-open-standards-open-services-and-open-infrastructure/
http://www.hardings.cl/blog/2006/10/05/floss-open-standards-open-services-and-open-infrastructure/#commentsThu, 05 Oct 2006 14:55:02 +0000Jens Hardingshttp://www.hardings.cl/blog/2006/10/05/floss-open-standards-open-services-and-open-infrastructure/OpenBusiness runs a very interesting inteview with Last.FM on their project, website or service, whatever you may call it. This is an interesting iniciative that offers what we could call an “open service”, although we still do not have a sound definition for what an open service should entail, but both Tim O’Reilly and Tim Bray have made interesting points. This is further followed by Anthony Coates by concluding:

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

]]>http://www.hardings.cl/blog/2006/10/05/floss-open-standards-open-services-and-open-infrastructure/feed/0Putting money where the security is: Liabilityhttp://www.hardings.cl/blog/2006/09/07/putting-money-where-the-security-is-liability/
http://www.hardings.cl/blog/2006/09/07/putting-money-where-the-security-is-liability/#commentsThu, 07 Sep 2006 15:48:38 +0000Jens Hardingshttp://www.hardings.cl/blog/2006/09/07/putting-money-where-the-security-is-liability/This article in Wired by Bruce Schneier gives another hint at what some people have been arguing for a long time: Liability for software vendors. It describes how fast an organization reacts when there is money in risk. In spite of the promise to focus on security after several worm breakouts with huge financial consequences for customers, the security has not been one of the most outstanding features for Microsoft lately. In Bruce’s words:

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.

]]>http://www.hardings.cl/blog/2006/09/07/putting-money-where-the-security-is-liability/feed/0Document Formats in Chilehttp://www.hardings.cl/blog/2006/08/20/document-formats-in-chile/
http://www.hardings.cl/blog/2006/08/20/document-formats-in-chile/#commentsMon, 21 Aug 2006 01:45:30 +0000Jens Hardingshttp://www.hardings.cl/blog/2005/12/19/document-formats-in-chile/Many eyes are paying attention to what is happening in Massachusetts with the Open Format requirement. Good coverage is available via severalblogs, in which Bob Sutor’s blog is probably the most complete and up to date.

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.