Date: Thu, 18 Oct 2001 06:36:04 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Doug Hass <dhass@imagestream.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, Ted Mittelstaedt <tedm@toybox.placo.com>, Leo Bicknell <bicknell@ufp.org>, Jim Bryant <kc5vdj@yahoo.com>, MurrayTaylor <taylorm@bytecraft.au.com>, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: FYI Message-ID: <3BCEDAC4.3A7286D2@mindspring.com> References: <Pine.LNX.3.96.1011017120835.4443B-100000@ims1.imagestream.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Hass wrote: > It's not a generalization at all. Honestly, compared to the market > traction that Linux, VxWorks, Solaris and others have, FreeBSD is > definitely without legs. The WAN card and RAS card markets are good > examples of where the attitude toward "BSD-licensed code or bust" has > resulted in FreeBSD being largely left out of the party. Three of the > largest manufacturers in these segments (SBS, Cyclades, and Ariel) all > support Linux and NT, but do not have BSD support. > > I've been frusturated repeatedly over the past few years as I try to > continue to use FreeBSD myself for different applications. > > It's too bad we can't find a way to include more companies and > solutions instead of continuing to find ways to EXCLUDE them... Let's take GPL'ed code as an example (it's just an example; it is not the only license that makes it hard to distribute full systems using the code). Code in the boot path can't be GPL'ed. This is because of the GPL's "poison pill" restrictions against BSD licensed code: 1) All code linked against GPL'ed code becomes GPL'ed Most of the code, we couldn't change the license if we wanted to, so this is a non-starter. 2) No additional restrictions There is still a lot of code (this is not a bad thing) that contains the 4 clause license, which means it includes the "claim credit" clause, which means that if you mention features or use of the code, you have to include the copyright in advertising materials so that you aren't claiming you wrote the feature (e.g., if you included PSC's SYN? cache, and said you had a SYN cache, then you'd have to admit that you didn't write it, PSC did). This is sometimes incorrectly called the "advertising clause" -- it isn't, though, since you don't have to mention features or use of the software in your advertising. Outside the boot path, the code can be loaded as a loadable module, so there's a lot more leeway as far as licensing. But if you wanted to replace the driver for the disk controller you are using, or the file system you are using or something else critical to the boot path (e.g. an ethernet driver, if you are net-booting), then there is the problem that it is no longer legal to distribute the code, under the GPL. Netscape, similarly, restricts the distribution of binaries for Netscape, except by themselves or licensees -- which is why we have both ports and packages, instead of just packages, and why some ports download intact binaries from their distributors. > If anyone has an interest in adding support for the SBS WAN cards to > FreeBSD, feel free to contact me. I'll be glad to help. The driver for these cards could be GPL'ed, and not impact FreeBSD. These drivers will not find themselves in the boot path. It also means that they could be binary-only... so long as they were kept up to date with kernel changes. The problems with a binary-only driver are somewhat more and less annoying at the same time: a binary driver that does not place license restrictions on redistribution or on the code it links with is no problem for the project. But there is not currently a lot of infrastructure for adding such drivers easily, and they can quickly become "stale", with evolution of the kernel code -- and the fact that the source isn't public means that it's impossible to intentionally avoid changing a kernel interface out from under it, to ensure the binary compatability is maintained between versions of the kernel. Doing this would also mean that the driver code could not be shared with other, similar devices. Perhaps this is the intent; if so, one should be certain that the trade-offs are worth it. It would probably be worthwhile to consider abstracting, as completely as possible, the code that can't be distributed as source code, and to make the code that depends on kernel interfaces public, so that the glue code could be changed by the FreeBSD community, as the FreeBSD kernel changes, without needing to chnage the core code, distributed as a shared object file. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BCEDAC4.3A7286D2>