3 ms·

The GPL does not have a terrible reputation. It does, however, have a vocal group of a corporate sponsored detractors that are trying to destroy it. Lots and

The GPL does not have a terrible reputation. It does, however, have a vocal group of a corporate sponsored detractors that are trying to destroy it. Lots and lots of people are thankful for the GPL, myself included.

ubernostrum 10y ago
Speaking as a long-time contributor to and maintainer of permissive/BSD software: the thing about the GPL family which drives me away is partly philosophical disagreement, but mostly uncertainty. You can if you like say this is just the "U" in "FUD", but there's truth here. For example: the FSF's stance on certain provisions of the GPL, like the ones on linking, is as far as I know completely untested in court and at odds with what appear to be both established legal and common-sense/intuitive notions of what constitutes a derivative work. And I'm not speaking from inexperience there: the Django project had to go many rounds on this because the maintained MySQL driver modules for Python are all GPL. Does this end up GPL'ing Django since it supports MySQL as an option and, thanks to the nature of Python's import system, will share address space with a GPL'd module if you use MySQL as your database? Or does the fact that it's an end-user choice and Django is simply shipping code to normalize API access to any of multiple drivers on multiple DB engines (leaning heavily on PEP 249, which itself is a normalized API for Python DB drivers to expose) avoid that? Nobody seems to be able to give a clear answer, because there is no clear answer, legally, on when the GPL's derivative-works clause is invoked or even if the GPL's derivative-works clause is legally sensible.
- belorn 10y ago
  The linking aspect is only a line in the sand where fsf will enforce the license, and is not part of the license text. To my knowledge it comes from the idea that binaries with linked libraries will generally not work without those libraries and that that dependency is a strong indicator that we are dealing with a single work rather than multiple independent and separate works. In contrast to uncertainty, I think we can be quite certain that django works without mysql (I personally run several sites with postgresql). Modules for django would likely not work without django, so they are likely derivative of django and not the other way around. I also vaguely recall fsf stating that they don't consider the linking guidelines to be that relevant for software written in languages without linking, which would include python programs. Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software?
  - ubernostrum 10y ago
    Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software? My problem is that the FSF's opinion on what constitutes a derivative work is horribly broad, and has never to my knowledge been tested in court. So despite all the reasonable intuitive opinions in the world, who knows?

ubernostrum 10y ago

Speaking as a long-time contributor to and maintainer of permissive/BSD software: the thing about the GPL family which drives me away is partly philosophical disagreement, but mostly uncertainty. You can if you like say this is just the "U" in "FUD", but there's truth here. For example: the FSF's stance on certain provisions of the GPL, like the ones on linking, is as far as I know completely untested in court and at odds with what appear to be both established legal and common-sense/intuitive notions of what constitutes a derivative work. And I'm not speaking from inexperience there: the Django project had to go many rounds on this because the maintained MySQL driver modules for Python are all GPL. Does this end up GPL'ing Django since it supports MySQL as an option and, thanks to the nature of Python's import system, will share address space with a GPL'd module if you use MySQL as your database? Or does the fact that it's an end-user choice and Django is simply shipping code to normalize API access to any of multiple drivers on multiple DB engines (leaning heavily on PEP 249, which itself is a normalized API for Python DB drivers to expose) avoid that? Nobody seems to be able to give a clear answer, because there is no clear answer, legally, on when the GPL's derivative-works clause is invoked or even if the GPL's derivative-works clause is legally sensible.

belorn 10y ago
The linking aspect is only a line in the sand where fsf will enforce the license, and is not part of the license text. To my knowledge it comes from the idea that binaries with linked libraries will generally not work without those libraries and that that dependency is a strong indicator that we are dealing with a single work rather than multiple independent and separate works. In contrast to uncertainty, I think we can be quite certain that django works without mysql (I personally run several sites with postgresql). Modules for django would likely not work without django, so they are likely derivative of django and not the other way around. I also vaguely recall fsf stating that they don't consider the linking guidelines to be that relevant for software written in languages without linking, which would include python programs. Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software?
- ubernostrum 10y ago
  Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software? My problem is that the FSF's opinion on what constitutes a derivative work is horribly broad, and has never to my knowledge been tested in court. So despite all the reasonable intuitive opinions in the world, who knows?