On Nov 13, 2006, at 02:21, Alan Brown wrote:
On Fri, 10 Nov 2006, Les Mikesell wrote:Is a non-free version a big issue for you? I've always been a big fanof perl's dual-license approach which effectively removes the restrictions of the GPL while allowing it to co-exist with GPL'd components. I think it's been a good thing for everyone.My only concern would be any form of license which allows a vendor to ship Bacula as a closed-source proprietary product without Kern's permission and without paying him royalties. This (to me) is the fundamental flaw of BSD-style licenses.(*) The superiority of GPL-license community developed products over BSD-license ones is well illustrated by the shenanigans that several vendors (especially Broadcom!) have gotten up to in order to disguise GPL-cored products (particularly embedded systems using the Busybox package - see www.gpl-violations.org) and claim them as proprietary.
This argument is predicated on a few assumptions:1) Vendor's usage of GPL software denotes blanket superiority of said software. 2) Users of software have a fundamental, moral right to not only the open source licensed implementations, but any aggregate work based atop those implementations. 3a) With the GPL, vendors will generally create a product based open source software, and then contribute their changes back to the projects in a usable form. 3b) Without the GPL, vendors will generally create a product based on open source software and NOT contribute their changes back to projects in a usable form. 3c) The author of open source software desires, or is best served, by royalties for all aggregate works.
The wide-spread adoption of GPLd software in the wireless sphere (such as that by Broadcom) is not -necessarily- based on the technical superiority of Linux, or GPLd software as a whole. As I was very interested in why vendors were using Linux on embedded devices, and not, say, NetBSD, I asked a friend of mine who formerly worked at devicescape Software, Inc -- a supplier of software for wireless devices. While devicescape did seriously consider NetBSD, they decided to base their product on Linux for a very simple reason: Foreign hardware vendors know the "Linux" brand, and that sold software. Their choice had more to do with brand recognition than technical superiority or licensing.
It is more difficult to address the notion of a user's "moral right" to aggregate work, and there's no correct answer. *My* answer is, however, that all work is aggregate -- Linux would not exist without Unix, Unix would not exist without Bell Labs, Bell Labs would not exist without Western Electric, Western Electric would not exist were it not for the industrial revolution -- ad infinitum. Within this framework, copyright exists as a limited monopoly on your individual culmination of aggregated work, for the purpose of encouraging contribution to the grand compendium of human production. The BSD license short-circuits the limited, artificial copyright monopoly -- opening your contribution to the world for *immediate* use by all comers, for all purposes. The GPL does not. I choose the BSD license when I believe that I will gain more by allowing immediate, unlimited, unrestricted aggregate work. I do not claim that this is the best choice, merely a reasoned one designed to gain maximum personal benefit. If you wish for royalties on commercial, close- source use of your work, you would likely choose otherwise.
Lastly, there is the aphorism that the GPL will lead to more vendor contribution than a more permissive license. I do not believe that licensing is a primary motivator in the decision to open source software in most (not all!) cases. Let's assume logical, informed actors -- if a company is comfortable with open sourcing their own code, there are inherent motivators to doing so regardless of whether they are compelled by licensing. Maintaining a fork of a given piece of software is an expensive and time consuming proposition, whereas contributing code upstream eliminates the cost of maintaining local modifications, while distributing the cost of overall code maintenance. Alternatively, if a company is not comfortable with open sourcing their code, then they will avoid licenses that force them to do so entirely.
Of particular interest to me, however, is the border case -- a company that is not comfortable open sourcing their own body of work when linked against existing code, but is comfortable contributing improvements and changes to the open source code base. This case is well suited to an example, so I'll make one up -- let's blithely pretend that Apple is interested in supporting Bacula backups natively in Mac OS X. As Bacula's existing network protocol is prone to change and incompatibilities between versions, Apple would greatly benefit from rewriting Bacula's network protocol implementation as a re-usable library. In turn, Bacula would greatly benefit from a stable network protocol and a re-usable protocol library. However, if Apple wished to link the newly written Bacula network protocol implementation with their own source code, they could not do so without releasing their own source code under the GPL license -- and thus may not contribute to begin with.
As licensing choices are entirely based in reasoned evaluation of costs and benefits, and are not, in my opinion, a moral decision, I do not posit that there is a correct choice at all, much less that mine is the correct one. I do, however, hold that the sociological intricacies of open source software development are sufficiently complex that it's simply disingenuous to make a blanket assertion that BSD-style licenses are fundamentally flawed.
-landonf
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
