5 ms·

In this post, whenever I use GPL I am using it to refer to the class of licenses (AGPL, LGPL, and GPL proper), not the specific license. Remember that Colin is

by tsally 17y ago

In this post, whenever I use GPL I am using it to refer to the class of licenses (AGPL, LGPL, and GPL proper), not the specific license. Remember that Colin is FreeBSD's security officer, so it's probably pretty obvious which camp of open source thinking he falls into. :-) I'll do my best to present the other way of thinking within the open source community. I recognize the FreeBSD school of thought and don't have a problem with it, I just think there is a better way. Let's use Colin's example and say you find and fix a bug in an open source library you are using. It is at that point I believe you have an ethical responsibility to contribute back. You found a bug and you should share the fix with everyone. Hell, the library probably wouldn't even be in a usable state if people didn't contribute patches. Patching back is what keeps the open source ecosystem flowing, and if you can encourage it though a license it's probably a good idea Now, people of the FreeBSD camp believe that people will usually contribute patches on their own accord. This might be true for open source hackers, but I can tell you that it is not true at large companies (not sure about the startup scene). The GPL camp believes it is better to have stronger language to encourage people to contribute back. Even with the GPL, if you are modifiying code for your own use, you can do whatever you want. It is only when you use GPLed code to run a service or to provide a product that you have to make your patches availible under the GPL. It's simple really. If you attempt to profit or use the code in any way other than for personal reasons, the GPL kicks in. Let's examin a running theory in the OpenBSD community. Theo thinks that the GPL is a poor choice because companies are scared of it. They are afraid to get involved with the GPL because it is a viral license, and thus will not contribute code back. He contends that to achieve their main goal of security, they need a more permissive license so companies will patch back. Theo may be right, but it is my personal belief that in practice this theory does not hold. I contend that any company with a useful patch will want to hold on to it, no matter what. Useful patches for OpenSSH represent a competitive advantage that other companies do not have. If I ran a company purely for profit, I would keep all my patches under wraps, regardless of license. It is for that reason that I believe the GPL style licenses are a better choice.

davidw 17y ago
You sum up two points of view: * Make them share stuff (GPL) * Be permissive, and aim for a bigger community - companies can participate and still use the stuff for proprietary code of their own. (BSD/Apache). > it is my personal belief that in practice this theory does not hold. Do you have any evidence either way? Both are valid points and have been show to 'work' in some way. Apache has lots of companies that participate, which is a counterpoint to your theory. On the other hand, maybe individuals are less likely to participate in efforts seen to benefit Big Companies? I suspect there are no certain answers.
- tsally 17y ago
  You're right, there are no certain answers. In fact, sometimes it seems that community and company participation is kind of arbitrary. It is because of that uncertainty that I believe in the GPL. The GPL licsenses provide legal incentive and wont stop any altruistic individuals from contributing as well. As for companies, you'll see from my example below that license may not actually matter at all. If you look at some of the more prominant examples, getting companies to contribute actually doesn't have anything to do with the license, and everything to do with popularity. nVidia provides both 32 bit and 64 bit blobs for Linux, but only a 32 bit blob for FreeBSD. This is only because Linux is widespread, and the blobs are neither GPLed or under a BSD license.
  - davidw 17y ago
    I'm talking more about "library" style code. BSD means companies can integrate it, and potentially contribute back. And this does happen. GPL may mean they simply do not use it, and thus the project loses out on potential contributions.
    - prodigal_erik 17y ago
      Despite BSD's large head start, Linux has received substantially more contributed work. This is evidence that "this is useful, let's follow the license" tends to outweigh "this is scary, let's avoid the project".
cperciva 17y ago
Useful patches for OpenSSH represent a competitive advantage that other companies do not have. True. However, they also result in additional costs -- you may have to rewrite your patches when new versions of OpenSSH are released, you will have additional system administration costs (you won't be able to use precompiled OpenSSH binaries), and you may have additional training costs (it's easy to find a sysadmin who knows how to use OpenSSH; not so easy to find someone who knows how to use OpenSSH-plus-your-local-patches). Even worse, there's a risk -- and I've seen this happen to many companies -- that whoever wrote your patches originally will leave the company, and you'll be stuck wanting to update to a newer OpenSSH but without the expertise needed to merge your patches. I'm not saying that it's always to your advantage to contribute patches back -- but I think in most cases the costs of keeping your own patches outweigh any competitive advantage they may give you.
- tsally 17y ago
  Good point, I had never thought about it quite that in depth before. However, I am still willing to contend that large companies who can afford the staff do (or should) have large internal patch sets for OpenSSH, FreeBSD, etc. You can be sure the NSA does. ;-)
  - cperciva 17y ago
    I am still willing to contend that large companies who can afford the staff do (or should) have large internal patch sets for OpenSSH, FreeBSD, etc. This absolutely happens -- I know of lots of companies which do this, for a wide variety of reasons. Some companies have local patches which aren't contributed back because they simply aren't relevant to the community at large; for example, I know of one large FreeBSD-using company which at one point had if (strcmp(fname, "mysql")) { /* Handle mysql processes specially */ ... } blocks in their kernel. Other companies have local patches simply because they're not sure exactly how to go about contributing changes back -- either due to a lack of knowledge about open source in general, or because they started with a source tree and started hacking, and aren't sure exactly what they've changed. I've seen job postings with "get the changes we've been making locally for the past five years into the FreeBSD tree" high on the list of job responsibilities. And then, of course, you're right that there are some companies which have changes which they could contribute back, but choose not to. But based on the companies I've talked to (which, admittedly, is a biassed sample), this doesn't seem to be a very common scenario.

by tsally 17y ago

davidw 17y ago

You sum up two points of view: * Make them share stuff (GPL) * Be permissive, and aim for a bigger community - companies can participate and still use the stuff for proprietary code of their own. (BSD/Apache). > it is my personal belief that in practice this theory does not hold. Do you have any evidence either way? Both are valid points and have been show to 'work' in some way. Apache has lots of companies that participate, which is a counterpoint to your theory. On the other hand, maybe individuals are less likely to participate in efforts seen to benefit Big Companies? I suspect there are no certain answers.

tsally 17y ago
You're right, there are no certain answers. In fact, sometimes it seems that community and company participation is kind of arbitrary. It is because of that uncertainty that I believe in the GPL. The GPL licsenses provide legal incentive and wont stop any altruistic individuals from contributing as well. As for companies, you'll see from my example below that license may not actually matter at all. If you look at some of the more prominant examples, getting companies to contribute actually doesn't have anything to do with the license, and everything to do with popularity. nVidia provides both 32 bit and 64 bit blobs for Linux, but only a 32 bit blob for FreeBSD. This is only because Linux is widespread, and the blobs are neither GPLed or under a BSD license.
- davidw 17y ago
  I'm talking more about "library" style code. BSD means companies can integrate it, and potentially contribute back. And this does happen. GPL may mean they simply do not use it, and thus the project loses out on potential contributions.
  - prodigal_erik 17y ago
    Despite BSD's large head start, Linux has received substantially more contributed work. This is evidence that "this is useful, let's follow the license" tends to outweigh "this is scary, let's avoid the project".

cperciva 17y ago

Useful patches for OpenSSH represent a competitive advantage that other companies do not have. True. However, they also result in additional costs -- you may have to rewrite your patches when new versions of OpenSSH are released, you will have additional system administration costs (you won't be able to use precompiled OpenSSH binaries), and you may have additional training costs (it's easy to find a sysadmin who knows how to use OpenSSH; not so easy to find someone who knows how to use OpenSSH-plus-your-local-patches). Even worse, there's a risk -- and I've seen this happen to many companies -- that whoever wrote your patches originally will leave the company, and you'll be stuck wanting to update to a newer OpenSSH but without the expertise needed to merge your patches. I'm not saying that it's always to your advantage to contribute patches back -- but I think in most cases the costs of keeping your own patches outweigh any competitive advantage they may give you.

tsally 17y ago
Good point, I had never thought about it quite that in depth before. However, I am still willing to contend that large companies who can afford the staff do (or should) have large internal patch sets for OpenSSH, FreeBSD, etc. You can be sure the NSA does. ;-)
- cperciva 17y ago
  I am still willing to contend that large companies who can afford the staff do (or should) have large internal patch sets for OpenSSH, FreeBSD, etc. This absolutely happens -- I know of lots of companies which do this, for a wide variety of reasons. Some companies have local patches which aren't contributed back because they simply aren't relevant to the community at large; for example, I know of one large FreeBSD-using company which at one point had if (strcmp(fname, "mysql")) { /* Handle mysql processes specially */ ... } blocks in their kernel. Other companies have local patches simply because they're not sure exactly how to go about contributing changes back -- either due to a lack of knowledge about open source in general, or because they started with a source tree and started hacking, and aren't sure exactly what they've changed. I've seen job postings with "get the changes we've been making locally for the past five years into the FreeBSD tree" high on the list of job responsibilities. And then, of course, you're right that there are some companies which have changes which they could contribute back, but choose not to. But based on the companies I've talked to (which, admittedly, is a biassed sample), this doesn't seem to be a very common scenario.