4 ms·

GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your

GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your mind, it's a nonstarter. NPM or Nuget under more restrictive license regimes would never get off the ground.

quadrangle 8y ago
The hyperbole in this comment is unwarranted. Furthermore, the GPL isn't even developer-focused. It's downstream, end-user focused. There's a reason many of the most prominent free/libre/open programs are GPL: GIMP, Audacity, Linux kernel, so many others… GPL for developer-focused libraries and tools etc. is where the tension comes in because so many developers want to benefit from the open resources but not pass on the freedoms downstream.
- megaman22 8y ago
  Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL. If it's MIT or Apache or MSPL, party on. under most CyA lawyer regimes.
  - abritinthebay 8y ago
    Which is why LGPL exists.
    - megaman22 8y ago
      LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.
      - rectang 8y ago
        The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2. This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.
      - dfox 8y ago
        It is problematic even in C(++) because of header files. This is why GNU libstdc++ and similar gcc-related libraries are not LGPL.
      - belorn 8y ago
        Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games. The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice". The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.
        megaman22 8y ago
        Thank you, that's probably the best explanation I've seen of the distinction. Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.
        belorn 8y ago
        It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory. Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.
  - ecthiender 8y ago
    Your comment exactly misses the point of GPL! If I, as an upstream developer, license my library in GPL, it is exactly because I don't want any random developer to use my library and don't pass on the same freedom to end users. I intentionally want anyone using my library to be in the same freedom sphere (for lack of a better word). If you think this as problematic/cancerous then it's a pity. This license was designed to retain freedom of software users.
  - badsectoracula 8y ago
    What is the problem with releasing your project under the GPL?
  - quadrangle 8y ago
    Right, and as I said in my comment, the GPL isn't for developers per se, it's for the freedom of end-users. That's THE point.
scbrg 8y ago
How would a GPL licensed NPM affect anything? Are you in the habit of including NPM in your software and shipping a closed source version of it to paying customers? Is this a common way of using NPM?
badsectoracula 8y ago
> Unless idealogical purity trumps practicality in your mind The ideology comes from very practical concerns about users being able to know and control what their computers are actually doing.

quadrangle 8y ago

The hyperbole in this comment is unwarranted. Furthermore, the GPL isn't even developer-focused. It's downstream, end-user focused. There's a reason many of the most prominent free/libre/open programs are GPL: GIMP, Audacity, Linux kernel, so many others… GPL for developer-focused libraries and tools etc. is where the tension comes in because so many developers want to benefit from the open resources but not pass on the freedoms downstream.

megaman22 8y ago
Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL. If it's MIT or Apache or MSPL, party on. under most CyA lawyer regimes.
- abritinthebay 8y ago
  Which is why LGPL exists.
  - megaman22 8y ago
    LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.
    - rectang 8y ago
      The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2. This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.
    - dfox 8y ago
      It is problematic even in C(++) because of header files. This is why GNU libstdc++ and similar gcc-related libraries are not LGPL.
    - belorn 8y ago
      Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games. The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice". The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.
      - megaman22 8y ago
        Thank you, that's probably the best explanation I've seen of the distinction. Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.
        belorn 8y ago
        It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory. Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.
- ecthiender 8y ago
  Your comment exactly misses the point of GPL! If I, as an upstream developer, license my library in GPL, it is exactly because I don't want any random developer to use my library and don't pass on the same freedom to end users. I intentionally want anyone using my library to be in the same freedom sphere (for lack of a better word). If you think this as problematic/cancerous then it's a pity. This license was designed to retain freedom of software users.
- badsectoracula 8y ago
  What is the problem with releasing your project under the GPL?
- quadrangle 8y ago
  Right, and as I said in my comment, the GPL isn't for developers per se, it's for the freedom of end-users. That's THE point.

scbrg 8y ago

How would a GPL licensed NPM affect anything? Are you in the habit of including NPM in your software and shipping a closed source version of it to paying customers? Is this a common way of using NPM?

badsectoracula 8y ago

> Unless idealogical purity trumps practicality in your mind The ideology comes from very practical concerns about users being able to know and control what their computers are actually doing.