Why you shouldn't use the Lesser GPL for your next library(gnu.org)
gnu.org
Why you shouldn't use the Lesser GPL for your next library
http://www.gnu.org/licenses/why-not-lgpl.html
9 comments
This is reminiscent of the RIPEM situation ~20 years ago. This was a program that did email encryption using RSA. RSA was implemented using a library from RSA (the company) that was freely distributable but not free software, and because RSA (the encryption method) was patented, there was no way in the US to replace this library with free software.
RIPEM also needed a big integer math library. The two main free software libraries for this were the GNU one and the the BSD one, which had different interfaces. RIPEM could be built to use either. This was an option you could set when you ran the build script.
The FSF said that distributing the RIPEM source code was a GPL violation, even though they did not claim copyright on any code in the RIPEM distribution. In particular, they were adamant that they were not claiming a copyright on the GNU mp library interface.
Their claim was that since RIPEM contained code (the conditional code that used the GNU mp interface) that was only useful with GNU mp, distributing that source code would lead to some people downloading GNU mp, which they would then link with RIPEM and the non-free RSA library, and that this meant that the RIPEM people had effectively distributed GNU mp with non-free software. See note [1].
The RIPEM people finally put an end to this nonsense by making a "new" mp library that had the same interface as the GNU mp library and was either (memory is hazy) just a thin wrapper for the BSD mp library, or was just a quick and dirty implementation of the simple, classical mp algorithms that any decent programmer can knock out from Knuth fairly quickly.
This meant that people receiving the RIPEM source and choosing to build using the GNU mp interface might not actually build with GNU mp. They might instead build with this new library. Now induced distribution can no longer be inferred. This satisfied FSF.
This was pretty astounding. If X is written first, and Y is written second, the answer to the question of whether or not Y infringes the copyright of X does not change if a third thing, Z, comes along AFTER X and Y. Copyright law obeys the arrow of time. :-)
[1] I may not be remembering their theory exactly correctly. The general outline (RIPEM not distributing any GPL code, but FSF thought they were liable anyway if someone downloaded RIPEM source, downloaded GNU mp source, and linked them together) is right.
RIPEM also needed a big integer math library. The two main free software libraries for this were the GNU one and the the BSD one, which had different interfaces. RIPEM could be built to use either. This was an option you could set when you ran the build script.
The FSF said that distributing the RIPEM source code was a GPL violation, even though they did not claim copyright on any code in the RIPEM distribution. In particular, they were adamant that they were not claiming a copyright on the GNU mp library interface.
Their claim was that since RIPEM contained code (the conditional code that used the GNU mp interface) that was only useful with GNU mp, distributing that source code would lead to some people downloading GNU mp, which they would then link with RIPEM and the non-free RSA library, and that this meant that the RIPEM people had effectively distributed GNU mp with non-free software. See note [1].
The RIPEM people finally put an end to this nonsense by making a "new" mp library that had the same interface as the GNU mp library and was either (memory is hazy) just a thin wrapper for the BSD mp library, or was just a quick and dirty implementation of the simple, classical mp algorithms that any decent programmer can knock out from Knuth fairly quickly.
This meant that people receiving the RIPEM source and choosing to build using the GNU mp interface might not actually build with GNU mp. They might instead build with this new library. Now induced distribution can no longer be inferred. This satisfied FSF.
This was pretty astounding. If X is written first, and Y is written second, the answer to the question of whether or not Y infringes the copyright of X does not change if a third thing, Z, comes along AFTER X and Y. Copyright law obeys the arrow of time. :-)
[1] I may not be remembering their theory exactly correctly. The general outline (RIPEM not distributing any GPL code, but FSF thought they were liable anyway if someone downloaded RIPEM source, downloaded GNU mp source, and linked them together) is right.
As it happens, this exact argument was put forth by the "at least one application program" that converted to free software:
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
It was never actually resolved, because the CLISP author decided that making his program free software would be a good idea for other reasons anyway. In the past, I would have disagreed with RMS's insinuation that a GPL violation would occur, because, as stated:
> So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?)
Only... we just got a US court decision that APIs are copyrightable. Although readline's API is much simpler than large parts of Java, it's substantial enough that I'd argue the decision nevertheless implies that libedit is a copyright violation. Which I find ironic, since most of the programs affected by the decision are free software clones of proprietary software, not the other way around.
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
It was never actually resolved, because the CLISP author decided that making his program free software would be a good idea for other reasons anyway. In the past, I would have disagreed with RMS's insinuation that a GPL violation would occur, because, as stated:
> So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?)
Only... we just got a US court decision that APIs are copyrightable. Although readline's API is much simpler than large parts of Java, it's substantial enough that I'd argue the decision nevertheless implies that libedit is a copyright violation. Which I find ironic, since most of the programs affected by the decision are free software clones of proprietary software, not the other way around.
The court opinion stressed pretty strongly that Google's usage of the Java API was never actually intended to build an interoperable implementation (stating that Google was unable to point to any specific examples of code that would even be interoperable ;P) but instead to build a non-interoperable platform that was heavily inspired by the work that was put into Java. I think Google could have made a better case for attempting to be interoperable in certain ways (such as with libraries as opposed to "apps"), but apparently they didn't, and in fact came off quite strongly as trying to build their own unrelated-to-Java platform for various technical and business reasons. It still seems to be the case that if you are building a system whose goal is truly to be interoperable (such as libedit is to libreadline) you would not run into problems. For much more detailed commentary and argument (as well as quotes from the opinion), I encourage you to read my comment from that thread:
https://news.ycombinator.com/item?id=7723853
https://news.ycombinator.com/item?id=7723853
I don't have a clue what Google's specific goals were, but couldn't an argument be made that compatibility with existing knowledge of developers is also a form of interoperability, and in particular one that needs to be protected from monopolization?
At that point copyright becomes meaningless (though if you are willing to go that far that's great: I don't see anything inherently incorrect about the position "copyright is meaningless"): "I needed my photograph to look like yours because everyone was familiar with yours and I wanted them to feel the same way as they did when they saw yours".
Well, yeah, I don't see much inherently meaningful in copyright either, in particular because drawing boundaries is ... difficult, to say the least.
But I think your example still doesn't quite capture what I mean ... even though, well, maybe it does, but let me explain ;-): What I had in mind is in particular that getting familiar with an API requires effort, so it's kindof an investment on the part of the developer. After all, an API is as much a human/machine interface as it is a machine/machine interface. As such, it is problematic to allow anyone to have a monopoly on that investment, essentially a monopoly on the use of those developers' knowledge. And protection of investments is one of the arguments (the argument?) for interoperability exceptions--so, why only for machine/machine interoperability and not also for human/machine interoperability?
I guess the "investment" aspect doesn't work that well for your example, but I still can see some value in the argument, in particular if you apply it to DRM (type) systems and culture in general.
But I think your example still doesn't quite capture what I mean ... even though, well, maybe it does, but let me explain ;-): What I had in mind is in particular that getting familiar with an API requires effort, so it's kindof an investment on the part of the developer. After all, an API is as much a human/machine interface as it is a machine/machine interface. As such, it is problematic to allow anyone to have a monopoly on that investment, essentially a monopoly on the use of those developers' knowledge. And protection of investments is one of the arguments (the argument?) for interoperability exceptions--so, why only for machine/machine interoperability and not also for human/machine interoperability?
I guess the "investment" aspect doesn't work that well for your example, but I still can see some value in the argument, in particular if you apply it to DRM (type) systems and culture in general.
For me, part of the difference is whether the interoperability is complete or fuzzy: I don't feel like you can be "only sort of interoperable", and that seems to be the big difference between the human/machine and machine/machine examples (it isn't that the interoperability is a different kind of interoperability, it is that it is a different level of precision in the kind of interoperability). A developer of will notice important differences in Java vs. Android.
To explain some more with my photograph comment: the photograph might have taken time and context and thought on behalf of an entire population of viewers to come to some "meaning"; maybe this is more obvious if we take a storyline from a popular television show: before the show people didn't care about the topic of the show, but after the investment, quality, and success of the show now people really like that topics and in particular the story progression that went along with it.
People are familiar with that story: to really allow those people to feel good about the new story, maybe it has to be similar to the old one? If you go down this path for a while, you start reading about idea/expression differences as they apply to literary and visual works: high-level plots and themes are not protected, but specific details and timelines are. The idea of organizing code into packages and classes is not, but the specific choice of what classes to put in what packages and what they are named are.
FWIW, I personally feel like a lot of the benefit of trying to be "interoperable" with someone's perception of how to program is sufficient to be at that higher "idea" level: when I use C# or Objective-C (which in many ways feel similar to Java and in the case of C# was pretty much designed as a direct replacement for Java) I am highly familiar with them despite not feeling like they are the same: I gain a lot of the benefit of C# and Java having similar ideas, despite the fact that they clearly have different expressions.
Now, that said? I continue to appreciate the idea that this is all a stupid distinction: but if you erase this distinction I am not certain where you still draw the line for claiming copyright on anything. Given the idea "investment in expression should be protected" (an admittedly-oversimplified version of "copyright"), I don't think you still have "investment by consumers in content should be inherently reusable by other creators". I could be wrong, however, and would love to hear more ideas.
To explain some more with my photograph comment: the photograph might have taken time and context and thought on behalf of an entire population of viewers to come to some "meaning"; maybe this is more obvious if we take a storyline from a popular television show: before the show people didn't care about the topic of the show, but after the investment, quality, and success of the show now people really like that topics and in particular the story progression that went along with it.
People are familiar with that story: to really allow those people to feel good about the new story, maybe it has to be similar to the old one? If you go down this path for a while, you start reading about idea/expression differences as they apply to literary and visual works: high-level plots and themes are not protected, but specific details and timelines are. The idea of organizing code into packages and classes is not, but the specific choice of what classes to put in what packages and what they are named are.
FWIW, I personally feel like a lot of the benefit of trying to be "interoperable" with someone's perception of how to program is sufficient to be at that higher "idea" level: when I use C# or Objective-C (which in many ways feel similar to Java and in the case of C# was pretty much designed as a direct replacement for Java) I am highly familiar with them despite not feeling like they are the same: I gain a lot of the benefit of C# and Java having similar ideas, despite the fact that they clearly have different expressions.
Now, that said? I continue to appreciate the idea that this is all a stupid distinction: but if you erase this distinction I am not certain where you still draw the line for claiming copyright on anything. Given the idea "investment in expression should be protected" (an admittedly-oversimplified version of "copyright"), I don't think you still have "investment by consumers in content should be inherently reusable by other creators". I could be wrong, however, and would love to hear more ideas.
Interoperability is relevant to fair use, but it's not the only factor. For instance, when Florian Mueller looks at the fair use argument, he cites a number of factors that weigh against it, of which the supposed lack of interoperability is only one:
http://www.fosspatents.com/2012/05/oracle-v-google-fair-use-...
http://www.fosspatents.com/2014/01/why-google-books-is-proba...
While I'm not a lawyer, it would make sense to me for API reimplementation not to be fair use when viewed from the perspective of copying "declaring code", even if interoperability is stronger or argued stronger. Incorporating part of a copyrighted work in a new work intended for exactly the same use, which competes with the original, is not "transformative", and certainly has an "effect of the [] value of the copyrighted work"; it doesn't look much at all like normal examples of fair use, such as thumbnails and quotations.
Also, I did read the decision itself, and the part about fair use didn't seem particularly friendly to Google's argument, even if the issue was remanded. In particular,
"We find this particularly true with respect to those core packages which it seems may be necessary for anyone to copy if they are to write programs in the Java language."
where "this" is relevance to fair use, reflects badly on the majority of packages which are not necessary to write programs in the Java language. (I think this definition of "language" is nonsense, as even though it's what a programmer would call the Java language, I think the analogy is to human languages, which were found to not be copyrightable; yet human languages include a large amount of vocabulary, which I find analogous to API declarations. However, it's what the court used.)
We will have to see what happens in the Android case, including appeals, as well as any future cases (though I'd say the former has a good chance of producing a chilling effect that will greatly decrease the probability of potential subjects of the latter from even being created), but I don't agree with your relatively positive assessment of the power of fair use.
Also, fair use determinations can, like in this case, be decided by the jury rather than the judge, and I trust juries far less than judges to weigh how the facts actually apply to the law rather than whether it feels like some company ripped off some other company.
http://www.fosspatents.com/2012/05/oracle-v-google-fair-use-...
http://www.fosspatents.com/2014/01/why-google-books-is-proba...
While I'm not a lawyer, it would make sense to me for API reimplementation not to be fair use when viewed from the perspective of copying "declaring code", even if interoperability is stronger or argued stronger. Incorporating part of a copyrighted work in a new work intended for exactly the same use, which competes with the original, is not "transformative", and certainly has an "effect of the [] value of the copyrighted work"; it doesn't look much at all like normal examples of fair use, such as thumbnails and quotations.
Also, I did read the decision itself, and the part about fair use didn't seem particularly friendly to Google's argument, even if the issue was remanded. In particular,
"We find this particularly true with respect to those core packages which it seems may be necessary for anyone to copy if they are to write programs in the Java language."
where "this" is relevance to fair use, reflects badly on the majority of packages which are not necessary to write programs in the Java language. (I think this definition of "language" is nonsense, as even though it's what a programmer would call the Java language, I think the analogy is to human languages, which were found to not be copyrightable; yet human languages include a large amount of vocabulary, which I find analogous to API declarations. However, it's what the court used.)
We will have to see what happens in the Android case, including appeals, as well as any future cases (though I'd say the former has a good chance of producing a chilling effect that will greatly decrease the probability of potential subjects of the latter from even being created), but I don't agree with your relatively positive assessment of the power of fair use.
Also, fair use determinations can, like in this case, be decided by the jury rather than the judge, and I trust juries far less than judges to weigh how the facts actually apply to the law rather than whether it feels like some company ripped off some other company.
None of this responds to my point in context that the analogy "libedit is to readline as Android is to Java SE" does not hold due to arguments that were levied against Android not being applicable to libedit. I also am confused by some of your comments here regarding my stance on fair use: I think that there is a core misconception people have in this case with relation to the separation of "infringement" from "fair use", but to be clear: I would not personally bet much on Google winning fair use (though I would also not bet much against: the jury was hung before, I doubt Google will manage a more intelligent argument, and so maybe it will go either way).
More importantly, though: nor am I even certain I wish/hope that Google does win, as I have great sympathy for the argument that they were never intending to build an interoperable system. I tried very hard to not put a strong opinion in my comment on the other thread (as I really and truly can appreciate a number of other consistent positions, including ones as strong as "copyright is inherently wrong"), so I'm guessing you just assumed me to be arguing for the thing you wanted (which sounds like "Google should win"): I maintain my "relatively positive assessment" even in the situation where Google loses, as I think this case is materially different than ones I care about.
Finally, I will point out that you are preaching to the choir on "chilling effects": that is what my entire final paragraph both admits and (in the nod to the comment from grellas with respect to "uncertainty") laments. The only positive thing is that "interoperability" does have some status in the world of copyright, if nothing else in the DMCA's reverse engineering restrictions, and there is a wide pool of precedent for the legality of building systems based on the knowledge from said reverse engineering (so it isn't just that you get to reverse engineer things and then feel satisfied with the knowledge: you get to release production systems that embody that learned knowledge).
More importantly, though: nor am I even certain I wish/hope that Google does win, as I have great sympathy for the argument that they were never intending to build an interoperable system. I tried very hard to not put a strong opinion in my comment on the other thread (as I really and truly can appreciate a number of other consistent positions, including ones as strong as "copyright is inherently wrong"), so I'm guessing you just assumed me to be arguing for the thing you wanted (which sounds like "Google should win"): I maintain my "relatively positive assessment" even in the situation where Google loses, as I think this case is materially different than ones I care about.
Finally, I will point out that you are preaching to the choir on "chilling effects": that is what my entire final paragraph both admits and (in the nod to the comment from grellas with respect to "uncertainty") laments. The only positive thing is that "interoperability" does have some status in the world of copyright, if nothing else in the DMCA's reverse engineering restrictions, and there is a wide pool of precedent for the legality of building systems based on the knowledge from said reverse engineering (so it isn't just that you get to reverse engineer things and then feel satisfied with the knowledge: you get to release production systems that embody that learned knowledge).
I'm sorry if my argument was unclear, but I was attempting to say my best guess is that fair use in this case is untenable regardless of the interoperability argument, and thus also in cases where interoperability was more strongly attempted. Of course, there would be many individual factors involved in any other court case, and it's not like a jury in the Android case could set a precedent one way or another (although an appeal could), but even so.
There is this interesting claim in the readline homepage: http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html
"Readline is free software, distributed under the terms of the GNU General Public License, version 3. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license."
That's interesting, it does not say it must use GPL (which is what I expected, it seems a direct contradiction to the article we just read) and so libss being MIT seems fine. Nothing in libss source seems to include anything from readline, no header file, no copying portions of header file even, just some very small words in the dl loader like"readline", "add_history", "rl_forced_update_display", and so forth. I would hope that is fair use. I would say that Oracle though might have a problem though if can't study the source freely for their client. But it seems wrong in someway that they should have such a problem since they copied so little and so indirectly. To be safe, they should modify libss and distribute a version where DEFAULT_LIBPATH in their private source includes no traces to readline. It's sort of ironic though regarding the recent Oracle v. Google ruling, to be sure theyu really should also modify most editline function names to something like oracle_foo_0, oracle_foo_1, ... shouldn't they ;) Seriously, this is a very interesting question, it's a good one for a lawyer in fact.
"Readline is free software, distributed under the terms of the GNU General Public License, version 3. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license."
That's interesting, it does not say it must use GPL (which is what I expected, it seems a direct contradiction to the article we just read) and so libss being MIT seems fine. Nothing in libss source seems to include anything from readline, no header file, no copying portions of header file even, just some very small words in the dl loader like"readline", "add_history", "rl_forced_update_display", and so forth. I would hope that is fair use. I would say that Oracle though might have a problem though if can't study the source freely for their client. But it seems wrong in someway that they should have such a problem since they copied so little and so indirectly. To be safe, they should modify libss and distribute a version where DEFAULT_LIBPATH in their private source includes no traces to readline. It's sort of ironic though regarding the recent Oracle v. Google ruling, to be sure theyu really should also modify most editline function names to something like oracle_foo_0, oracle_foo_1, ... shouldn't they ;) Seriously, this is a very interesting question, it's a good one for a lawyer in fact.
There are now BSD versions of the library. This was not true for several years, after the license was picked.
Yea, this is an old article.
I wonder what changed? "Updated: $Date: 2014/04/12 12:39:52 $" Maybe someone could look in archive.org, it's blocked for me.
The CVS log of the page: http://web.cvs.savannah.gnu.org/viewvc/www/licenses/why-not-...
The only change of substance since at least 2001 (when they started using CVS) is the rename of "Library GPL" to "Lesser GPL" (the 2001 version had a notice that the rename had occurred, but the article had not been updated).
Most of the changes are adding additional translations, and minor markup changes (the most recent is "Remove empty <p> element.")
The only change of substance since at least 2001 (when they started using CVS) is the rename of "Library GPL" to "Lesser GPL" (the 2001 version had a notice that the rename had occurred, but the article had not been updated).
Most of the changes are adding additional translations, and minor markup changes (the most recent is "Remove empty <p> element.")
There was no distribution of GPLd code so I don't think there was a violation of the GPL.
On the other hand I could see the claim there was a violation with the proprietary app being at fault. They should have verified all of their dependencies not just the direct ones.
On the other hand I could see the claim there was a violation with the proprietary app being at fault. They should have verified all of their dependencies not just the direct ones.
The proprietary app in this example, has no idea whether they are dynamic linking with a version of libss that has the dlopen functionality (which is the case in the version of libss distributed with e2fsprogs), but there is also the version of libss distributed with Solaris SEAM and the MIT Kerberos v5 distribution which does not dlopen readline.
This is the problem of whether the GPL infects across dynamic linking. Yes, it is possible for GPL and proprietary code to be in the same process address space, without any knowledge of the owner of the proprietary address space. It was the user who decided to use a particular version of libss, not Solaris.
This is the problem of whether the GPL infects across dynamic linking. Yes, it is possible for GPL and proprietary code to be in the same process address space, without any knowledge of the owner of the proprietary address space. It was the user who decided to use a particular version of libss, not Solaris.
* It was the user who decided to use a particular version of libss, not Solaris.*
That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.
That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.
Sun shipped could which _could_ link dynamically to GPL code.
The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.
The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.
[deleted]
What's the difference between Mozilla supporting EME to maintain market relevance among proprietary competitors and the FSF licensing glibc as "Lesser GPL" to do the same?
> Proprietary software developers have the advantage of money; free software developers need to make advantages for each other.
This actually confuses 'libre' with 'gratis'.
This actually confuses 'libre' with 'gratis'.
I actually think it's a subtle admission that it's impossible to gain any significant amount of revenue by "selling" free software.
I love the open-source/libre philosophy but it's not viable for a business. I think the more pressing question is whether software even should be a business. Many think that there's a certain rift between users and developers that still exists today, and I have to agree.
1. Users push for increased ease-of-use 2. Developers implement more simple systems 3. Power users complain about the loss of features 4. Developers add back in missing features 5. All users complain about software being a convoluted mess
The programmer is now left at a disadvantage: he can either continue working with a codebase that's disorganized and inelegant, or he can start over from scratch. In a business environment, starting over from scratch would not be an economically viable situation, while continuing with the older codebase would be the wiser choice (even thought it may piss off users). Users are left disadvantaged; they can continue to use the older software versions but run the risk of poor security and an inferior interface.
With free/libre software this problem disappears, as a talented programmer with the user's interest can simply fork the older version and continue to implement a better interface and security updates while retaining a cleaner codebase. However, the endless stream of forks fragment software and hinder unified progress. Also, the original developer is more likely to abandon the software application due to lack of funds and interest.
It's a lose-lose situation. There is no one perfect development methodology. The open-source philosophy is more effective in the long run, but proprietary software is the only viable method to sustain a business. Open-source advocates will often point to Red Hat as a counter-example, but it's important to note Red Hat is the exception to the rule. It's also even more important to note that Red Hat isn't doing so hot these days, either.
Where the FSF falls down is in its inability to compromise. A number of companies have achieved success with a mixed closed/premium source model, such as JetBrains. While this again allows much more freedom than a standard proprietary setup, the FSF will always refuse to acknowledge any software with ANY proprietary bits in it.
They're now incredibly out of touch with Silicon Valley, and it isn't difficult to see why. They continue their militant and expressive attitude instead of expressing gratitude to those that push OSS forward.
Apart from GNU, the GPL and its many variants, the FSF is largely irrelevant.
It never had to be that way.
I love the open-source/libre philosophy but it's not viable for a business. I think the more pressing question is whether software even should be a business. Many think that there's a certain rift between users and developers that still exists today, and I have to agree.
1. Users push for increased ease-of-use 2. Developers implement more simple systems 3. Power users complain about the loss of features 4. Developers add back in missing features 5. All users complain about software being a convoluted mess
The programmer is now left at a disadvantage: he can either continue working with a codebase that's disorganized and inelegant, or he can start over from scratch. In a business environment, starting over from scratch would not be an economically viable situation, while continuing with the older codebase would be the wiser choice (even thought it may piss off users). Users are left disadvantaged; they can continue to use the older software versions but run the risk of poor security and an inferior interface.
With free/libre software this problem disappears, as a talented programmer with the user's interest can simply fork the older version and continue to implement a better interface and security updates while retaining a cleaner codebase. However, the endless stream of forks fragment software and hinder unified progress. Also, the original developer is more likely to abandon the software application due to lack of funds and interest.
It's a lose-lose situation. There is no one perfect development methodology. The open-source philosophy is more effective in the long run, but proprietary software is the only viable method to sustain a business. Open-source advocates will often point to Red Hat as a counter-example, but it's important to note Red Hat is the exception to the rule. It's also even more important to note that Red Hat isn't doing so hot these days, either.
Where the FSF falls down is in its inability to compromise. A number of companies have achieved success with a mixed closed/premium source model, such as JetBrains. While this again allows much more freedom than a standard proprietary setup, the FSF will always refuse to acknowledge any software with ANY proprietary bits in it.
They're now incredibly out of touch with Silicon Valley, and it isn't difficult to see why. They continue their militant and expressive attitude instead of expressing gratitude to those that push OSS forward.
Apart from GNU, the GPL and its many variants, the FSF is largely irrelevant.
It never had to be that way.
Where the FSF falls down is in its inability to compromise
They're an ideological foundation. There are already plenty of others who compromise in the name of pragmatism, and there's nothing wrong with that.
FSF represents a viewpoint that is constantly under threat from some of the world's richest corporations such as Apple. If they became the "Free And Also Not-So-Free (As Long As It's Useful) Software Foundation", they can just as well close shop.
They're now incredibly out of touch with Silicon Valley
Certainly this is a positive thing in the long run? There's much more to technology than just the Valley players' interests.
They're an ideological foundation. There are already plenty of others who compromise in the name of pragmatism, and there's nothing wrong with that.
FSF represents a viewpoint that is constantly under threat from some of the world's richest corporations such as Apple. If they became the "Free And Also Not-So-Free (As Long As It's Useful) Software Foundation", they can just as well close shop.
They're now incredibly out of touch with Silicon Valley
Certainly this is a positive thing in the long run? There's much more to technology than just the Valley players' interests.
My frustration doesn't stem from the FSF's stubbornness; my frustration stems from the fact that they don't realize how it's holding free software back. The EFF has been very successful at accomplishing their goals because they, unlike the FSF, understand diplomacy and relationships.
I can't really see how non-GPL free software has been held back. If anything, it's been successful beyond most people's dreams.
Most servers are powered by software under Apache and MIT licenses; companies pick what they want and mostly don't give back. The dominant operating system on personal devices is Android, which is free but nevertheless deeply tied with a corporation's interests and developed in secrecy using the same principles as proprietary software.
What would FSF gain by supporting that kind of software freedom, other than a reputation as nice guys? That model of freedom has already won, and from FSF's point of view, it's not much better than traditional closed software.
Most servers are powered by software under Apache and MIT licenses; companies pick what they want and mostly don't give back. The dominant operating system on personal devices is Android, which is free but nevertheless deeply tied with a corporation's interests and developed in secrecy using the same principles as proprietary software.
What would FSF gain by supporting that kind of software freedom, other than a reputation as nice guys? That model of freedom has already won, and from FSF's point of view, it's not much better than traditional closed software.
Imagine what it would be like if the FSF had been helping instead of fighting this type of open source development?
But isn't it precisely the FSF's "stubbornness" (their uncompromising defense of libre software) what results in the phenomenon you identify as not understanding diplomacy?
If the FSF compromises in order to be diplomatic, they'll have to compromise on the only thing they are adamant about: that software must be libre (and there's no such thing as "mostly libre" software). This would invalidate the FSF's mission, which is ideological and their only raison d'etre.
If the FSF compromises in order to be diplomatic, they'll have to compromise on the only thing they are adamant about: that software must be libre (and there's no such thing as "mostly libre" software). This would invalidate the FSF's mission, which is ideological and their only raison d'etre.
Do they have a reason to continue existing? If they didn't hew to their extreme position, would all open source software disappear? It's hard to say one way or another.
I think they do.
Open source software would probably not disappear, since it's largely successful (and extremely convenient even for companies who don't give anything back), but maybe libre software would. The FSF's concern is libre software, not open source software. I'd like libre software (as well as user rights and our freedom to tinker) to continue to exist and therefore I support the FSF's mission and their principled stance. I'm not as uncompromising as they are, but then again, my job is not advocacy.
I hate to sound paranoid, but I think libre software, user rights and the open internet are under attack, and we need to organize and defend those rights. This is an ideological issue orthogonal to any technical merit of open or closed source software. I'm glad the FSF exists as one of the groups on the side of users.
Open source software would probably not disappear, since it's largely successful (and extremely convenient even for companies who don't give anything back), but maybe libre software would. The FSF's concern is libre software, not open source software. I'd like libre software (as well as user rights and our freedom to tinker) to continue to exist and therefore I support the FSF's mission and their principled stance. I'm not as uncompromising as they are, but then again, my job is not advocacy.
I hate to sound paranoid, but I think libre software, user rights and the open internet are under attack, and we need to organize and defend those rights. This is an ideological issue orthogonal to any technical merit of open or closed source software. I'm glad the FSF exists as one of the groups on the side of users.
It's hard to sell free software as a product. It's easy to sell it as a service (by which I mean consulting and customization, not SaaS). It's true that this may not translate into a "significant amount of revenue" - it doesn't scale like printing off copies, but it can certainly pay the bills.
I don't use GPL libraries because of the tyrannical copy-left clause. If I want to GPL mine, then I'll make that choice. But I won't use a single library that'll force me to choose GPL—I'll just write/find a replacement. So go ahead, make your library GPL instead of LGPL/MIT/BSD/MPL/APL/ETC and it'll sit unused and ignored (for the most part).
I also really appreciate what morbius wrote in this same thread: https://news.ycombinator.com/item?id=7757677
I also really appreciate what morbius wrote in this same thread: https://news.ycombinator.com/item?id=7757677
Tyranny is a strong word for "please only use this free code in the ways that I have outlined".
It's Tyranny because the express goal of the GPL is to force all software to be free and open source. It's one thing to just say "my library has restrictions, please obey them", but the GPL is designed to try to infect as much of the software world as it possibly can, forcing via legal measures other software to catch its copyleft virus.
Given the analogy you are using, do I understand it correctly that software can "catch" GPL (as in being required to be released under the GPL, I suppose?) without a deliberate decision of its developers to include GPL licensed code into their codebase? Could you explain how that works?
Also, would you use the same language to describe typical proprietary licenses? After all, most of those would also prevent me from publishing any codebase incorporating any code I obtained under such a license as free software--or in your terminology, the codebase would be "infected" by the proprietary license which forces my software to also "catch a proprietary license"? I'm not quite sure I understand your analogy, though ...
Also, would you use the same language to describe typical proprietary licenses? After all, most of those would also prevent me from publishing any codebase incorporating any code I obtained under such a license as free software--or in your terminology, the codebase would be "infected" by the proprietary license which forces my software to also "catch a proprietary license"? I'm not quite sure I understand your analogy, though ...
>the express goal of the GPL is to force all software to be free
The GPL does not force software to be free. It is not viral. Please stop using such dishonest language. The GPL will only be a part of software project if you choose to use it. It doesn't invite itself in.
The GPL does not force software to be free. It is not viral. Please stop using such dishonest language. The GPL will only be a part of software project if you choose to use it. It doesn't invite itself in.
Because using coercion in the interest of "freedom" always works out so well.
What is your definition of "coercion" that you are using here?
The same sense that the FSF uses coercion when they describe participation in closed-source.
Where free in this case means free as in beer, not free to use as you please.
> tyrannical copy-left clause
Do you believe that proprietary software licenses are tyrannical as well?
Do you believe that proprietary software licenses are tyrannical as well?
Not really, most proprietary software licenses don't interfere with the ways in which I prefer to release software to clients.
Freedom is all about what you want to do, the problem is that GPL developers and developers who sell things to clients have different objectives for what they want to do. Likewise users of paid for software and users of GPL software have very different expectations of the software, GPL users tend to want to modify the code, and paid for software users want the software to work, but don't want to modify it.
So for a GPL developer GPL code is very free, for a non-GPL developer it's not very free.
Freedom is all about what you want to do, the problem is that GPL developers and developers who sell things to clients have different objectives for what they want to do. Likewise users of paid for software and users of GPL software have very different expectations of the software, GPL users tend to want to modify the code, and paid for software users want the software to work, but don't want to modify it.
So for a GPL developer GPL code is very free, for a non-GPL developer it's not very free.
Well, but using your needs as the defining criteria for freedom is not particularly universal, is it? If a customer of mine requires that I provide them with the ability to use and modify the system I build for them in any way they want, proprietary licenses are quite "tyrannical" (though I wouldn't really use that word), whereas GPL gives me the freedom to do what I want/need to do.
Which also seems to highlight a possible confusion on your part, that somehow "paid for software" is the opposite of "GPL software". When I sell software, customers tend to want to be able to modify it, or to have the ability to have others implement modifications for them. And that works both with proprietary code as well as with GPLed code: It's no problem at all to sell code under a proprietary license that allows modifications for own use, but it's also no problem at all to sell code under the GPL, which also allows modifications, and at the same time allows me to build on GPLed code.
Also, I don't think terms such as "GPL developer" make much sense. There just is code out there that you can use under different licenses, some of which are incompatible, and for a given project, you have to take care to select components that are compatible technically as well as legally, both between them and with the requirements of the project--and in particular, there isn't really anything all _that_ special about the GPL, as you cannot include proprietary code in a project when the license is not compatible with the customer's requirements either.
Which also seems to highlight a possible confusion on your part, that somehow "paid for software" is the opposite of "GPL software". When I sell software, customers tend to want to be able to modify it, or to have the ability to have others implement modifications for them. And that works both with proprietary code as well as with GPLed code: It's no problem at all to sell code under a proprietary license that allows modifications for own use, but it's also no problem at all to sell code under the GPL, which also allows modifications, and at the same time allows me to build on GPLed code.
Also, I don't think terms such as "GPL developer" make much sense. There just is code out there that you can use under different licenses, some of which are incompatible, and for a given project, you have to take care to select components that are compatible technically as well as legally, both between them and with the requirements of the project--and in particular, there isn't really anything all _that_ special about the GPL, as you cannot include proprietary code in a project when the license is not compatible with the customer's requirements either.
> Not really, most proprietary software licenses don't interfere with the ways in which I prefer to release software to clients.
So, you value developer freedom, but not user freedom. Copylefted software is "tyrannical" to you because it prevents you from using the software to build proprietary software.
>GPL users tend to want to modify the code
Well, some of us modify some of the source code. But I use most free software unmodified. Free software isn't merely to satisfy my penchant for hacking, but to give me the freedom to have control over my computing and share with my neighbors.
>paid for software
Free software is about freedom, not price. Software can be both free and "paid for".
So, you value developer freedom, but not user freedom. Copylefted software is "tyrannical" to you because it prevents you from using the software to build proprietary software.
>GPL users tend to want to modify the code
Well, some of us modify some of the source code. But I use most free software unmodified. Free software isn't merely to satisfy my penchant for hacking, but to give me the freedom to have control over my computing and share with my neighbors.
>paid for software
Free software is about freedom, not price. Software can be both free and "paid for".
Yes, copylefted software is "tyrannical" to you because it prevents you from using the software to build proprietary software, your powers reading comprehension astound me.
To continue with that line of thought...
For non-GPL developers, GPL code can even be more expensive than the cost of a proprietary library.
For non-GPL developers, GPL code can even be more expensive than the cost of a proprietary library.
I don't understand this viewpoint of supposed "tyranny".
I can understand why one would publish under MIT/BSD because they think that a developer is entitled to close source their software even if it builds onto free software.
But then if you support such freedom for the developer why isn't a developer entitled to publish under GPL because its their software and they can do whatever they want with it.
It seems like this viewpoint is implicitly saying that close sourcing the code is totally fine, but publishing the code under GPL isn't. That does not make sense to me.
I can understand why one would publish under MIT/BSD because they think that a developer is entitled to close source their software even if it builds onto free software.
But then if you support such freedom for the developer why isn't a developer entitled to publish under GPL because its their software and they can do whatever they want with it.
It seems like this viewpoint is implicitly saying that close sourcing the code is totally fine, but publishing the code under GPL isn't. That does not make sense to me.
There is no supposition about tyranny here. It used to be that the GPLv2 allowed use of libraries in applications so long as any adjustments to the library contributed back to the project. This was fair and reasonable, even when working on a commercial project. With GPLv3 you can no longer use GPL software, even as a library, in non-GPL software. [1] There's one exception, but it doesn't really apply to PHP libraries/applications (because there's no distinction between either in PHP; it's all source code). [2]
I never said that a developer isn't entitled to their choice of license. In fact, I fully support and encourage that. But choosing GPLv3 and then expecting people to use the library is a conflict of terms. I have equal rights to yours over how I license my code—at least until I pick the GPL. [2] So, attempting to dictate what license I use when writing my code by including a "viral" copy-left clause in your license is tyrannical and arrogant.
I do have to eat. So if my only choices are GPL licensed libraries and a project we can't release source for, all you GPL-only guys make me waste my time writing a proprietary library.
I absolutely resent the copy-left. And I won't ever use the GPL because I won't inflict such terms upon anyone, commercial or open-source users of my libraries or software.
[1]: https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
[2]: Bear in mind that my day-job is writing PHP code, and all distribution of libraries and software is in source form. The GPLv3 has special exceptions for statically linked languages loading the library dynamically, but in PHP the whole application is (arguably) in source form and always loaded dynamically.
I never said that a developer isn't entitled to their choice of license. In fact, I fully support and encourage that. But choosing GPLv3 and then expecting people to use the library is a conflict of terms. I have equal rights to yours over how I license my code—at least until I pick the GPL. [2] So, attempting to dictate what license I use when writing my code by including a "viral" copy-left clause in your license is tyrannical and arrogant.
I do have to eat. So if my only choices are GPL licensed libraries and a project we can't release source for, all you GPL-only guys make me waste my time writing a proprietary library.
I absolutely resent the copy-left. And I won't ever use the GPL because I won't inflict such terms upon anyone, commercial or open-source users of my libraries or software.
[1]: https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
[2]: Bear in mind that my day-job is writing PHP code, and all distribution of libraries and software is in source form. The GPLv3 has special exceptions for statically linked languages loading the library dynamically, but in PHP the whole application is (arguably) in source form and always loaded dynamically.
This is an incorrect understanding of GPLv2. From the GPLv2:
"This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License."
"This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License."
The problem, I think, with the GPL community is that they refuse to accept that almost all software developers make a living by working for a company, and feel that it is unjust to refuse their libraries to others who do the same.
And, because their software is open source, someone will inevitably create a better competing library based on the ideas behind the GPL one. That new library? Apache license.
And, because their software is open source, someone will inevitably create a better competing library based on the ideas behind the GPL one. That new library? Apache license.
While it's true that GPL is often incompatible with specific strategies chosen by companies (and often those are the most effective strategies in the current environment, and maybe in any reasonable environment), there is still a tremendous gulf between GPL - which permits commercial uses that abide by its restrictions - and anything with a non-commercial clause.
Not that this entirely undermines your point, just promoting deeper awareness/understanding of the issues.
Not that this entirely undermines your point, just promoting deeper awareness/understanding of the issues.
+1 that is a good point: for many of us, the GPL is much less restrictive than source code with a no commercial use license.
I have mostly rolled over on the issue of license and usually dual GPL/Apache license my own projects.
I have mostly rolled over on the issue of license and usually dual GPL/Apache license my own projects.
> And, because their software is open source, someone will inevitably create a better competing library based on the ideas behind the GPL one.
Or, in some cases, just buy a proprietary license from the authors? That is often an option (not always but sometimes, we are doing it).
Surely if these software developers are making a living selling software, presumably by licensing it and so on, they understand and are very familiar with how that works?
> That new library? Apache license.
Because they will just keep it in house and not release it. Which...is exactly what GPL is designed to discourage. Some benevolent companies like Google might but not others are not.
At least I don't see a problem with authors choosing a license they like. I will not put them down or criticize for choosing GPL, there are good reasons to choose GPL sometimes.
Or, in some cases, just buy a proprietary license from the authors? That is often an option (not always but sometimes, we are doing it).
Surely if these software developers are making a living selling software, presumably by licensing it and so on, they understand and are very familiar with how that works?
> That new library? Apache license.
Because they will just keep it in house and not release it. Which...is exactly what GPL is designed to discourage. Some benevolent companies like Google might but not others are not.
At least I don't see a problem with authors choosing a license they like. I will not put them down or criticize for choosing GPL, there are good reasons to choose GPL sometimes.
I'm having trouble parsing your first sentence. There's a problem of refusing to be accepted that almost all, and unjust to refuse to others that do the same. One or both of us are making a sign error.
Are you saying that the "GPL community" don't want software developers that work for a company to use their libraries?
Are you saying that the "GPL community" don't want software developers that work for a company to use their libraries?
GPL community definitely wants commercial software companies to use their software since they get even more GPL code as a result.
However, most commercial software companies don't want to use GPL code because they don't want to GPL their entire codebase.
So if by want you mean the idea then yes, but if by want you mean, will actually entice to use, then no.
However, most commercial software companies don't want to use GPL code because they don't want to GPL their entire codebase.
So if by want you mean the idea then yes, but if by want you mean, will actually entice to use, then no.
More succinct point:
I can't use GPL software libraries at work. I have no interest in developing under GPL because it would expose others to the same problem.
There are ways the GPL community could attempt to incorporate individuals like me, but to be honest, I much prefer a world where anyone can use any open source code however they wish.
There are ways the GPL community could attempt to incorporate individuals like me, but to be honest, I much prefer a world where anyone can use any open source code however they wish.
Have you considered that the problem could be that your company is writing proprietary software?
Do you for the same reason also have no interest in developing under proprietary licenses? After all, that also exposes others to the problem that they cannot just use your code.
> Are you saying that the "GPL community" don't want software developers that work for a company to use their libraries?
I am not the person you responded to, but that actually sounds about right for the GPL community.
As far as I can tell, GPL predicated upon the idea that nobody should be able to charge money for software. It's not saying that there should be free software, it's saying all software should be free (where "free" in this case also means open source).
I am not the person you responded to, but that actually sounds about right for the GPL community.
As far as I can tell, GPL predicated upon the idea that nobody should be able to charge money for software. It's not saying that there should be free software, it's saying all software should be free (where "free" in this case also means open source).
stcredzero already more or less said it, but IMO it needs to be said even more clearly:
You could not be more wrong.
Free Software as per the FSF, and thus the GPL, is all about the freedoms of the user. It's not just about "open source", and in particular, it's NOT ABOUT MONEY AT ALL. It is perfectly fine to sell GPL software, be it your own or be it software written by someone else, both legally and as far as the FSF's philosophy is concerned, there is absolutely nothing wrong with charging for (GPL) software.
You might also want to have a look at the FSF's GPL FAQ, which clears up many such misconceptions:
http://www.gnu.org/licenses/gpl-faq.html
You could not be more wrong.
Free Software as per the FSF, and thus the GPL, is all about the freedoms of the user. It's not just about "open source", and in particular, it's NOT ABOUT MONEY AT ALL. It is perfectly fine to sell GPL software, be it your own or be it software written by someone else, both legally and as far as the FSF's philosophy is concerned, there is absolutely nothing wrong with charging for (GPL) software.
You might also want to have a look at the FSF's GPL FAQ, which clears up many such misconceptions:
http://www.gnu.org/licenses/gpl-faq.html
If there's nothing wrong with it, then why the AGPL?
Pretty much every time someone figures out how to make money with GPL software they create a new license that makes that impossible.
Pretty much every time someone figures out how to make money with GPL software they create a new license that makes that impossible.
Because, as I wrote, free software is about protecting the freedoms of the user, who in the case of hosted GPL software has very little rights, while the AGPL protects the user's rights to inspect, modify, and share the software they are using.
Also, it's obviously not true that they create licenses that make it impossible to make money - it is perfectly fine to make money by offering hosting of AGPL software, it's just not acceptable to lock users in to your hosting offering (as far as the FSF is concerned/if you are using AGPL software), as that limits the user's freedom.
Now, you are right, of course, that this prevents you from making money by locking in your users, for example. But first of all, that's obviously not the same as making it impossible to make money, and secondly, the intention behind it is not to prevent anyone from making money, which is also why your observation is just flat-out wrong that they make a new license "every time someone figures out how to make money with GPL software" - really, I can barely believe that you really think that, given just how many people and companies are making money with GPL software, and have been doing so for many years without anyone trying to change anything about that: Manufacturers selling home routers (GPLed Linux kernel inside), companies hosting their file servers on Samba (GPLv3) as infrastructure for their business, software development companies and consultants offering the development of customisations of GPLed software, hosting companies offering hosting of GPLed and AGPLed software, ... they are all making money with GPL software, and the FSF and RMS are happy about it - were you really not aware that all of that is happening?
Now, user lockin is something that the FSF would consider unethical, and as such it indeed is intentional that you should not be able to do that with (A)GPLed software, because they consider the freedom of the user in this case to be more important than your interest in making money from them being locked in (that's a bit like how society in general nowadays considers the right of humans not to be owned to be more important than the interest of slave owners to make money off their slaves' work--that does not mean, though, that the abolishment of slavery had anything to do with preventing anyone from making money, it was about human liberty, and that you couldn't make money using slave labor anymore was just a side effect and not the primary goal, and, after all, you even still could hire the former slaves to work for your business, you just could not own them anymore).
There might also be methods of making money with software that might be perfectly ethical, even by the FSF's standard, and which still are prevented by the GPL. Those cases tend to be unfortunate side effects of the fact that the GPL is a general-purpose license that has to be written to be applicable in as wide a range of cases as possible.
You might also want to read the FSF's definition of free software (or at least the first few paragraphs if the whole thing is too long for your taste):
http://www.gnu.org/philosophy/free-sw.html
Also, I just noticed this more verbose explanation of how and why selling free software is perfectly fine:
http://www.gnu.org/philosophy/selling.html
Also, it's obviously not true that they create licenses that make it impossible to make money - it is perfectly fine to make money by offering hosting of AGPL software, it's just not acceptable to lock users in to your hosting offering (as far as the FSF is concerned/if you are using AGPL software), as that limits the user's freedom.
Now, you are right, of course, that this prevents you from making money by locking in your users, for example. But first of all, that's obviously not the same as making it impossible to make money, and secondly, the intention behind it is not to prevent anyone from making money, which is also why your observation is just flat-out wrong that they make a new license "every time someone figures out how to make money with GPL software" - really, I can barely believe that you really think that, given just how many people and companies are making money with GPL software, and have been doing so for many years without anyone trying to change anything about that: Manufacturers selling home routers (GPLed Linux kernel inside), companies hosting their file servers on Samba (GPLv3) as infrastructure for their business, software development companies and consultants offering the development of customisations of GPLed software, hosting companies offering hosting of GPLed and AGPLed software, ... they are all making money with GPL software, and the FSF and RMS are happy about it - were you really not aware that all of that is happening?
Now, user lockin is something that the FSF would consider unethical, and as such it indeed is intentional that you should not be able to do that with (A)GPLed software, because they consider the freedom of the user in this case to be more important than your interest in making money from them being locked in (that's a bit like how society in general nowadays considers the right of humans not to be owned to be more important than the interest of slave owners to make money off their slaves' work--that does not mean, though, that the abolishment of slavery had anything to do with preventing anyone from making money, it was about human liberty, and that you couldn't make money using slave labor anymore was just a side effect and not the primary goal, and, after all, you even still could hire the former slaves to work for your business, you just could not own them anymore).
There might also be methods of making money with software that might be perfectly ethical, even by the FSF's standard, and which still are prevented by the GPL. Those cases tend to be unfortunate side effects of the fact that the GPL is a general-purpose license that has to be written to be applicable in as wide a range of cases as possible.
You might also want to read the FSF's definition of free software (or at least the first few paragraphs if the whole thing is too long for your taste):
http://www.gnu.org/philosophy/free-sw.html
Also, I just noticed this more verbose explanation of how and why selling free software is perfectly fine:
http://www.gnu.org/philosophy/selling.html
Entirely incorrect. It's based on the idea that everyone should be able to read and modify everything. Free as in speech, not free as in beer.
This. There is the ivory tower and the real world, and in the real world, the license can't be GPL.
Linux (sorry, GNU/Linux) is ample evidence to the contrary.
He was talking about libraries, not platforms. Sorry I should have made that clear.
No it's not. Linux is useful and used all of the time in proprietary systems because there are lots of useful classes of things you can do with linux that aren't derivative works.
There are no useful things you can do with a library besides link it.
There are no useful things you can do with a library besides link it.
Other than use it in Linux and GPLed software, software which offers lots of useful classes of things that you can do with them that aren't derivative works.
The title would be perfect for an article arguing for a non-copyleft license instead of the LGPL. Some who create projects mistakenly believe that if they use the LGPL or some other copyleft license that most of the problems with the GPL go away. I think Firefox has lost some developers to Chromium because of Chromium's simpler license. The EPL is also frustrating to some who would like to use Clojure (Scala is under a simpler license). I tried writing such an article: https://gist.github.com/benatkin/98e28b329842f021e6d3
Good points in this article. Note as well that the LGPL requires you to permit reverse-engineering of your proprietary code. There are good reasons for this, but it's unrealistic in a lot of organizations.
A lot of developers (and a lot of lawyers!) rely on the rule of thumb that you're fine under the LGPL as you don't modify and don't statically link. That's a fine rule of thumb, but that's all it is.
A lot of developers (and a lot of lawyers!) rely on the rule of thumb that you're fine under the LGPL as you don't modify and don't statically link. That's a fine rule of thumb, but that's all it is.
It took some time for me wrap my brain the restrictions around the EPL while I was picking up clojure, but I don't understand how EPL would be frustrating to other developers or businesses. Could you elaborate?
As I understand it, as long as you use a library according to its stated API, you can do whatever you want with it and license the entire product under any license you choose. [1]
[1] - https://www.eclipse.org/legal/eplfaq.php#EXAMPLE
As I understand it, as long as you use a library according to its stated API, you can do whatever you want with it and license the entire product under any license you choose. [1]
[1] - https://www.eclipse.org/legal/eplfaq.php#EXAMPLE
I thought one of the main reasons for the LGPL was to attract more people to use and contribute to your library, whether open source or proprietary; with the added advantage that developers efforts were not being wasted with needless duplication.
This approach seems to seek to create a much stronger 'us' and 'them' mindset which can only alienate a large number potential contributors.
This approach seems to seek to create a much stronger 'us' and 'them' mindset which can only alienate a large number potential contributors.
One could also look at it as seeking to avoid needless duplication even more: By trying to give free software an advantage by being able to make use of GPLed libraries, or possibly to motivate people to release their new software under GPL because that allows them to make use of GPLed libraries, you might be able to avoid future work on the competing proprietary silos, instead focusing resources that are used for developing the particular kind of software on the one commonly developed free software solution, thus creating a much stronger 'us all together' instead of any kind of 'us' vs 'them'.
I'm really happy there are people fighting for a world like this. It doesn't matter that they can't get 100% of the market, just by advocating for a better alternative makes the whole thing better.
Pragmatically, the FSF should be advocating for the LGPL over BSD or Apache, since GPL over LGPL is already a lost battle.
https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s... https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s...
So riddle me this. The ss library is under an MIT-style copyright license. Suppose you have a proprietary program (Say, the Solaris kerberos v5 administration daemon client, to take a not-so-hypothetical example). Now suppose it dynamic links against a version of libss that might dlopen readline, or might dlopen editline, and if neither is available, libss will fall back to fgets. Now suppose Solaris distributes their kadmin program independent of the version of libss distributed as part of e2fsprogs. Quick! Is there a copyright violation, and if so, who committed it?