Date: Fri, 17 Mar 2000 15:45:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Cc: tlambert@primenet.com (Terry Lambert), noslenj@swbell.net (Jay Nelson), freebsd-chat@FreeBSD.ORG Subject: Re: The Merger, and what will its effects be on committers? Message-ID: <200003171545.IAA16366@usr06.primenet.com> In-Reply-To: <xzpaejy3sw9.fsf@flood.ping.uio.no> from "Dag-Erling Smorgrav" at Mar 17, 2000 09:25:26 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Let's please not have this discussion in public. No problem; I won't, if you won't. > > 2) Given that BSDI has binary-only drivers, the source for > > which can not be released because of NDA, are the binary > > object files, linkable to a FreeBSD kernel using the > > process outlined in #1, going to be made available for > > use in FreeBSD? > > Why should they? If they were written by BSDI employees, spending BSDI > money, I see no reason why BSDI wouldn't be allowed to keep them > proprietary. That's the whole point with using the BSD license instead > of the GPL. The point is that, if a driver already exists in BSDI, and FreeBSD becomes the public shadow of the BSDI source tree, there is very little incentive to write a new driver among volunteers, because the job has already been done, and there are interesting things to write that haven't yet been done. Given a choice between writing something that has already been written by someone else, and writing something new, I believe that a volunteer will always choose to do the new thing. I can give relevent FreeBSD examples for this: o There is not BSD licensed FPU emulator o There is no UDI support in FreeBSD o For execution classes for other OSs, the OSs native libraries are used to achieve compatability, instead of having written ABI equivalents o There are still drivers missing in the new SCSI code that were supported under the old SCSI code o After licensing the Telenetworks ISDN stack, Whistle has not maintained its home-grown ISDN stack, which it could have released under BSD license I'll stop here, so as to not waste my entire morning citing examples; you get the point by now. I believe that the existance of a BSDI driver for something will implicitly discourage the developement of a FreeBSD driver for the same thing. This concept is not limited to drivers, however, since it must include things like the login.conf code, which was only recently, relative to its lifetime, released to NetBSD by BSDI, and then only after FreeBSD had practically reimplemented it, forcing their hand. > > 3) Given new hardware under NDA, when the hardware is no > > longer under NDA because the Linux camp have done our > > jobs for us, and gotten documentation released, or have > > written a driver without documentation, will the NDA > > driver then be released? > > That's up to BSDI. IMHO, they'd be stupid not to, since they'd then > have to keep maintaining it (at a cost) when it no longer gives them a > commercial advantage because competitors can write equivalent or > better drivers, so it'd simply make good business sense to release the > driver and let the teeming millions (aka. the FreeBSD committers) > maintain it for them. If the Linux camp writes the driver without documentation, there are a couple of holes in your thesis: o The drivers which can be written are not necessarily equivalent, or even capable of being equivalent o The BSDI drivers may disclose NDA information in the comments, manifest constant or variable naming, or even the structure of the code o The BSDI drivers may contain vendor-supplied code, such as the Adaptec HIM layer for supporting RAID using the Adaptec RAID sequencer microcode So even if BSDI wished to release this code, they may be legally prohibited from doing so. This once again begs the question of binary BSDI drivers being used by FreeBSD; it further raises the question of maintenance of the code, in the face of interface changes, since each interface change would require a rerelease of the BSDI binary code, which we would have to trust to occur, at perhaps large expense to BSDI, and for hardware which has been potentially marginalized to the point that it's not relevent to their market any more. And to support this, we still have to have the ability to link binary drivers from BSDI into FreeBSD at kernel creation time, even if all other obstacles are swept away. I suspect that the pressure of Linux on BSDI will not be so compelling a goad as the pressure of another BSD on BSDI. Consider also that a Linux driver, even one written with full documentation, will not remove the NDA agreement; a contract is a contract, as Public Key Partners can tell you. Finally, say we get to an impasse, for whatever reason, and BSDI doesn't release the driver in binary or source form at all. Is this a "fork event" for the combined source trees? The tools in use, i.e. CVS, do not support the concept of concurrent lines of developement; there's no "Julian SLICE code" LOD in FreeBSD, and the tools make it difficult for different technologies to compete under a single FreeBSD umbrella, with the best technology winning by virtue rather than by the need to prune one away to accomodate the tools imposition of the rule "there is only one -current". A pruning as a result of fiat by the tools means that the most mature, not the most virtuous, technology will winn the battle. Likewise, maintaining patches in the face of a moving source tree is a daunting task. How much better off would we be now, if a "FreeBSD + netgraph" LOD had been available ever since netgraph was operational, as opposed to the anti-bloat driven requirement that it not be integrated into "the one -current" until there was obvious utility other than to its author? Ask Julian how many cycles he wasted, tracking an unnecessarily moving target, when he could have been working on modules with obvious utility, such as the PPOE module, which is the only way some FreeBSD users can use FreeBSD and a cable modem at the same time. I'm not trying to pound on you here, I'm only saying that there are issues that need to be addressed. I'm not even claiming that my answers, where I've given my opinions, are the correct ones: only that answers are needed. > > 4) If the answer is "no", then will the powers that be permit > > a driver written using the Linux driver as a reference to > > be committed to the FreeBSD tree, as has occurred with > > other drivers in the past? > > Why shouldn't they? How is BSDI going to stop a FreeBSD committer from > committing such a driver to the tree? What makes you think BSDI will > have dictatorial control over FreeBSD development? They won't. I believe it's an emergent property of the tools. It's not by choice that this would happen; I believe there are good people involved, but even good people can become victims of circumstance. > The alert reader will notice that the objections you've raised in > questions 1 through 4 are the classical objections GPL advocates > always raise against the BSD license (claiming that distributing > software under the BSD license allows commercial vendors to hijack the > software), and that the answers I've given you are the classical > replies from the BSD advocates. No. We are arguing a different set of issues than that. I am one of those BSD advocates. GPL advocates argue that "hijack" is an emergent property of any license _other than the GPL_. It can be proven using games theory models and monte-carlo that that argument is false. The BSD license is not at issue; its a linear Richardson mutual security game, and companies that recognize the difference between tactical and strategic decisions will give code back to any public project, regardless of whether or not there is a license forcing them to do so. > > 5) Say a division of IBM uses FreeBSD, and a driver for > > IBM hardware is written under NDA, and the answer to any > > of #1, #2, or #3 is "no". Will the division of IBM be > > forced to use BSDI, or not have a driver for hardware > > obtained from a different division of IBM, with which the > > first division has no political clout? > > I don't quite follow this. Who, in this hypothetical scenario, > actually wrote the driver? An IBM employee. The point at issue is whether or not there is an investment in FreeBSD to permit it to use binary-only drivers for boot devices, i.e. linked into the kernel instead of dynamically loaded, and whether such an interface would be compatible with linking BSDI binary-only drivers in exactly the same way. IBM could allow publication of the ".o" file, but if FreeBSD were not arranged to be able to handle using it for a build, the release would be meaningless. One could also consider the case where BSDI has written a driver for the same hardware, but by virtue of a superior understanding of kernel internals, their driver is better (e.g. perhaps their driver is kernel reentrant, or multithreading safe, or whatever), but BSDIs driver is not availble to FreeBSD because it's one of the proprietary BSDI components. 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003171545.IAA16366>