From owner-freebsd-hackers Wed May 8 15:27:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA00649 for hackers-outgoing; Wed, 8 May 1996 15:27:42 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA00643 for ; Wed, 8 May 1996 15:27:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id PAA25442; Wed, 8 May 1996 15:27:01 -0700 (PDT) To: eischen@vigrid.com (Daniel Eischen) cc: freebsd-hackers@FreeBSD.org Subject: Re: Copyright question In-reply-to: Your message of "Wed, 08 May 1996 17:58:27 EDT." <9605082158.AA09404@pcnet1.pcnet.com> Date: Wed, 08 May 1996 15:27:01 -0700 Message-ID: <25439.831594421@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'll try to see if I can get rid of clause 4, but I don't think > they're going to let it go without some sort of clause. Is there > anything we can do? Add a comment in LINT saying it's restricted > by copyright? Or point to a file from within LINT that will list > the restricted driver(s)? As long as the user sees the copyright > restriction before he rebuilds the kernel with the driver, right? Well, yes, that would sort of do it - you could have a one-liner in LINT saying "Only for use with Condor boards, please see /sys/i386/isa/condor.c for licensing restrictions" or something. But I'd also like to suggest that we perhaps attack this problem from a different angle. What is Condor trying to achieve here? Protection of sales, right? More to the point, they'd like to sell this board to FreeBSD users as a consequence of having this driver in FreeBSD by default, assuming that they might be less willing to do so otherwise. The "protection of sales" issue is also actually a secondary one since, up to this point, there _are_ no sales to protect. So far, so good. NOW.. What influences a user's decision to buy one board over another? Several things: One is naturally the cost, though in certain markets (and I suspect this is one of them) this is less important than reliability. Another is word-of-mouth - what are people suggesting they buy? This works pretty well, or vendors wouldn't be climbing all over one another just to get Jerry Pournelle to mention them in BYTE. It's my suggestion that we try and convince Condor that they've no existing market to protect here, nor will the eventual market size likely be anything to lose sleep over, and they don't need to protect their revenue in this fashion. What we can give them as incentive to play by these more relaxed rules is some free PR and a commercial entry on our web pages (along with a mention in my announcement text for the next SNAP and the eventual 2.2 release, etc and so forth). I'd mention them anyway, naturally, but a willingness to play ball on their part will be incentive for me to mention them in a lot more places. :-) In other words, what they potentially lose in "protection" we'll try and make up for with some good word-of-mouth advertising since they've proven themselves to be such good guys (and gals). It's my feeling that people will then buy what they've seen mentioned, and if it doesn't say "supports condor and condor clones" on the web pages, then they're going to buy a condor rather than end up with some useless clone piece of junk that doesn't even work. On the flip side, those people who *do* decide to buy clones anyway (perhaps due to their own testing) won't be deferred by clause 4 as it's almost entirely unenforceable anyway. We're not Microsoft. :-) Jordan