8 ms·

As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it mysel

As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it myself. However, using the GPL for a library seems like a bad idea, because there are a lot of people, especially at companies, which won't touch the GPL. So if you license a library GPL and it's useful someone is just going to come along and reimplement it with a more liberal license. And such a waste of resources is sad to contemplate. The ideal of the GPL was that it would force other projects to switch to GPL, but it doesn't seem to happen too much in practice because the modern world has an abundance of alternative software for any task. Think long term: chances are someone in the next 50 years will be annoyed enough to reimplement whatever you're doing.

robert_foss 11y ago
In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better. The author seems to have the same idea, and is considering re-licensing to MIT later on. I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.
- jobigoud 11y ago
  > If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. Obviously the issue is not about publishing changes to the library, it's about publishing the rest of the source which just uses the library as a building block.
  - robert_foss 11y ago
    You're free to link to compiled GPL libraries. There is nothing forcing you to change the license of your product unless you intend to integrate the sourcecode.
    - kazinator 11y ago
      I also believe this, but it is not an established fact. The GPL does prohibit it, and so whether that is actually enforceable has to be tested in a court of law. So you are in fact not free to do this, if you have a boss above you who cares dearly about the company steering clear of hot water. I'd be willing to testify as a technical expert in a court of law that the GPL cannot reasonably rule out dynamic linking; that dynamic linking to a program is a form of use (like invoking a command line and passing it arguments) and not integration. The proof is that dynamically linked components can be replaced by clean-room substitutes which work exactly alike, or at least well enough so that the main software can function. For example, a program can be shipped with a stub library which behaves like GNU Readline (but perhaps doesn't have all its features). The users themselves can replace that with a GNU Readline library. Thus, the program's vendor isn't even redistributing the GPL'ed component. They can provide it as a separate download or whatever. However, if they were to include a GNU Readline binary for the convenience of the users, then the program supposedly infringes. This is clearly nonsense.
      - belorn 11y ago
        The problem with that line of thought is that the courts don't care if its use or integration, but if the resulting work depends on someone else work. The word used in copyright law is transform, adapt, recast, and such changes requires additional copyright permission. For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy. Components can not be cleanly viewed as separate when dealing with copyright. You can also turn this around and ask if its legal to use process call within a other program without invoking the need for additional permissions. FSF view that it should be legal, but it has never been tested. By now however an industry standard has formed around the FSF guidelines and most courts would just look at it when deciding. This is what commonly happen when no one go to court to find out what the rules actually should be.
- pierrebai 11y ago
  It's not about being apologetic or anti-freedom, it's all about the reality of software. If it gets reimplemented with a more libral license, then the more liberal version will dominate. If there is any incompatibility whatsoever, the more liberally licensed version will win. Look at gcc for an example: it has gcc-specific extensions and there are other compilers with more open license. These compilers are gaining the upper-hand. Making it GPL instead of LGPL is just a bad political choice. Especially for something which need wide adoption to even live. Image formats can only exist if they get adopted.
  - robert_foss 11y ago
    GCC has been around for 30 years. Only in the past 5 years has LLVM been around, and LLVM really is the only compiler to ever have matched GCC. The value GCC has provided to the software community in large is immense. Do you think it would have survived this far if it had been MIT-licensed all along? To support this argument, I'd like you to think about all the other compilers that never had a 10th of the traction of GCC and how they were licensed. I do agree that the LGPL is a reasonable choice for prototype implementation of a specification. I don't think using the GPL is a huge loss compared to LGPL for a prototype. I'd like to ask a non-rhetorical question; On an individual basis is it not better if all software was available as sourcecode? And if so, does that not mean the choice of not-publishing sourcecode is done for other reasons than what's best for the individual(s)?
    - kazinator 11y ago
      Unfortunately, a sample of one isn't statistically significant. That a GPL-licensed compiler suite is overwhelmingly popular rather than an MIT- or BSD-licensed one could be little more than a historic accident. BSD Unixes are BSD-licensed and have "survived this far". The SBCL implementation of Common Lisp is licensed as a "a mixture of BSD-style .. and public domain" [source: http://www.sbcl.org/history.html http://www.sbcl.org/history.html] It is a popular CL implementation. GNU Common Lisp [https://en.wikipedia.org/wiki/GNU_Common_Lisp https://en.wikipedia.org/wiki/GNU_Common_Lisp], the GNU Project's Common Lisp implementation, is LGPL-ed and has been a floundering project. The choice of license cannot be the determiner of what propels a project to the forefront of popularity in its class, because ... there are many more projects than licenses. https://en.wikipedia.org/wiki/Pigeonhole_principle https://en.wikipedia.org/wiki/Pigeonhole_principle
bdisraeli 11y ago
If companies don't want to use code licensed under the GPL, they're probably welcome to pay the original the author for a separate license.
- anon1385 11y ago
  Is there any evidence that the author will sell commercial licences? Other comments are describing him as a strong proponent of free software, so it seems very unlikely that he is interested in selling proprietary licences.
- kazinator 11y ago
  But that unfortunately erodes the free-as-in-beer advantage, since in this situation the software is effectively proprietary, and competes with proprietary code on an equal footing: bang for the buck. "If we're going to pay to license freeware code as proprietary, let's look at all proprietary alternatives."
jwr 11y ago
> there are a lot of people, especially at companies, which won't touch the GPL Exactly. And for reasons which not everyone is aware of, for example anti-patent clauses. What people classify as "GPL-hate" is often a very pragmatic approach. I've seen this a number of times: companies have nothing against sharing improvements to the code, but do have a problem with a) having to share everything they wrote and b) anti-patent clauses which are landmines. And at companies I worked with, (b) was actually the bigger issue, especially if you build and distribute physical devices with software.

robert_foss 11y ago

In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better. The author seems to have the same idea, and is considering re-licensing to MIT later on. I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.

jobigoud 11y ago
> If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. Obviously the issue is not about publishing changes to the library, it's about publishing the rest of the source which just uses the library as a building block.
- robert_foss 11y ago
  You're free to link to compiled GPL libraries. There is nothing forcing you to change the license of your product unless you intend to integrate the sourcecode.
  - kazinator 11y ago
    I also believe this, but it is not an established fact. The GPL does prohibit it, and so whether that is actually enforceable has to be tested in a court of law. So you are in fact not free to do this, if you have a boss above you who cares dearly about the company steering clear of hot water. I'd be willing to testify as a technical expert in a court of law that the GPL cannot reasonably rule out dynamic linking; that dynamic linking to a program is a form of use (like invoking a command line and passing it arguments) and not integration. The proof is that dynamically linked components can be replaced by clean-room substitutes which work exactly alike, or at least well enough so that the main software can function. For example, a program can be shipped with a stub library which behaves like GNU Readline (but perhaps doesn't have all its features). The users themselves can replace that with a GNU Readline library. Thus, the program's vendor isn't even redistributing the GPL'ed component. They can provide it as a separate download or whatever. However, if they were to include a GNU Readline binary for the convenience of the users, then the program supposedly infringes. This is clearly nonsense.
    - belorn 11y ago
      The problem with that line of thought is that the courts don't care if its use or integration, but if the resulting work depends on someone else work. The word used in copyright law is transform, adapt, recast, and such changes requires additional copyright permission. For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy. Components can not be cleanly viewed as separate when dealing with copyright. You can also turn this around and ask if its legal to use process call within a other program without invoking the need for additional permissions. FSF view that it should be legal, but it has never been tested. By now however an industry standard has formed around the FSF guidelines and most courts would just look at it when deciding. This is what commonly happen when no one go to court to find out what the rules actually should be.
pierrebai 11y ago
It's not about being apologetic or anti-freedom, it's all about the reality of software. If it gets reimplemented with a more libral license, then the more liberal version will dominate. If there is any incompatibility whatsoever, the more liberally licensed version will win. Look at gcc for an example: it has gcc-specific extensions and there are other compilers with more open license. These compilers are gaining the upper-hand. Making it GPL instead of LGPL is just a bad political choice. Especially for something which need wide adoption to even live. Image formats can only exist if they get adopted.
- robert_foss 11y ago
  GCC has been around for 30 years. Only in the past 5 years has LLVM been around, and LLVM really is the only compiler to ever have matched GCC. The value GCC has provided to the software community in large is immense. Do you think it would have survived this far if it had been MIT-licensed all along? To support this argument, I'd like you to think about all the other compilers that never had a 10th of the traction of GCC and how they were licensed. I do agree that the LGPL is a reasonable choice for prototype implementation of a specification. I don't think using the GPL is a huge loss compared to LGPL for a prototype. I'd like to ask a non-rhetorical question; On an individual basis is it not better if all software was available as sourcecode? And if so, does that not mean the choice of not-publishing sourcecode is done for other reasons than what's best for the individual(s)?
  - kazinator 11y ago
    Unfortunately, a sample of one isn't statistically significant. That a GPL-licensed compiler suite is overwhelmingly popular rather than an MIT- or BSD-licensed one could be little more than a historic accident. BSD Unixes are BSD-licensed and have "survived this far". The SBCL implementation of Common Lisp is licensed as a "a mixture of BSD-style .. and public domain" [source: http://www.sbcl.org/history.html http://www.sbcl.org/history.html] It is a popular CL implementation. GNU Common Lisp [https://en.wikipedia.org/wiki/GNU_Common_Lisp https://en.wikipedia.org/wiki/GNU_Common_Lisp], the GNU Project's Common Lisp implementation, is LGPL-ed and has been a floundering project. The choice of license cannot be the determiner of what propels a project to the forefront of popularity in its class, because ... there are many more projects than licenses. https://en.wikipedia.org/wiki/Pigeonhole_principle https://en.wikipedia.org/wiki/Pigeonhole_principle

bdisraeli 11y ago

If companies don't want to use code licensed under the GPL, they're probably welcome to pay the original the author for a separate license.

anon1385 11y ago
Is there any evidence that the author will sell commercial licences? Other comments are describing him as a strong proponent of free software, so it seems very unlikely that he is interested in selling proprietary licences.
kazinator 11y ago
But that unfortunately erodes the free-as-in-beer advantage, since in this situation the software is effectively proprietary, and competes with proprietary code on an equal footing: bang for the buck. "If we're going to pay to license freeware code as proprietary, let's look at all proprietary alternatives."

jwr 11y ago

> there are a lot of people, especially at companies, which won't touch the GPL Exactly. And for reasons which not everyone is aware of, for example anti-patent clauses. What people classify as "GPL-hate" is often a very pragmatic approach. I've seen this a number of times: companies have nothing against sharing improvements to the code, but do have a problem with a) having to share everything they wrote and b) anti-patent clauses which are landmines. And at companies I worked with, (b) was actually the bigger issue, especially if you build and distribute physical devices with software.