14 Dec 2013

44766

11

Intellectual Property: Ideology vs Practicality

The thing that people need to keep in mind when discussing the GPL is that it was created to achieve an ideological and political goal, namely that users of software should have the right to modify and extend the software as they see fit. To achieve this goal, the GPL seeks to ensure that the source code is always available and that reusing the source code in question comes without any restrictions save for what the GPL itself imposes in order to ensure this "right" is never withdrawn. There are certainly noble aspects to this goal, but there are also consequences for programmers that run into code under the GPL. The biggest is that the GPL is basically an all or nothing proposition. If you wish to use GPL covered code directly in your own application, your own code then becomes bound by the GPL and you are obliged to produce that code upon request. This obligation should not be considered trivial or burdenless, which all too often happens with some of the more fanatical free software advocates. After all, their goal is to see all software fall under the GPL because they consider that to be the 'correct' state of things in the software industry. The problem however is that by placing advancement of an ideological position as the primary objective, the GPL can actually discourage the reuse of code licensed under it.

As mentioned above, when one uses GPL covered code, one's own code then comes under the GPL and an obligation is created to make the source available upon demand. Again, this is a burden in that there is a cost in time and resources to make the source available. If a developer does not believe in the ideology of the GPL, then the burden must be weighed against the benefit of not having to write whatever functionality the GPL code provided. In many instances, the cost is far greater than the benefit because once the code is under the GPL, that iteration will always be under the GPL, creating a long term obligation and burden. As such, it can become cheaper in the long run to roll one's own solution than to reuse existing GPL covered code. Another alternative is to go with code covered under more permissive licenses such as the Apache or BSD license. These require that their code and direct modification of their code remain under the BSD, but there is no requirement that every other piece of the software come under the same license. These licenses thus make it easier to use their code by limiting any obligations that are imposed by the use. For developers that do not care about ideology or for companies that have considerably complex intellectual property agreements, it becomes easy to pick which body of code they would rather use.

While I make no argument about which position is "right" or "wrong," I do make an argument about which is ultimately more usable from a programmer's perspective. The software world is a complicated place and programming is difficult enough without having to think about the additional legal complexities of a certain body of code. Metaphorically, open source versus closed source can be considered white and black whereas free software is gray. With open and closed source, you know fairly easily whether you can or cannot use the code. With free software, the situation can become sticky very quickly.

Comments (11)

  • anon

    It's very simple, actually:
    Strong copyleft (GPL) gives more freedom to users, at the expense of developers' freedom.
    Lack of copyleft (BSD, MIT) gives more freedom to developers, at the expense of users' freedom.
    Weak copyleft (LGPL, which you forgot to mention) is a in between the two.
    Naturally, many developers consider their own freedom to be more important than users' freedom, and thus use non-copyleft licenses. Some just don't care about freedom at all, and use whatever is most convenient.

    Dec 15, 2013
  • anon

    If you are writing a piece of code that you intend to be reusable by others, then choosing a weak or non-copyleft license is in my opinion an indication that you want to make it as easy as possible to reuse, not that you care about your own "freedom" more than your user's. If you as a developer choose to use code that is under a weak or non-copyleft license, I would argue that you are laying the groundwork for making your own code more easily reusable if you ever decide to open source it.

    Dec 16, 2013
  • anon

    I think is somewhat arguable about the costs of releasing the source code (I don't argue that in some cases releasing it kills the business, though), as there are several services out there for it, free of charge. For example, github and sourceforge, which as long your software is open source, provide this storage for free. The first also gives you lots of convenience tools with git. I don't know if there are any professional tools that make it even more convenient to work than git, but I've been using it and is a nice tool.
    If you have no need of keeping it closed source, I don't think there is any drawback in working directly in the open, and this releases a lot of the burden of distribution of the source code, as you can use such services. Of course, it is an extra work if you work in the closed and release your source code only after every binary release.

    Dec 15, 2013
  • anon

    Here's the problem with that line of reasoning. You are presuming that keeping something closed is the thing that needs to be defended/argued for. Flip the reasoning to you needing a reason to make it open and the relative costs increase.

    Dec 16, 2013
  • anon

    No, I'm just assuming such an analysis was already taken care of, and the developers seem to be interested in releasing the source code, for whatever reason they have; if they are not interested, I think there is nothing to discuss, it is their IP and they can do whatever they want with it. If there is interest from the developer, there are a few things that can be show stoppers, one is actually being unable for legal reasons, another one is it killing the business (already mentioned), then costs is another (which is what I'm arguing in my previous comment, that nowadays, new projects have virtually zero cost to open source if the developers want it that way), or just being closed source a need for the project for whatever technical reason, but in any case the point to be defended and the point to be taken as "default" is to be decided by the developers, based mostly on which model they do like better.

    Dec 20, 2013
  • anon

    An extra, shorter comment. There is also the case where you don't want the code available for everyone, but choose to give it on request to your users only. But there is some practicality there: you are giving it to them under the GPL. There is nothing stopping them from spreading it, as the license allows them, and this means almost surely that somebody WILL spread it, so not releasing it for everyone is just trying to slow down the inevitable.

    Dec 15, 2013
  • anon

    If you want to restrict distribution of your source code, you would never choose to use the GPL to begin with.

    Dec 16, 2013
  • anon

    Actually, that's kind of what I meant. My point was, there might be a case where you want your clients to be able to study/modify the program (for example, some game engines do license the source code in special conditions), but that the GPL doesn't suit it well.

    Dec 20, 2013
  • anon

    It's as simple as asking you these questions, in order:

    1. Do you want others to be able to study the code?
    2. If so, do you want others to be able to build upon your code?
    3. If so, do you want others to share their work like you did yours?

    Your choice of license depends on how strongly you would say "yes" to each:

    • If you don't want others to see the code, don't release it at all.
    • If you want others to see the code but not use it for anything other than understanding the product, then you want some sort of "shared source".
    • If you want others to be able to modify the code or use it for other projects, but don't care if they don't release the new code, then you may want to choose a non-copyleft license, since it exclude less people.
    • If you want others who modify or build upon the code to also share it in the same way you did, then you want a copyleft license. Weak or strong copyleft simply matters of how strong you want the share-alikeness to be.

    Dec 23, 2013
  • anon

    I feel the post is actually sidestepping the real issue here. After all, since the title is 'Ideology versus practicality, and it's clear the GPL is considered the ideological tool, one is left wondering what is considered the tool for 'practicality'. BSD? Closed source? It seems to say that the normal way of doing things (aka, buying a licence) is more 'practical'. But is it?

    "The problem however is that by placing advancement of an ideological position as the primary objective, the GPL can actually discourage the reuse of code licensed under it."

    Closed source, of course, also discourages the reuse of code. Some seem to forget that following the free, liberal market where one asks money to use anything is ALSO an ideological position (namely a capitalistic one). Not that I disagree in principle with it - and it certainly has proven itself superior to communism, for instance - but nevertheless, it's an ideology. And that ideology ALSO puts a burden on the one using it, which often can exceed that of the GPL.

    "As mentioned above, when one uses GPL covered code, one's own code then comes under the GPL and an obligation is created to make the source available upon demand. Again, this is a burden in that there is a cost in time and resources to make the source available."

    And closed source, when one uses IP-protected code, also creates a burden in cost and time and resources, but then for the use of the product itself. Depending on how much is asked, and the conditions imposed, and how much one evaluates ones' own program to be worth - it can well be that it's far greater than the burden a GPL-licence imposes. There is no free lunch, so comparing an ideological driven licence to free things up, with an (actually also ideologically driven) licence that holds all the IP rights can not be settled with saying one is burdened and the other isn't. No, they both are. What the 'greatest cost' is for a developer, depends on the circumstances and certain variables, as explained above. However, the poster seems to forget one important aspect, which makes the whole issue of 'what is better (aka, more or less burdersome)' of the two rather obvious.

    The fact of the matter is, that code which falls under the GPL is more encompassing (in a meta-sense) than any closed source, ALSO for distributing it. Let me explain: while the code made by a developer can be placed under the GPL, it still is that developers code, so ONE CAN STILL ask, or, indeed, buy a licence FROM that developer. This is called dual licensing. Nothing - not even the GPL - prohibits the developer from making his code ALSO available as a licensable piece of code that others CAN use without fearing that they have to put all their own code under the GPL licence.

    The reverse is not true, however. If you buy closed source code you can't just decide to put it in GPL-code. Well, you can if the developer agrees to it, but then neither him or anyone else can expect it to remain closed source, then. So, if one puts something under the GPL, it's still possible to let people buy a license as if it were closed source (aka, they wouldn't need to change their licence for their software); the possibility of dual (multiple) licensing makes the counterargument that one then has an unreasonable burden (compared to normal licensing practises) invalid. You can still make use of the closed source licensing if the developer allows it, while it still remains free for others to use under the GPL. The reverse is not possible, or at least, amounts to the same: if you have a free and a closed way of doing it, you still have the free way of doing it.

    It becomes clear, thus, that making code under the GPL, does not inherently mean you can't use a closed source variant anymore. Nothing prohibits the ones wanting to use it, to ask if they can have it with a license other than the GPL. Most developers will do so, imho. And for the GPL-die-hards that won't, well, one can always create the code oneself, then. In essence, this does not change from a closed source code which asks a too great a price, for instance; there too, the devs will need to make it themselves if they think the price is too high. So in the worst case, it amounts to the same, and in the best case, the fact that one can dual license, also with code under the GPL, means that there is more freedom, at least potentially. GPL'ed code does not inhibit using it as it were closed source (while closed source does inhibit it being given away as GPL'ed source, or, at least, it's no longer closed source, from that moment). I think I made this clear enough, and that it's obvious which has the most potential to be used in different ways.

    Now, of course, this handles closed source and GPL'ed source, but...one also has BSD licenses. Which one of the 2 (or 3) is the most 'free' (aka, freedom to use/distribute)? Well, logic indicates, that it's the BSD. I have to agree with this, thus: http://www.matusiak.eu/numerodix/blog/2007/12/15/gpl-vs-bsd-a-matter-of-... . Viewed on itself, there can be no discussion that a licence that gives you the possibility to do whatever you like, even making it closed source, is more free than a licence that obliges you to follow their rules, be it GPL-rules or closed-source rules. This is self-evident.

    The author uses impeccable logic:

    "What the GPL terms "freedom" is actually fairly subversive, because it *forces* you to do certain things. Most people who are forced to do something call that a "restriction" rather than a "freedom". It's true that you have certain freedoms when you get the software, but if you want to pass it on you have restrictions, so they could just as well call it the four freedoms and the four restrictions.

    Therefore, if we take the philosophical ideal of freedom to heart, even though both of these licenses promote free software, none of them represent freedom, and the GPL is far less free than the BSD."

    Spot on.

    Now, he also makes a good point later on, however, that while BSD may be 'more free', when it comes to sustainability of that freedom, it becomes a whole other matter. As far as the wish for accumulated knowledge and progress is concerned, the GPL is better suited than the BSD. Point in case; there have been many examples where BSD code is being taken, used, and made it closed source (Microsoft did it with network code if memory serves right), thereby cutting off all improvements they might make on it. This would be impossible with the GPL. The GPL is a way to even the playing field, and make sure that what was once freely given, remains free.

    Is this an unduly burden to devs? Me thinks not. It boils down to the logical reasoning and habit of reciprocity: equal give and take, using the same arguments under the same conditions, etc. This is generally considered to be the most logical (imagine a debate where no reciprocity of argument is deemed needed) and the most fair. One can be 'more free' with the BSD, but that freedom is therefore not 'most suited' to make the most progress on the code/program, which is, I would venture, a very important goal of any dev, which supersedes the mere ideological ones.

    So, what is more 'usable from a programmer's perspective'? Well, I agree that clear licensing makes everything (the use/distribution, etc.) more clear and thus is preferred for a dev. I would wager though, that all 'free' (in the sense that z98 used it) software has *some* sort of license. I don't think there are large bodies of valuable code on the Net which doesn't have either a variant of closed source, or a variant of open source licences. In fact, if I remember correctly, they once made a survey of what % of particular licensing open source software used. I think of all the open source software, it was over 90% GPL and BSD (or variants, like the LGPL). There is a high degree of uniformity, thus. The problem hardly arises, thus. If anything, it will be more cumbersome with closed source, since, while the basic tenet is the same: 'you pay and you can use it', it's best to read the small print, to see how and when you can use it, or you might get the short stick. So even there, the devs are generally better off, with less ambiguity, with open source software than with closed source. software which uses vague and ambiguous licenses and conditions: well, one should better stay clear of those, whether they are closed or 'free'. (It has little to do with closed vs free, thus, but all with how clear the licence is).

    All in all, I would say that the ability and usage of using dual licensing, coupled with making ones code fall under the GPL, gives devs the most opportunities to go forward the fast as possible.

    Jan 01, 2014
This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.