Date: Sat, 13 Mar 1999 22:15:14 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: sprice@hiwaay.net (Steve Price) Cc: tlambert@primenet.com, advocacy@freebsd.org Subject: FAQ: debunking UCB (BSD) license objections Message-ID: <199903132215.PAA21748@usr09.primenet.com> In-Reply-To: <Pine.OSF.4.02.9903122314300.10606-100000@fly.HiWAAY.net> from "Steve Price" at Mar 12, 99 11:21:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Well, enough people have asked for this that I'm sending it out. > # Deflect them. If they examine their license critically against > # another license that better espouses their philosophy, their reason > # for buy-in to the GPL in the first place, then the GPL has lost. > # > # That's why I point at the eCOS license. As an instrumentality of > # the GNU Manifesto, it is a profoundly superior document to the GPL. Q1. What is the URL for the eCOS license? http://www.cygnus.com/ecos/ecoslicense.html > # Then you shoot down their primary anti-UCB themes one by one. I > # can give you the distilled themes and the canned counter-arguments, > # with real-world examples, if you want. Q2. I want a copy of the distilled themes list for <my reason here>; can you send it to me? ------------------------------------------------------------------------ A brief FAQ debunking common objections to the UCB (BSD) license Author: Terry Lambert Date: 13 March 199 Version: 1.0 Q) What about the ``obnoxious BSD advertising clause''? People say it "leads to a kind of gridlock for advertising free software". A) This is actually a "claim credit" clause. It's intended to ensure that authors are given credit for their work. It reads as follows: 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. This supposedly results in a "plethora" of different people you "have to" acknowledge when advertising the software. This is false. The important part is "mentioning features or use of this software". If your advertising doesn't say something like: Uses a terrific new scheduling algorithm! or: New! Now with BSD Net/2 TCP/IP! ("features" or "use"), then you are off the hook, and don't have to put the notices anywhere but appendix X of your documentation, and you can use agregation, to print the license in total once (substituting "DEVELOPERS"), and a list of the people, institutions, or corporations who are DEVELOPERS. Q) But can't people take my code and make it proprietary? A) No. They can only make proprietary _derivative works_. Your code is your code, and remains your code. Generally, there is some proprietary derivation going on, but unless your code did something unique (like SAMBA), even if your code was under one of the "copyleft" type licenses, it would be very hard for you to prove. This has happened to SAMBA several times in the past, and it's only the unique nature of SAMBA that allowed the SAMBA people to become suspicious. Generally, if someone uses your code once it's published, you'll probably never know about it, unless whoever uses it also publishes. Q) But why would a greedy company ever contribute changes back under _any_ circumstances? A) You just said it: because they're _greedy_. Companies are run by people. These are either relatively smart people, or the company doesn't stay in business very long. Here is how contributing code back to an open source project can be greedy: 1) By contributing the code back, the ongoing maintenance costs associated with keeping the code running and fixing bugs can be paid by the open source project, instead of your company. 2) By contributing back changes which are tactically important for your business, you get rid of the ongoing maintenance burden of reintegrating them each time the open source project makes a new release. This yields a big competitive advantage against anyone else who is also using the source to do the same things you are, but isn't giving their changes back. 3) By contributing back changes which are tactically important for your business, you are buying an "extended warrantee" that the open source project won't make changes that conflict with your changes; you gain a small amount of philosophical control. This also yields a big competitive advantage against anyone else who is also using the source to do the same things you are, but isn't giving their changes back. 4) By contributing code back, you control the space in which your competition has to play. Using the leverage of an open source project to set baseline standards in the competitive space, and forcing your competitions hand to follow yours. 5) By contributing code back, you gain cooperative advantage, as well as competitive advantage. This means, for instance, that your competition and you can interoperate, and any competing companies that don't adopt the code either have to work like mad to keep up, or they don't interoperate. This may give some of your competition a leg up at the same time it gives you a leg up, but not all of your competition. 6) By contributing code back, you can poison the well. I was reluctant to include this one, but it's a real danger that any open source project faces, regardless of the license used, and I would be lying if I said I didn't think this happens from time to time. The need to get the warning out was more important than the need to not give someone bad ideas; security through obscrity rarely works anyway. Q) OK, I can see how _tactical_ changes get contributed back, but what about _strategic_ changes? A) They don't. At least, not immediately; you need to take the long term view. Eventually, anything that's strategic will become tactical. This will happen either because the strategic value degrades over time as the competition develops equivalent technology, because the market you are in changes in some way, or the open source project you are leveraging for competitive advantage changes in such a way that you can no longer leverage it. This last can happen because of conflicting architectural changes that preclude your code from working, development of equivalent technology in the open source project for its own purposes (or worse, by your competition), The open source project is leaving your code in the dust, or simply because the ongoing maintenance burden outweighs the strategic advantage you had by keeping the code close to your vest. It's also important to note that patents play a critical role here. If you have strategic code, and it's covered by a process (algorithm) patent, no one can use it without your license anyway, and the open source project probably won't take the code under those conditions anyway. ------------------------------------------------------------------------ Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199903132215.PAA21748>