Date: Wed, 21 Feb 2001 01:31:07 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Dennis Jun" <dennisjun@home.com>, <freebsd-advocacy@FreeBSD.ORG> Subject: RE: BSD licence vs GPL Message-ID: <007101c09be9$04ff4f60$1401a8c0@tedm.placo.com> In-Reply-To: <046d01c09bd0$1e8bdfc0$0300a8c0@wilma>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-advocacy@FreeBSD.ORG > [mailto:owner-freebsd-advocacy@FreeBSD.ORG]On Behalf Of Dennis Jun > Sent: Tuesday, February 20, 2001 10:33 PM > To: freebsd-advocacy@FreeBSD.ORG > Subject: BSD licence vs GPL > > > Hello all! > > A Linux friend of mine and I were chatting bout the BSD licence versus the > GPL. He was asking me how *BSD developers felt about that their code could > (and has) being used by commercial companies and in turn becomes closed in > the end. That is, you don't know if your code will stay open or not. He No, what happens is that the second that the commercial company closes their source, the source "forks", ie becomes disconnected from the public source that everyone is working in. I question if your friend has worked on large code projects much. The problem with forking off your own private copy of BSD code is that now, every time that someone makes a refinement to the BSD code that makes it better, if you want to take advantage of that refinement you have to go back and re-implement it into your own code. This is pretty easy to do initially, but the more divergence you yourself place into your own private source, the harder it becomes. For example, say you get BSD networking code and you see a race condition in it. You fix it, and decide that your fix is so fantastic that your not going to share it. Then, 3 months later someone working on the public code notices the same race condition, and fixes it, but does it differently than you did. Then, a few weeks later someone working on the BSD code implements this great new feature that has a component that's integrated into the public BSD anti-race code. Now, you have a lot of work, because you have to go rip out your race fix and redo it like the BSD code, then integrate in this new feature. And, what if you have continued to make modifications to the code, so now when you rip out your race fix, you break more of your own code. And, if you decide not to rip out your race fix, then you have to reimplement the new feature in the public code. You can imagine what happens if this sort of thing has been going on for years and years with hundreds of little changes - implementing new features basically eventually means that you cannot merely copy them into your code from the BSD code, you have to completely reengineer them. What ends up happening if the fork exists for years and years is that your code ultimately becomes so different from the BSD code that ie completely loses all resemblance to the BSD code, ie: it simply no longer IS BSD code. Thus, you eventually end up losing access to the very code that you originally decided to "close" To give you some examples of why this is so stupid, there have been a number of security vulnerabilities posted in the last couple of years that were repaired in publc BSD code within a day of release of knowledge of the vulnerability, yet commercial software vendors (who purported to be using Real Live BSD networking code) took weeks to issue patches. Well I can tell you, this is a recipie for getting your commercial software ejected from any self-respecting ISP. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com > asked doesn't that bother BSD developers? I thought this was a very > interesting question. I couldn't give him a really good answer since I'm > not a programmer. So I wanted to ask some people who do program and > contribute to BSD what their thoughts on this is. Does it bother you? Is > it even an issue? Much thanx in advance. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-advocacy" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007101c09be9$04ff4f60$1401a8c0>