From alsa-devel-owner@alsa.jcu.cz  Tue Mar  2 18:12:33 1999
Received: from linuxmaster.corel.eng (internet.corel.ca [209.167.40.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA14503
	for <alsa-devel@alsa.jcu.cz>; Tue, 2 Mar 1999 18:11:14 +0100
Received: (from news@localhost)
	by linuxmaster.corel.eng (8.8.7/8.8.7) id MAA02352
	for alsa-devel@alsa.jcu.cz; Tue, 2 Mar 1999 12:10:38 -0500
From: uo3fieoe@umail.furryterror.org (Zygo Blaxell)
Subject: Re: (SB Live) Free drivers or not? (fwd)
Date: 2 Mar 1999 12:10:29 -0500
Message-ID: <7bh625$thq$1@naga.corel.eng>
References: <m10HHZG-000sLNC@lbscissors.kek.jp> <36DB61F4.9BD170DD@mediaone.net>
To: alsa-devel@alsa.jcu.cz
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

In article <36DB61F4.9BD170DD@mediaone.net>,
root  <alsa-devel@alsa.jcu.cz> wrote:
>We don't want to scare any innovation away from linux.  

Which is why we want only source in the long term.

>If a developer wants to be paranoid and squeeze every IP $ out of their
>product that is their problem.

_Their_ problem, not _ours_.  Binary compatibility is good in that
it means that the code is more convenient to use--it takes time and
space to recompile gigabytes of binaries from source code unnecessarily.
However, use of that compatibility between releases to release binary-only
proprietary software is IMHO simply abuse of goodwill.

>For the most part a binary only developer should be more fearful of the
>incarnations of redhat, debian, slackware and so forth than the kernel.
>
>They have caused me more "compatibility" problems than running a devel
>kernels.

True.  I'm still running programs I compiled in 1994 on Linux kernel
2.2.2 with a lot of binary compatibility modules and libraries (not part
of Red Hat, of course, which only came into existence some years after
these libraries were generally accepted as "obsolete").  During that
time there have been more than 100 revisions and three _rewrites_ of the
runtime libraries (DLL/.so/whatever) _and_ 300 or so kernel revisions
and one _binary format_ change.

I can even run some proprietary binary-only software from 1993 on Red
Hat 5.2 with Linux kernel 2.2.  It crashes and hangs randomly, of course,
but then again it crashed and hung randomly in 1993 as well.  That's
just binary-only software for you; I could fix it if I had the source.

>It is not much different from NT service packs (in fact much better
>because you see it coming and you can look at it to see EXACTLY how it
>impacts you).

And pick and choose which parts of the service pack you want, instead of
taking all of the bugs with any of the fixes.

>I have seen quite a lot of hostility to developers testing the waters
>who have not yet grown comfortable with open source.  This is bad for
>linux and bad for open source.

Hostility toward the _developer_ is harmful, but hostility toward
_binary-only software_ is not.  This notion that binary-only software
is healthy and normal must die before it becomes too entrenched.

Compilers are intended for performance optimization, not as devices for
protection of intellectual property.

>New binary only developers should be told that:
>
>1. Yes! things change in fundamental ways in the kernel and the "OS"
>such as it is, but generally for good reasons and in a sensible manner,
>not every week.  NT service packs do much the same thing in a harder to
>track manner.

Actually things _do_ change every week.  On the other hand, the changes
are usually very small, have isolated, well-defined effects, and they
are usually optional (although you do have to catch up to progress every
year or two).  "Hmmm...  the device driver for the BogoFlops 1000 Arcnet
driver was updated this week.  Total impact on my organization: Zero.
Also updated this week was a security patch for ftpd.  Total impact on
my organization:  Emergency!  Install this on everything we can right
now and turn off the rest before they get cracked!"

In other words, implementations change every week, interfaces every
year or two.  The impact this has on you depends on your coding style.
If you tend to rely on implementation bugs and not on documented
interface behavior, then you will be screwed.  If you find a bug in the
implementation, the best long-term strategy is to get the implementation
fixed by submitting a patch that fixes it to the maintainers; if you
don't fix the problem, someone else will, and if your code relies on
the unfixed behavior then it will break.

>3. If you release a neat package in binary only, be prepared for some
>bored college programmer/group to mimic it.  

Oh yeah.  I don't know how many little programs I've written in a fit of
rage just because someone dared to try to charge me $10 for a shareware
version.  Sure, it's not worth 8 hours of my time to re-implement a $10
shareware app, but it's _really_ satisfying to mail the source code of
that re-implementation to the author and watch them scream bloody murder.
;-)

Also note that binary-only packages are _only_ an inconvenience.
Your real intellectual property protection comes from copyrights and
(ugh!) patent law.  Everyone who really wants to steal your code will
just reverse-engineer the binary anyway, and they have the knowledge 
and tools to do it.  The dark side of the Force (i.e. warez crackers)
do this all the time, and they usually try to get it done within the
first 24 hours after release.

Consider what would happen if you released the source code of your
application under a non-open-source license (i.e.  source licenses which
basically allow you to read the source code and make binaries out of it
but not redistribute the source code itself).  Your competitors would 
derive exactly the same benefit from that code that they would if you
didn't release the source at all--they'd be in serious legal trouble if
they "borrowed" your code without permission, so they won't.

>BUT please do offer your package in linux!!!

And of course just because _I_ won't like your package (or any other
binary-only package) doesn't mean that there aren't millions of users
who _will_ like it.  ;-)

-- 
Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
zblaxell@furryterror.org (play).  It's my opinion, I tell you! Mine! All MINE!
Size of 'diff -Nurw [...] winehq corel' as of Tue Mar  2 11:14:00 EST 1999
Lines/files:  In 4440 / 4, Out 13185 / 221, Both 17550 / 223

