It's got a lot of great ideas and discussions of philosophical underpinings, but I really think they're approaching the GPL through the worst-possible lens. The point of the GPL has nothing about...
It's got a lot of great ideas and discussions of philosophical underpinings, but I really think they're approaching the GPL through the worst-possible lens.
It’s hard to stop a spiral of aggrievement once you’ve chosen to look at open source development this way. It’s the way of Stallman and the GPL license. Walking around with the scowl that someone might take your software, and do things with it you wouldn’t like (such as extending it without sharing those extensions).
The point of the GPL has nothing about protecting "my precious creation." It doesn't require you to push your changes upstream, or even host it on your webservers. An example is Kenwood stereo units. They have no requirement to provide their GPL software modifications to the public at large, or even all their users. Merely their users who request it. Here is the form
While the GPL does leverage property law to give it power, it very much anti-property. It is a CVE severity 10 exploit of property law, which enshrines a bill of rights for software users. In lay terms it really says "Your users have just as much right to use your modifications as you do mine." It leverages property law to prevent the creation of property, only creation of more commons. It's just enforced public domain, a wall of guards to prevent the lords from conqouring it and dividing it amongest themselves. Why else would you see giant swarms of corporations trying to shut it down in court, rather than just not using GPL software? There's the BSDs if you want to go that route, as Sony and Apple (and countless others) have. The big tech companies want to patch the legal system against the GPL.
Look at how the regular public domain has been crippled by these gigantic lengths of copyright extensions, and how much of our culture since the 1920's is being lost to the sands of time due to it. A substantial bit of Disney's empire was built by copying a chunk of this commons, declaring that copy theirs, and then lobbying to avoid returning it back as required by law.
Pirate sites now have the most comprehensive collections of movies and films to date, most of which would certainly be lost in 30+ years, long after it has ceased being profitable to sell it. They distribute in post-scarcity fashion, against the laws of the land.
Sure, the MIT and BSD licenses could be considered more post-scarcity philosophically. But the GPL is more post-scarcity in practice because we still live in a world which is manufacturing artificial scarcity.
Given that we now have 3d printers and DNA printers, once the GPL has reached into those schematics, you've burst open gigantic other swaths of property being dismantled to the commons.
Actually I think it's more common for businesses to either not use GPL software or to use it inadvertently than to fight it in court. A few court cases got a lot of attention but they're pretty...
Actually I think it's more common for businesses to either not use GPL software or to use it inadvertently than to fight it in court. A few court cases got a lot of attention but they're pretty rare.
I think the big tech companies are the most likely to respect software licenses? At Google, software licensing is tracked as part of the build system. If you don't want them to use something, put it in the license and they won't use it. Smaller teams might not be as careful?
These days there is a lot more non-copyleft open source software available so there is little reason to want to use GPL software.
I would challenge you to find a company that uses no GPL software at all. Inadvertant is kind of irrelevant, because its pervasiveness shows just how powerful and subversive it is. But in the end...
I would challenge you to find a company that uses no GPL software at all. Inadvertant is kind of irrelevant, because its pervasiveness shows just how powerful and subversive it is.
But in the end it's immaterial. A MIT/BSD enthusiast's anti-GPL rant has largely been the same since the GPL was written. This one is just particularily elouquent.
Oops, that's not what I meant. Let me clarify. There's difference between simply using a GPLed tool or application (which nobody needs to worry about) and including a GPLed library in the release...
Oops, that's not what I meant. Let me clarify.
There's difference between simply using a GPLed tool or application (which nobody needs to worry about) and including a GPLed library in the release of your own software. I know that Google was careful about what they ship when I worked there. It's not very hard to avoid depending on any GPLed libraries when building an executable, provided you use a tool to automatically check the licenses of your dependencies. Not everyone does though, so it's possible a GPLed library might slip in.
Ah, gotcha. That does make more sense. I still endorse always using GPL for everything. If you manage to force open some previously-closed code, mission accomplished. If it doesn't matter to you,...
Ah, gotcha. That does make more sense.
I still endorse always using GPL for everything. If you manage to force open some previously-closed code, mission accomplished. If it doesn't matter to you, you've at least left the door open for your users to do so if they desire.
Just as another perspective, when working professionally I would write Java libraries that I thought were pretty good, but had to rewrite them from scratch after switching jobs. There are certain...
Just as another perspective, when working professionally I would write Java libraries that I thought were pretty good, but had to rewrite them from scratch after switching jobs. There are certain libraries I wrote multiple times. It's nice to have the option to release stuff as open source because then you can use it again. But if you release it as GPL you might not be able to use that library at your next job.
This doesn't apply to application or tools, though.
Also it turned out to be a theoretical concern. I never did release anything as open source that I used at another job. It's usually better to reuse popular libraries than make something new.
Still, the idea that maybe I could do that was enough for me to prefer non-copyleft licenses for libraries. This motivation (I could use this for work) might also be important for other programmers who write libraries?
Although I really admire the beauty of the GPL, I just public domain my code. It's easy to write something small and complete and shunt it off into space. Then I have no headache about what anyone...
Although I really admire the beauty of the GPL, I just public domain my code. It's easy to write something small and complete and shunt it off into space.
Then I have no headache about what anyone does with it, and it's as simple as possible for anyone to use. I also have zero interest in running a project accepting contributions and managing people in my free time.
I probably wouldn't use a copyleft license for a larger project, either. Drew Devault makes a great case for copyleft, but I've been more influenced by Rob Landley.
Of course, the WTFPL also holds a special place in my heart, as does the less well known Good Luck With That Public License, which to my knowledge might be the first software license with a specific NSFW version.
This is true. While I am not in the business of writing software for end users...I also don't ascribe to the concept that your employer owns everything you do on the clock. If you are concerned...
This is true. While I am not in the business of writing software for end users...I also don't ascribe to the concept that your employer owns everything you do on the clock.
If you are concerned about that, but still like GPL, you can dual license, that anybody who asks can obtain a GPL-free license and anybody who doesn't uses a GPL. The one key is you can't accept contributions from others, since they own the copyright for those contributions and you can't dictate a dual license on those.
This kind of insanity demonstrates quite effectively why I think software should generally not have any copyright/patent protections.
That's not true. If it's your project, you control what gets merged and you can ask for anything you like from contributors. You can require people submitting patches to use all the same...
That's not true. If it's your project, you control what gets merged and you can ask for anything you like from contributors. You can require people submitting patches to use all the same license(s) as the existing code as a precondition for doing the merge. You could even require copyright assignment, and some projects do.
Of course, if they don't like it then they might choose not to contribute. Also, you can't control what a fork might do, other than what's in the terms of the license.
Any dual licenced code needs that reassignment. Because when they fork, their license becomes GPL, not the dual license. If they push back their changes, they own those, and are GPLv2. You can...
Any dual licenced code needs that reassignment. Because when they fork, their license becomes GPL, not the dual license. If they push back their changes, they own those, and are GPLv2. You can accept those, but they can't be redistributed with the base dual-license without that reassignment.
Probably not a big issue for smaller things. But if you're making a big project it solves a lot of potential headaches if it's not pure GPL.
Sure! In countries where copyright is automatic (most of them), when you make contributions, those contributions are your copyright, not those of the original project (a derivative work). So you...
In countries where copyright is automatic (most of them), when you make contributions, those contributions are your copyright, not those of the original project (a derivative work). So you must have your contributors reassign copyright in order to avoid future legal hassle. Another interesting discussion on that.
In general, both you and @FlippantGod are correct, that the BSD/MIT licenses are easier. But that's also because they are not committed to Free Software. The GPL is specifically anti-proprietary. Open Source (as a term) was created as a way to kind of separate away from that.
The other advantage is one that Bitwarden leveraged for their server. By having their server software under AGPL with an option to dual license, they've basically given some powerful software away for free to anyone who likes free software (or wants to audit it). Anybody who is afraid of the AGPL (especially cloud providers) has the option to buy a proprietary license. They require the contributor agreement for that reason.
Those references doesn't say anything about dual licensing though. The basic idea is that you need to use some license in order to have permission to use someone else's copyright-protected code at...
Those references doesn't say anything about dual licensing though. The basic idea is that you need to use some license in order to have permission to use someone else's copyright-protected code at all. If a GPL license is the only one offered then you would have to use that one. But for code that's dual licensed,you have the choice of licenses. If you use the other license and then the terms of the GPL license don't matter - you're not relying on those terms so they don't apply.
I think you're missing something in there. Suppose Person A has dual licensed code on Project A (GPL and closed), where you have to pay for closed. Person A has the copyright on Project A, and can...
But for code that's dual licensed,you have the choice of licenses. If you use the other license and then the terms of the GPL license don't matter - you're not relying on those terms so they don't apply.
I think you're missing something in there.
Suppose Person A has dual licensed code on Project A (GPL and closed), where you have to pay for closed. Person A has the copyright on Project A, and can choose GPL or not.
Person B clones repo, and thus their usage is covered by GPL (not paid). This becomes Project B, and is now GPL. They own copyright on any changes they make to Project B.
If Person A or Person B wants to merge changes from B to A, they may. But those changes can't be redistributed under the secondary, closed license without reassignment. Because Person B's changes are under the GPL and not your dual-license, and Person B owns the copyright.
So Project A needs a reassignment of copyright agreement for pull requests so that contributer changes are no longer subject to just the GPL.
If Person C pays for a closed license, they are not subject to GPL at all and can do whatever your closed license allows them to.
Okay, I see what you mean now. When code is dual licensed, someone makes a fork, and the new code isn't distributed under both licenses, then, yes, any changes can't be merged upstream without...
Okay, I see what you mean now. When code is dual licensed, someone makes a fork, and the new code isn't distributed under both licenses, then, yes, any changes can't be merged upstream without getting additional permission from the authors of the new code.
However, I'm not sure that's very common? When code is distributed under two open source licenses, the original repo has license files for both licenses. If you fork the repo, it also has both licenses. Any new code you add will look like you released it under both licenses and people will assume that's what you wanted, unless you explicitly say otherwise, for example by using different license headers on any new source files you add.
Also, the common case (on GitHub anyway) is that the author of the changes sends a pull request to the owners of the original repo, and this pull request doesn't make any changes to any licenses in the original repo, so you're agreeing that your new code will be distributed under all the original licenses. (If you didn't want that, then you would put different license headers on your new code, this would be obvious in the pull request, and they would probably ask you to take them out before accepting the change.)
Sometimes there is a contributor license agreement to make that explicit. But reassigning copyright isn't necessary if the new code is already released under all the original licenses.
It's got a lot of great ideas and discussions of philosophical underpinings, but I really think they're approaching the GPL through the worst-possible lens.
The point of the GPL has nothing about protecting "my precious creation." It doesn't require you to push your changes upstream, or even host it on your webservers. An example is Kenwood stereo units. They have no requirement to provide their GPL software modifications to the public at large, or even all their users. Merely their users who request it. Here is the form
While the GPL does leverage property law to give it power, it very much anti-property. It is a CVE severity 10 exploit of property law, which enshrines a bill of rights for software users. In lay terms it really says "Your users have just as much right to use your modifications as you do mine." It leverages property law to prevent the creation of property, only creation of more commons. It's just enforced public domain, a wall of guards to prevent the lords from conqouring it and dividing it amongest themselves. Why else would you see giant swarms of corporations trying to shut it down in court, rather than just not using GPL software? There's the BSDs if you want to go that route, as Sony and Apple (and countless others) have. The big tech companies want to patch the legal system against the GPL.
Look at how the regular public domain has been crippled by these gigantic lengths of copyright extensions, and how much of our culture since the 1920's is being lost to the sands of time due to it. A substantial bit of Disney's empire was built by copying a chunk of this commons, declaring that copy theirs, and then lobbying to avoid returning it back as required by law.
Pirate sites now have the most comprehensive collections of movies and films to date, most of which would certainly be lost in 30+ years, long after it has ceased being profitable to sell it. They distribute in post-scarcity fashion, against the laws of the land.
Sure, the MIT and BSD licenses could be considered more post-scarcity philosophically. But the GPL is more post-scarcity in practice because we still live in a world which is manufacturing artificial scarcity.
Given that we now have 3d printers and DNA printers, once the GPL has reached into those schematics, you've burst open gigantic other swaths of property being dismantled to the commons.
Actually I think it's more common for businesses to either not use GPL software or to use it inadvertently than to fight it in court. A few court cases got a lot of attention but they're pretty rare.
I think the big tech companies are the most likely to respect software licenses? At Google, software licensing is tracked as part of the build system. If you don't want them to use something, put it in the license and they won't use it. Smaller teams might not be as careful?
These days there is a lot more non-copyleft open source software available so there is little reason to want to use GPL software.
I would challenge you to find a company that uses no GPL software at all. Inadvertant is kind of irrelevant, because its pervasiveness shows just how powerful and subversive it is.
But in the end it's immaterial. A MIT/BSD enthusiast's anti-GPL rant has largely been the same since the GPL was written. This one is just particularily elouquent.
Oops, that's not what I meant. Let me clarify.
There's difference between simply using a GPLed tool or application (which nobody needs to worry about) and including a GPLed library in the release of your own software. I know that Google was careful about what they ship when I worked there. It's not very hard to avoid depending on any GPLed libraries when building an executable, provided you use a tool to automatically check the licenses of your dependencies. Not everyone does though, so it's possible a GPLed library might slip in.
Ah, gotcha. That does make more sense.
I still endorse always using GPL for everything. If you manage to force open some previously-closed code, mission accomplished. If it doesn't matter to you, you've at least left the door open for your users to do so if they desire.
Just as another perspective, when working professionally I would write Java libraries that I thought were pretty good, but had to rewrite them from scratch after switching jobs. There are certain libraries I wrote multiple times. It's nice to have the option to release stuff as open source because then you can use it again. But if you release it as GPL you might not be able to use that library at your next job.
This doesn't apply to application or tools, though.
Also it turned out to be a theoretical concern. I never did release anything as open source that I used at another job. It's usually better to reuse popular libraries than make something new.
Still, the idea that maybe I could do that was enough for me to prefer non-copyleft licenses for libraries. This motivation (I could use this for work) might also be important for other programmers who write libraries?
Although I really admire the beauty of the GPL, I just public domain my code. It's easy to write something small and complete and shunt it off into space.
Then I have no headache about what anyone does with it, and it's as simple as possible for anyone to use. I also have zero interest in running a project accepting contributions and managing people in my free time.
I probably wouldn't use a copyleft license for a larger project, either. Drew Devault makes a great case for copyleft, but I've been more influenced by Rob Landley.
Of course, the WTFPL also holds a special place in my heart, as does the less well known Good Luck With That Public License, which to my knowledge might be the first software license with a specific NSFW version.
This is true. While I am not in the business of writing software for end users...I also don't ascribe to the concept that your employer owns everything you do on the clock.
If you are concerned about that, but still like GPL, you can dual license, that anybody who asks can obtain a GPL-free license and anybody who doesn't uses a GPL. The one key is you can't accept contributions from others, since they own the copyright for those contributions and you can't dictate a dual license on those.
This kind of insanity demonstrates quite effectively why I think software should generally not have any copyright/patent protections.
That's not true. If it's your project, you control what gets merged and you can ask for anything you like from contributors. You can require people submitting patches to use all the same license(s) as the existing code as a precondition for doing the merge. You could even require copyright assignment, and some projects do.
Of course, if they don't like it then they might choose not to contribute. Also, you can't control what a fork might do, other than what's in the terms of the license.
Any dual licenced code needs that reassignment. Because when they fork, their license becomes GPL, not the dual license. If they push back their changes, they own those, and are GPLv2. You can accept those, but they can't be redistributed with the base dual-license without that reassignment.
Probably not a big issue for smaller things. But if you're making a big project it solves a lot of potential headaches if it's not pure GPL.
I've never heard of that, and it seems contrary to the goal of dual licensing, which is that you can choose either one. Do you have a reference?
Sure!
In countries where copyright is automatic (most of them), when you make contributions, those contributions are your copyright, not those of the original project (a derivative work). So you must have your contributors reassign copyright in order to avoid future legal hassle. Another interesting discussion on that.
In general, both you and @FlippantGod are correct, that the BSD/MIT licenses are easier. But that's also because they are not committed to Free Software. The GPL is specifically anti-proprietary. Open Source (as a term) was created as a way to kind of separate away from that.
The other advantage is one that Bitwarden leveraged for their server. By having their server software under AGPL with an option to dual license, they've basically given some powerful software away for free to anyone who likes free software (or wants to audit it). Anybody who is afraid of the AGPL (especially cloud providers) has the option to buy a proprietary license. They require the contributor agreement for that reason.
Those references doesn't say anything about dual licensing though. The basic idea is that you need to use some license in order to have permission to use someone else's copyright-protected code at all. If a GPL license is the only one offered then you would have to use that one. But for code that's dual licensed,you have the choice of licenses. If you use the other license and then the terms of the GPL license don't matter - you're not relying on those terms so they don't apply.
I think you're missing something in there.
Suppose Person A has dual licensed code on Project A (GPL and closed), where you have to pay for closed. Person A has the copyright on Project A, and can choose GPL or not.
Person B clones repo, and thus their usage is covered by GPL (not paid). This becomes Project B, and is now GPL. They own copyright on any changes they make to Project B.
If Person A or Person B wants to merge changes from B to A, they may. But those changes can't be redistributed under the secondary, closed license without reassignment. Because Person B's changes are under the GPL and not your dual-license, and Person B owns the copyright.
So Project A needs a reassignment of copyright agreement for pull requests so that contributer changes are no longer subject to just the GPL.
If Person C pays for a closed license, they are not subject to GPL at all and can do whatever your closed license allows them to.
Okay, I see what you mean now. When code is dual licensed, someone makes a fork, and the new code isn't distributed under both licenses, then, yes, any changes can't be merged upstream without getting additional permission from the authors of the new code.
However, I'm not sure that's very common? When code is distributed under two open source licenses, the original repo has license files for both licenses. If you fork the repo, it also has both licenses. Any new code you add will look like you released it under both licenses and people will assume that's what you wanted, unless you explicitly say otherwise, for example by using different license headers on any new source files you add.
Also, the common case (on GitHub anyway) is that the author of the changes sends a pull request to the owners of the original repo, and this pull request doesn't make any changes to any licenses in the original repo, so you're agreeing that your new code will be distributed under all the original licenses. (If you didn't want that, then you would put different license headers on your new code, this would be obvious in the pull request, and they would probably ask you to take them out before accepting the change.)
Sometimes there is a contributor license agreement to make that explicit. But reassigning copyright isn't necessary if the new code is already released under all the original licenses.