Date: Wed, 08 May 1996 19:49:33 -0400 From: "Daniel M. Eischen" <eischen@vigrid.com> To: jkh@time.cdrom.com Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org Subject: Re: Copyright question Message-ID: <3191330D.41C67EA6@pcnet.com>
next in thread | raw e-mail | index | archive | help
J"org: > Just out of curiosity: what is MIL-STD-1553? It's a military standard data bus specification. Been around for years and used on a variety of different things from space shuttle payloads, to air transports and Apache helicopters, and in our lab at work. It peaks out at around 1 Mbit/sec I believe. MIL-STD-1773 is the same spec really, but over fiber-optic. The military likes it because it's capable of being dual redundant and deterministic in transmission times. I haven't heard of any new systems here at work that are using it though. The big push is now on COTS and ISO and industry standards. > > * 4. This code is only licensed for use with Condor Engineering, Inc. > > * interface hardware. > > I think this is: > > * redundant -- the driver is built for a Condor Eng. board, so it's > certainly unusable with a BusLogic SCSI adapter or a 3Com ethernet > card :) But the chip on the board is a United Technologies Corp M1553BCRTM chip and could be used on 1553 boards by other manufacturers. This is Condors concern, I believe. > > * impractical -- if we are allowed to ship the driver, but its actual > *usage* is restricted, who will ever care for the restriction? Agreed :) > (Anyway, i don't think it really restricts redistribution of the > source and/or binary code, so pending objections from more > knowledgable people, i think it's okay.) Terry: > If devfs and LKM were fully integrated, you could distribute it as > a binary loadable, no source required. This assumes that it's not > ever going to be used to run the console or other boot-critical > uses (ie: somewhat limited utility). Yes, Peter Dufault mentioned to me last year also. Peter gave me a lot of help when I had questions, and also reviewed the driver making some good suggestions. I'd like to see if I can get Condor to agree to release the source without any unliveable restrictions, though. Jordan: > 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. :-) If you don't mind, I'd like to forward some of this to Condor in my request for revocation of clause #4. Dan Eischen eischen@pcnet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3191330D.41C67EA6>