There’s an issue that’s been bothering me for quite a while. There’s a problem in the software development world, a practice that breaks down the free and open exchange of information. This practice is widespread throughout the software development world and can lead to a lock-in mindset that is damaging for the advancement of the community as a whole. I’m talking, of course, about copyleft licenses such as the GPL.

via Is Copyleft Really Right for Open Source? – Intridea Blog.

[This started out as a comment on the post above, but it ran long – as my comments are wont to do.]

While I generally agree with the delineation Michael makes (GPL for large systems, MIT for small libraries and tools), I think his characterization of the intentions of the GPL misses out a bit on its historical backdrop. The UNIX family of OSes was severley hobbled by the fragmentation that was a direct result of the original BSD code being, well BSD-licensed. Every vendor built their own incompatible system and it caused a lot of grief for software maintainers and sysadmins alike. Among other things, this is a big part of why we have to deal with the horrible pack of hacks that is Autotools.

So what could Diaspora have done differently? They could have licensed with a very permissive license but added a clause: any modified version of the Diaspora code must remain interoperable with the “standard” release laid out by the Diaspora team. In this way, they could have allowed a thousand seeds to be planted by any company that wants to take a crack at it, knowing that these companies are license-bound to continue supporting the distributed infrastructure of the project.

It’s easy to say “just include a compatibility clause” but in practice that accomplishes nothing. Lots of vendors paid lip service to standards like POSIX, but their clients were locked in anyway because of proprietary APIs that extended beyond the POSIX-specified ones. It would be very easy for a hypothetical “Oracle Diaspora” to hold to the letter of the license and maintain backward compatibility with other Diaspora systems – but to add a whole new set of Oracle-specific APIs. Once an organization began depending on plugins which required on the Oracle extensions for full functionality, they would be effectively locked-in.

In any case, I don’t think Diaspora is a good example, because of all the obstacles preventing that project from ever achieving meaningful success, the license is the least of their worries. Diaspora suffers from the Chandler Sydrome; a total failure to comprehend the economics and dynamics of Open Source systems. You can’t throw money at a vague concept and get usable, popular Open Source software out the other end. It’s been shown time and again that it doesn’t work. OSS projects have to be driven by either a specific itch (usually) or a business plan (more rarely, but see Canonical and Ubuntu).

Rails is actually an interesting test case for MIT licensing in the large, because it is a big enough system and has achieved sufficient corporate interest that someone could potentially release a forked version with proprietary extensions. E.g. (to pick on Oracle again) an “Oracle Rails” with extra features that enabled special hooks into Oracle DBs. Only time will tell; but I hope (perhaps optimistically) that that era is over, and there is now sufficient appreciation for Open Source values within the IT community that any such attempt would be a non-starter.

Published by Avdi Grimm

4 Comments

  1. actually his clause is not compatible

    Reply
  2. You raise an interesting point re: expanding on open source APIs to the point of damaging the community. I think another example of this is Microsoft's attempts to “improve” Java by making the Windows Java contain features that other versions did not. The GPL does act as a kind of safety net here, ensuring that at the very least if someone is going around making a pseudo-proprietary format on top of open source that there is recourse. I hadn't considered that and I believe that's a real argument for the use of copyleft licenses.

    I would still argue, however, that this applies to a small subset of the overall open source project population. In addition, these kinds of “bad proprietary tactics” can only be employed by a few large, powerful companies that have the resources to force their version to become popular (Microsoft, Oracle, Google, Apple, are some examples, but there are maybe tens not hundreds of companies that could do so). The GPL simply includes a kind of distrust and paranoia that, in my opinion, are far overkill for the vast majority of open source work. It makes a fundamental assumption of evil rather than good, and I think that's my big problem with it.

    Reply
    • Like I said, I agree with your overall delineation between which projects should be GPLed and which shouldn't. Although I don't think this GPLing is as epidemic as you seem to think; Open Source C++ and Java middlewares were being put under MIT-style licenses for years before Ruby was even on the map, for precisely this reason. Their creators didn't want their adoption hobbled by fears that commercial products couldn't incorporate them.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *