[lug] Software patents

[Nate Duehr]

On May 30, 2009, at 8:25 PM, Rob Nagler wrote:

> Lawyers will be the first to tell you that if the judge
> has a bad day, you could lose your case when you thought you had an
> 80% chance of winning.

Isn't that the biggest problem of them all?  Consistent, economical  
court decisions (appeals cost a lot of money) sure would be nice, but  
not in the best personal interests of the Judges, Lawyers, or the  
American Bar Association -- nor most of the ex-or-current-lawyer  
politicians who make laws.  Never ending treadmill that there's no  
good motivation on the parts of any of the participants to fix...

> Big companies rarely sue small companies for infringement of anything.
>  It's just not worth their while unless there is serious money on the
> table.  If a big company sues you (e.g. RIAA or MPAA), you had better
> have very deep pockets or the EFF on your side.  It has nothing to do
> with right or wrong or "justice".  It has to do with how well you can
> follow the legal process.  Pay good lawyers and/or settle.

Continued comment here on the American legal system today, "You can  
have the most justice your money can buy."  Sad reality.

> I was a long time member of the LPF.  I have never gotten a patent,
> even when offered money by my employers to get one (my co-workers
> applied for the patents, and got the cash, and were happier).  I run
> an open source company.  I am technical director of an open source
> non-profit.  I run a dot-com which is still in business, which runs a
> proprietary web-app, but we probably could open source the app if it
> was worth the time to do so.  I believe that open source will win, and
> classical IP-oriented companies will fail (look at Sun).   Even The
> Economist proclaimed this week that "Open-source software has won the
> argument."


One could argue that Sun "failed" (technically they're still alive  
under the Oracle banner now, whatever that will bring) because their  
hardware, although FAR better than the average "pizza box" was always  
marginally more expensive, and people didn't see the value in the  
better-engineered machines, and also because OS's themselves have  
almost become a commodity.  Whether that's because of open-source, is  
probably not debateable, Linux has killed proprietary Unix in all  
situations where accurate and serious certification testing isn't  
required.

Linux on the desktop is still mostly a bust, but Linux on the server,  
is something where the copy-cat OS was able to copy all the marginally  
required features of other OS's who developed the ideas first, and  
therefore open-source eats away at the profits of those who came up  
with the ideas.

Sun's hardware division died the day they decided to play in the pizza  
box cheap-ass computer game.  Quad processor Enterprise V480 or a  
Netra 440 were computers designed to run and still be able to do their  
jobs more than 10 years from the purchase date.  If you're amortizing  
over 7 years... they're cheap.  Pizza boxes are typically swapped  
right at the 7 year amortization schedule, if they're not dead  
sooner.  I still see Ultra 2's and Ultra 5's doing PRODUCTION jobs at  
customers... and their replacement plan literally is a pile of them  
from eBay... $100 will get them four spares these days.  The original  
Sun/SPARC hardware was just built better than anything in the lower  
price points that are so popular today in data centers.  (Same thing  
with HP/HP-UX boxes and IBM/AIX boxes in their respective times,  
also... IBM and HP are still duking it out...)


> I don't think there's any substitute for hard work.  I spend as much
> time as possible writing tests and code.   The tests are the hard
> part, the code is easy.  Most companies (open source and IP-oriented)
> don't think tests are worth their time.  I strongly disagree: Tests
> are the only intellectual property that matters.  This little secret
> keeps my companies under the radar and out of IP lawsuits (for the
> most part :-).  We're just too small for anybody to bother with us,
> and we can stay small because we have so many tests.  If we were
> threatened with a patent lawsuit on a particular software technique
> (not a business process, that's a different can of worms), we can
> simply rewrite our code and use our "real IP" (the tests) to verify
> that the new and different code works.


Not a bad way to tackle it.  Interesting.  Thanks for sharing that.


> Every software problem can be solved through another layer of
> indirection, even software problems created by IP lawsuits.


That's sad, since that just adds more unnecessary complexity to  
machines that are dumber than the average automobile when you look at  
their mechanical make-up.  Taking something as simple as a computer  
and layering on so much complex software that the owner can't possibly  
find their own people to maintain that software is the basis of the  
whole "IT industry".   Not exactly very empowering for the owner of  
the technology... they *must* buy that complex software (as do their  
competitors) to stay competitive since the software company is also  
selling to their competition.  That's a large undercurrent in software  
development today -- with only a few examples a year of anything truly  
innovative.

Companies that write proprietary systems internally, instead of  
relying on software vendors, so often do it wrong/badly that article  
after article gets published about their "failures until they decided  
to use brand X software"... but if everyone relies on Brand X... no  
one gets ahead of their competition... well, unless they teach their  
people to operate/use it better.

Now knowing the irrefutable truth that knowing how to use the complex  
software better than the next guy using it is the key to whippin' up  
on the competition -- when was the last time anyone here's employer's  
spent any time/money/effort beyond a single day overview course  
MAYBE... for software OPERATION training?  I haven't seen basic  
computer operation training done in a formal setting since the late  
1980's.

But you can't tell me that it wouldn't help...

--
Nate Duehr
nate at natetech.com