|
|
|
| Authored by: mcinsand on Wednesday, May 16 2012 @ 12:21 PM EDT |
The deal of a patent is <b>supposed</b> to advance technology by
getting information into the public domain sooner to advance the state of the
art. If an idea is really innovative, then it does also drive competitive
developments to try to find new, unanticipated technologies that will achieve
the same goals. I have personally seen this, where I was part of an effort to
find new technology that a competitor's issued patent did not anticipate or
cover. However, I work in the physical world.
One problem with this theory of patents advancing technology, though, is that
the laws were written before the information age. For that matter, they were
written when much of the population still couldn't read. Technology was on a
much slower development cycle so granting a couple of decades' worth of
temporary monopoly wasn't so bad of a deal for society at large to receive
full-detailed knowledge of new innovations. For something that is
development-intensive, it also allows for recovery of development costs. When
the law was written, getting the information documented and into the public
domain was faster.
If we forget for the moment how patenting language constructions and math are
just plain wrong, we can look at the society/governmental patent contract to see
how consumers and progress are getting the short end of the stick. Again,
forget that this is about language and math constructions, but think about the
development cycle and costs. Software patents slow (or stop) development,
rather than to advance it. Determining whether a patent is novel ahead of time
is also cost-prohibitively difficult, with billions of lines of code out there
and the amount exponentially increasing all the time. The result is that an
issued patent number is dangerous whether the patent is valid or not.
Challenging a patent is often much more expensive than licensing, so it can
become an extortion tool. And, we have plenty of examples from a certain
Redmond company.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 16 2012 @ 01:29 PM EDT |
At least part of patent reform must include restrictions on transferability.
Sun, is the Java innovator so only them should have patent protection. Oracle,
having acquired Sun, does not become the innovator. Therefore, they deserve no
patent protection.
And because it actually people in companies that innovate, patents should only
be granted to people.
This would completely eliminate patent trolls.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 16 2012 @ 01:33 PM EDT |
Patents, since Jefferson's time, have given the inventor a short-term legal
monopoly on the invention on the condition that the invention be made completely
public, and go into the public domain when the patent expires. Trade secrets,
another way to give an inventor a de facto monopoly, never expire, and could be
lost to history by circumstances unrelated to their value to society. Jefferson
took a long-term view. Our country gets more benefits inventions when they're
protected by patent than when they're trade secrets. Patents exist to reduce the
number of trade secrets.
Apply this to software. Are trade secrets in software acting as long-term
monopolies? I don't think so. I think it's darn hard to keep software a trade
secret. Amazon couldn't possibly keep its "one-click" as a trade
secret. (And the idea that Amazon would refrain from inventing
"one-click" if it couldn't patent it is just ludicrous.) Resolving
symbolic references at execution time couldn't be kept a trade secret.
Simulating execution of array-initializing bytecodes to make more efficient
intialization couldn't be kept a trade secret. I'm therefore of the opinion that
patents aren't needed in the software area.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, May 20 2012 @ 07:11 PM EDT |
The only Java products for which Sun was ever paid
(except in lawsuits)
were:
- The Java ME variants for older generation smartphones,
where Java ME was the only common (sometimes only, period)
programming
environment. The details of Sun's deals with
existing handset makers such as
Nokia, Ericsson and Siemens
made it difficult to add the incremental
improvements made
since Java 1.2 without breaking portability.
- The
Java variant ("JavaCard") included on-chip on
most upgradable security
chipcards, including (by standard
requirements!) the Subscriber Identity Module
(SIM) cards
that provide phone number and billing for all GSM-compatible
phones worldwide, from old 10+ pound clonkers to the latest
iPhone (same card,
movable from phone to phone). This
version is constrained by the physical
limitations of the security chips, the long term
certification and commitment
to each chip model (FIPS and
EAL certification, long term card printing
contracts with
carriers etc.), plus lack of imagination regarding ways to
provide missing
features, until Sun made the too bloated JavaCard 3, which I
consider a security liability due to some excess features.
- The Java
variant used in Blu-Ray video disk players as
the required method for
implementing on-disk menus etc.
So Sun was very willing and able
to deliver Java on
Mobile,
achieving more copies of Mobile Java variants
(first two
above) than PC copies.
JCP definition and Sun/OS
implementation of additional
APIs for Java Me was very much alive too, with
developers
and industry
groups actively tracking which phone models and
firmware
upgrades provided which additional JSRs, such as the ones
for GPS
position, touch screen support etc.
But the frustrating lack of access
to Java 1.2+ language
features was still annoying, and Sun had no real interest
in
competing against the mobile OS companies who were their
biggest paying
Java customers.
Their problem was that Google's wishes for an open
source, free as in beer and free as in freedom,
license would not
only have to be expensive to match what
others pay per handset, but would also
undercut the existing
deals, as non-Android handset makers could reuse the free
Android Java code without paying Sun for the privilege. So
Google's buyout
license would have to cover Sun's entire
Java for Mobile gross revenue, not
just the usual fee for
each Android phone.
[ Reply to This | Parent | # ]
|
|
|
|
|
