4 ms·

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions. For complex situations, you can always choose "other

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions. For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.

d0mine 15y ago
you could use "keep it free" if "copyleft" is not descriptive enough, though just the name of a license would work best.
pygy_ 15y ago
Prepare for an uproar if an entity the size of GitHub summarizes the GPL as "restrictive". The GPL enables freedom for the end user, who's entitled to obtain and modify the source of the programs he uses. It offers some protection against repressive governments and monopolistic companies, a much broader scope than what permissive licenses enable (freedom for the developers). "Copyleft" is well defined and easy to google. Education doesn't hurt people.
- madrobby 15y ago
  So what if there's an uproar? Other license writers could also want to be treated specially. This is just about a general filter, into "proprietary", "do whatever you want to", and "restrictive" open source licenses; for developers when they choose which projects on GitHub might be a good fit for their needs. If you read the GPL it puts a lot of restrictions on what you can do as a developer. So do other licenses (for example licenses that allow you to use the source in open source projects but require some form of payment when used for commercial products).
  - phillmv 15y ago
    You do understand how there are people who would disagree with your characterization, and thus the more neutral term 'copyleft' is the most… let's call it politically-safe term to use. Let's not even touch lumping the copyleft licenses with non-commercial-only licenses. The gradation of rights and privileges goes farther than "Public Domain, Sort of Public Domain, Restrictive". The best way is to just have a dropdown that lists the name of the license.
  - pygy_ 15y ago
    > So what if there's an uproar? It would be boneheaded from a PR stand point, and it is insulting towards the GPL. > Other license writers could also want to be treated specially. You seem to have a serious gripe with the GPL. The GPL (its unnamed ancestor, to be pedantic) is the mother of open source licenses. It enables Freedom, with a capital "f" for its users, at the expense of obligations for people who distribute binaries. Liberal licenses turn the situation around. Labeling the GPL, but not liberal licenses as restrictive is heavily biased, and simply does not reflect reality (since liberal licenses put implicit restrictions on binaries recipients). I speak as a license author, BTW: https://github.com/pygy/The-Romantic-WTF-Public-License https://github.com/pygy/The-Romantic-WTF-Public-License
    - gte910h 15y ago
      I'd love to release source, and USE gpl software, and even make a unsigned binary available that if you could hack your own hardware to run, you could. But even if I did, the GPL would prevent me from releasing said software using GPLed libraries, as the actual binary they get has to be trivially copyable. That's crap. That's restrictive. Why can't I supply you with an alternative binary on a website just like I can with the source? Restrictive isn't hate. It's a description. GPL licensed code is useless code to people who develop for top tier gaming platforms other than the PC.
      - pygy_ 15y ago
        > I'd love to release source, and USE gpl software, and even make a unsigned binary available that if you could hack your own hardware to run, you could. But even if I did, the GPL would prevent me from releasing said software using GPLed libraries, as the actual binary they get has to be trivially copyable. That's crap. That's restrictive. Why can't I supply you with an alternative binary on a website just like I can with the source? I'm afraid I don't understand your point... You can distribute GPLed software as binaries, but you must provide the source on request. Edit: Perhaps you mean that you want to release your source code under another license? > Restrictive isn't hate. It's a description. My point is that all licenses are restrictive in a way or another. Even WTF-type licenses or the public domain have implicit restrictions. Singling out the GPL as restrictive is insulting, because its restrictions are designed to enable the freedom for people to check the source code for vulnerabilities or user hostile features (how many backdoors for the US govt. are there in Windows?). > GPL licensed code is useless code to people who develop for top tier gaming platforms other than the PC. ... because of restrictions imposed by the SDK user agreement.
  - kl4m 15y ago
    It has no restrictions for developers, only for redistributors.
- gte910h 15y ago
  Yes, the GPL (specifically GPL2) is powerful enough to empower users on those systems to never have to worry about using a program with any GPLed code in it. What a benefit for them.
metamattl 15y ago
Even if "restrictive" is misleading? Copyleft licenses really don't seem to be a problem unless you're trying to make something proprietary? Unless I'm missing some other restriction...
mkup 15y ago
I don't understand why are you being downvoted, as GPL does actually impose some restrictions in comparison to BSD/MIT. These restrictions may be for copyleft, for benefit of end users, pro bono, for whatever else, but there are restrictions, and the term "restrictive open source" captures the essense of this license. Also, these restrictions won't disappear no matter how low your (or mine) comment is downvoted here on HN.
mindcrime 15y ago
Many people don't know what "copyleft" is, so "restrictive" makes more sense. I could see that holding true among the general population, but among developers? What developer who's going to be browsing Github doesn't know what copyleft means? There are more restrictions. Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective the GPL is "more free" in a sense. All of that said, I get the point behind a simple binary "restrictive/permissive" flag, and I think most people would intuitively grok the general sense of it. I'm not opposed to it, but I think we could do better. Hmmm... that raises an interesting point... does Github have any sort of notion of explicit support for DOAP[1] files? Encouraging people to use DOAP files might be a better answer anyway. [1]: http://en.wikipedia.org/wiki/Description_of_a_Project http://en.wikipedia.org/wiki/Description_of_a_Project
- nkassis 15y ago
  "Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective the GPL is "more free" in a sense." This is an important point. How many people know that they should list their changes when using EDIT:Some licenses or the patent stuff in the Apache license etc... These tags don't really make sense.
  - mindcrime 15y ago
    or the patent stuff in the Apache license Exactly. That's a great example of what I had in mind. Nobody talks about it, but that stuff is there and is important.

d0mine 15y ago

you could use "keep it free" if "copyleft" is not descriptive enough, though just the name of a license would work best.

pygy_ 15y ago

Prepare for an uproar if an entity the size of GitHub summarizes the GPL as "restrictive". The GPL enables freedom for the end user, who's entitled to obtain and modify the source of the programs he uses. It offers some protection against repressive governments and monopolistic companies, a much broader scope than what permissive licenses enable (freedom for the developers). "Copyleft" is well defined and easy to google. Education doesn't hurt people.

madrobby 15y ago
So what if there's an uproar? Other license writers could also want to be treated specially. This is just about a general filter, into "proprietary", "do whatever you want to", and "restrictive" open source licenses; for developers when they choose which projects on GitHub might be a good fit for their needs. If you read the GPL it puts a lot of restrictions on what you can do as a developer. So do other licenses (for example licenses that allow you to use the source in open source projects but require some form of payment when used for commercial products).
- phillmv 15y ago
  You do understand how there are people who would disagree with your characterization, and thus the more neutral term 'copyleft' is the most… let's call it politically-safe term to use. Let's not even touch lumping the copyleft licenses with non-commercial-only licenses. The gradation of rights and privileges goes farther than "Public Domain, Sort of Public Domain, Restrictive". The best way is to just have a dropdown that lists the name of the license.
- pygy_ 15y ago
  > So what if there's an uproar? It would be boneheaded from a PR stand point, and it is insulting towards the GPL. > Other license writers could also want to be treated specially. You seem to have a serious gripe with the GPL. The GPL (its unnamed ancestor, to be pedantic) is the mother of open source licenses. It enables Freedom, with a capital "f" for its users, at the expense of obligations for people who distribute binaries. Liberal licenses turn the situation around. Labeling the GPL, but not liberal licenses as restrictive is heavily biased, and simply does not reflect reality (since liberal licenses put implicit restrictions on binaries recipients). I speak as a license author, BTW: https://github.com/pygy/The-Romantic-WTF-Public-License https://github.com/pygy/The-Romantic-WTF-Public-License
  - gte910h 15y ago
    I'd love to release source, and USE gpl software, and even make a unsigned binary available that if you could hack your own hardware to run, you could. But even if I did, the GPL would prevent me from releasing said software using GPLed libraries, as the actual binary they get has to be trivially copyable. That's crap. That's restrictive. Why can't I supply you with an alternative binary on a website just like I can with the source? Restrictive isn't hate. It's a description. GPL licensed code is useless code to people who develop for top tier gaming platforms other than the PC.
    - pygy_ 15y ago
      > I'd love to release source, and USE gpl software, and even make a unsigned binary available that if you could hack your own hardware to run, you could. But even if I did, the GPL would prevent me from releasing said software using GPLed libraries, as the actual binary they get has to be trivially copyable. That's crap. That's restrictive. Why can't I supply you with an alternative binary on a website just like I can with the source? I'm afraid I don't understand your point... You can distribute GPLed software as binaries, but you must provide the source on request. Edit: Perhaps you mean that you want to release your source code under another license? > Restrictive isn't hate. It's a description. My point is that all licenses are restrictive in a way or another. Even WTF-type licenses or the public domain have implicit restrictions. Singling out the GPL as restrictive is insulting, because its restrictions are designed to enable the freedom for people to check the source code for vulnerabilities or user hostile features (how many backdoors for the US govt. are there in Windows?). > GPL licensed code is useless code to people who develop for top tier gaming platforms other than the PC. ... because of restrictions imposed by the SDK user agreement.
- kl4m 15y ago
  It has no restrictions for developers, only for redistributors.
gte910h 15y ago
Yes, the GPL (specifically GPL2) is powerful enough to empower users on those systems to never have to worry about using a program with any GPLed code in it. What a benefit for them.

metamattl 15y ago

Even if "restrictive" is misleading? Copyleft licenses really don't seem to be a problem unless you're trying to make something proprietary? Unless I'm missing some other restriction...

mkup 15y ago

I don't understand why are you being downvoted, as GPL does actually impose some restrictions in comparison to BSD/MIT. These restrictions may be for copyleft, for benefit of end users, pro bono, for whatever else, but there are restrictions, and the term "restrictive open source" captures the essense of this license. Also, these restrictions won't disappear no matter how low your (or mine) comment is downvoted here on HN.

mindcrime 15y ago

Many people don't know what "copyleft" is, so "restrictive" makes more sense. I could see that holding true among the general population, but among developers? What developer who's going to be browsing Github doesn't know what copyleft means? There are more restrictions. Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective the GPL is "more free" in a sense. All of that said, I get the point behind a simple binary "restrictive/permissive" flag, and I think most people would intuitively grok the general sense of it. I'm not opposed to it, but I think we could do better. Hmmm... that raises an interesting point... does Github have any sort of notion of explicit support for DOAP[1] files? Encouraging people to use DOAP files might be a better answer anyway. [1]: http://en.wikipedia.org/wiki/Description_of_a_Project http://en.wikipedia.org/wiki/Description_of_a_Project

nkassis 15y ago
"Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective the GPL is "more free" in a sense." This is an important point. How many people know that they should list their changes when using EDIT:Some licenses or the patent stuff in the Apache license etc... These tags don't really make sense.
- mindcrime 15y ago
  or the patent stuff in the Apache license Exactly. That's a great example of what I had in mind. Nobody talks about it, but that stuff is there and is important.