George K. (guest) 27 Jun 2012 21:10
So how are going to resolve this license issue with Crossroads?
Does GPL hurt free software? / Discussion
Forum
» Hidden / Per page discussions
» Does GPL hurt free software?
This is the discussion related to the wiki page Does GPL hurt free software?.
George K. (guest) 27 Jun 2012 21:10
The code is licensed under LGPL which means that to change the licensing, all the past contributors would have to approve the license change. That simply won't happen.
This seems incompatible with the stated goals of Crossroads. In fact, it seems like it kinda kills the entire point of having created Crossroads, as you have described it above. The only way to move forward, if you don't find a way to solve the licensing problem, is to sit around waiting for someone else to reimplement it under the terms of a copyfree license.
Have you just given up on the stated goals for Crossroads, then?
I am working on reimplementing the library. It'll probably be MIT-licensed when it's ready.
Sure. I have to stabilise the basic architecture first, then I'll make it public. Any help would be appreciated then.
Hi,
There is an assumption that *other* people will help you with MIT licenced software.
I know of, and am one of, many people who refuse to contribute to non GPL software, precisely so that I never have to compete against some derivative of my contribution.
You keep making the case from a primary developer point of view, which is perfectly fine. The argument changes for contributors.
If you contribute something to a project, do you really want to see your competitor be able to take advantage of it? In most cases, no.
Which is why the GPL levels the playing field amongst competitive companies (e.g. Linux kernel done by Google, Oracle, IBM, Redhat, etc.).
The GPL is a good way to build a community (not the only way by any means) around competing developers. Which makes things better for everyone.
Are you really selling your GPL code so that if someone copies it he becomes a *real* competitor?
If not, you have no competitors and you are probably working for credit. And if so, other people using your code (even in a closed product) are source of the credit rather than a competition. For example, in job interview you can mention that your code is used inside Windows, iOS and Oracle DB. That would give you a lot of credit.
That being said I understand the position of considering the non-free software as evil and thus using GPL to hurt it. That's a perfectly consistent position to take.
BTW: If you are really selling your GPL code it would be interesting to discuss the motivation and the business model.
LOL, I'm opposite. I'll contribute most to free licenses such as MIT and sometimes LGPL. But GPL nope. I will rather find other project which is MIT than contribute to GPL. Only if there's no other choice, only them I'll help GPL
Martin, you don't seem to understand the requirements of LGPL. If you only use the code released under LGPL as a library, that is only statically or dynamically link to it, you can choose any licence you want for your final product (including proprietary one). Only the changes made to the library itself have to be released under LGPL.
That means that Windows, OS X, *BSD can use Crossroads/ZeroMQ no problem. But if they modify your code, the modifications has to be released as free software. But just the modification, not the rest of their code stack. Where is the problem then?
And one more comment about commercial potential of GPL (note, I'm not talking here about LGPL that was discussed above). You said that GPL projects charging money for distribution would be forked and distributed for free. But knowing that, why would you charge for making a copy? Charge for making the software instead, kickstarter-like. Then charge for customisation, new features, bug fixes, support, all the real work you do. Not for making a copy which costs you nothing :)
I've read both GPL and LGPL word-by-word. Several times.
Anyway, LGPL does make the situation better, but it goes just half the way. Imagine the hypothetical case that you want to re-use some of the ZeroMQ code in FreeBSD in-kernel implementation of a similar system. You just can't.
What about Linux in-kernel implementation? LGPL allows re-licensing the LGPL code under GPL, which is nice, however, it's not possible to re-license GPLv3 (ZeroMQ) as GPLv2 (Linux). So you are stuck once again.
Charging for making software: OK. How much are you willing to spend? :)
Seriously: The article takes a broader perspective. It doesn't say you can't make money on GPL software. That would be demonstrably untrue. What it says is that GPL in a non-trivial obstacle to the flow of money in the ecosystem. Which in turn means less developers, less man-hours spent of projects etc. and ultimately less free software.
The upside may be that unpaid work is usually better quality than paid work.
Btw, if I have some free time, I would like to write 2 more articles:
- Why I believe that communication infrastructure, specifically, advances the case of freedom better when permissively licensed.
- Some thoughts about economy of credit (as opposed to economy of money) in open-source world. This has some non-trivial implications for issues like trademarks etc.
Interesting essay. The Github ecosystem appears to back up your observation on the advantages of MIT-licensed software (and other permissive licenses) in the free flow of money and ideas. As you are likely aware, the Github ecosystem, particularly when you don't count the software hosted there that was created prior to the advent of Github itself, is overwhemingly permissively-licensed. And it's clearly thriving.
I think the reason for this is a result of the obstacle you describe that GPL poses to the flow of money in an ecosystem. Some of the people who use the GPL like to think that they are somehow sticking it to the big companies by using the GPL. But it's not the big companies who are hurt by the GPL. They can easily pay for bespoke software, and they usually don't even care that the quality is sometimes inferior to open source software.
Small-time operations and freelancers, on the other hand — the small development firms, low-budget startups, and sole developers who make open source — are hugely hurt by the GPL. The above comment nonewithstanding, it's very hard to make money off of GPL software. Kickstarter has introduced a possible solution, but it's not clear that will work, and prior to that there was almost no solution for smaller operations except for the duplicitive and exploitative practice of "dual licensing".
Most young Github devs seem to have realized this, and are overwhelmingly licensing their software permissively. And so they all use each others software whenever they do need to create proprietary projects to pay the rent.
Which then allows them to then make more permissively-licensed open source, and so the cycle continues.
That's my thinking as well. One interesting additional thought would be that prevalence of GPL (I think it's still the leading OS license) have lead to expanse of software as a service as opposed to traditional packaged software. With SaaS you don't have to re-distribute your software even if you've used GPL'd components. That allows you to actually make money of it.
If the proposition is proved true, it would mean another unintended consequence of GPL, namely increased centralisation of the data, with privacy issues, spying and all the other stuff that ensues.
I think there is a hole in your argument.
Suppose I am a developer and I'm writing a library. I want to decide between licensing it as BSD or LGPL.
Suppose I make a living selling consulting related to this library - that is, developing proprietary software for clients that uses the library (which both the BSD and the LGPL allow). Sure, anyone else can offer the same consulting services, but I have a competitive advantage because I wrote the library (or most of it) and I know it the best.
Now suppose I licensed the library under BSD. Along comes Bob, and implements a new feature in the library. Had the library been LGPL, Bob would have had to release the new feature under LGPL, but this way he can keep it proprietary. He offers consulting services of his own, on top of the improved library. I now have to compete with his services, which may be more attractive to my clients because of the new feature - and yet, I did most of the work, I wrote all of the library except this feature.
You might argue that even if the library were LGPL, Bob would only have to give the source code of the new feature to his clients… but it would take just one client to distribute it to the public, and Bob's monopoly over it would be over - and clients, collectively, would have an incentive to do so, because having the new feature available to the public would reduce the value-added, and thus drive down the price, of Bob's services.
In theory, you are right. However, try imagining yourself in the customer's position.
You can choose between a fully open BSD-licensed product supported by the original developer and all the community around the project. Or you can choose Bob's proprietary closed source fork of the project that happens to have one additional feature.
Consider the consequences. To get one feature you are betting your business on Bob's ability to deliver. If Bob gets hit by a bus, you are in a trouble. Same if Bob decides to discontinue the product. Also, you are locked-in to Bob's product, thus at Bob's mercy. If Bob decides to double his rates, there's no one else to help you.
All in all, from a business perspective it makes more sense to hire someone (presumable the original developer!) to implement the feature you need and either merge it back to the project or keep the patch for yourself.
I am interested in your thoughts in relation to the various iterations of leadership, forking and progress outlined in the gpl'd WebKit Browser Engine, as described by John Resig, at
ejohn (dot) org/blog/webkit-is-the-jquery-of-browser-engines/
(posted February 13th, 2013). Basically, KDE creating ->KHTML, Apple -> WebKit, based upon that, Google -> WebKit/Chromium, and now with Opera participating.
Your point is well taken that you want NanoMSG to be incorporated as an infrastructure into all OSes, and the gpl impairs that aim.
For the browser, as "mostly" an application-level program, there does to appear to be a solid demonstration of how the forced sharing of gpl has allowed and furthered the improvement of browsers by multiple entities.
I would tend to agree, the WebKit history may or may not have much to do with your topic "furthering free software".
Well, I am not following the WebKit development, but my point was about GPL building artificial barriers. Thae this example:
"They can implement a number of their Opera-specific features into WebKit and it’s likely that those features will start to trickle back into other WebKit-using browsers as well."
If the case was that WebKit was originally BSD licensed, Opera took it and made it GPL licensed, the patches won't trickle back.
How can we contrast this with Android which is under APL(save the kernel), and getting fragmented by other vendors, ranging from Smasung to some small chinese manufacturer?
In this case, Google would had the benefit by licensing Android as GPL instead of APL.
One license does not fit all scenarios(OS , service software, libraries, etc), it actually depends on what your aim is and what strategy you would employ to forward it.
As I see it, GPL in business requires the mental model that code is only written as needed (and that work is paid by somebody) and the resulting code is free (both as-in-beer and as-in-freedom). That is, GPL enforces that nobody can make money from the already created stuff and extra work is required in exchange for extra money. This directly goes against any business model that depends on "Copyright" as intellectual property or imaginary property that is rented, leased or sold. GPL cannot be enforced if "Copyright" does not exists at all, and in that case GPL would not be needed at all.
GPL is all about making sure that "Copyright" cannot be used to restrict the usage of a piece of work (both as-in-end-user-usage and as-in-used-for-derivative-works). MIT/BSD/Public domain is about making sure that end recipient of a piece of work is free to do whatever he pleases (roughly, credit must be preserved in case of MIT/BSD).
If you create a new piece of work, the work will receive most distribution if it's released under MIT/BSD/Public domain licensing because that allows most users (direct end users and creators of derivative works) to benefit from your work. GPL prevents creators of derivative works from getting more freedoms than the end users. As a result, you'll lose the part of the user base that is not willing to play on a level playing field.
The original motivations of the license for GNU's software were sound. Ultimately, however, the fanatical copyleft devolved quickly into feet stamping and spite.
I once even saw it claimed that if someone (A) releases code under a permissive license, and someone (B) forks it and releases their version under a proprietary license, that someone's (A) software becomes proprietary. There's not a whole lot of logic in statements like that.
All the above is true, but there's another aspect to it: The level part of the field is pretty small.
By using GPL you are locking yourself into a tiny corner of the ecosystem. Imagine how popular would Linux be if it required all the applications running on top of it to be GPL-licensed.
Yes, the original intention was that the leveled field will gradually expand until in the end everything is GPL. However, that doesn't seem to be the case. I bet it's for the same reason that real socialism haven't worked: Any system based on assumption that people would behave in such a way as to increase common good, even in spite of personal disadvantage, is not ecologically viable.
It's an unfair universe.
It's an unfair universe.
Your possition is a bit sad.
On the other hand you can stand the idea of the "unfair universe" only because you are not being able to think from the point of view of those hurt by that.
Lot of people will not be able to use MIT/BSD stuff, because it is only implemented in privative packages. Is this the time to think on those?
MIT/BSD license is conservative of the "status quo" you are only thinking from the point of view of someone on the winning side.
If it's private, it's proprietaty, not MIT/BSD, no?
/forum/t-513129/does-gpl-hurt-free-software#post-
