

One Small Leap for Open Source, One Giant Leap for Mankind - mickeyben
http://press.redhat.com/2009/10/01/one-small-leap-for-open-source-one-giant-leap-for-mankind/

======
fnid
What is the difference between software as a tool and something mechanical as
a tool? Mechanical devices, for which there are many patents, take a state of
matter and change it to another state of matter. Why should you be able to
patent a circuit board, but not a set of program code that does exactly the
same transformation to a set of bits?

Why are mechanical engineers able to patent their devices, but computer
engineers are not?

I understand the ramifications of software patents. But the problems with
software patents are the same for patents in _every_ other field. Why is
software special?

Why are we narrowing the conversation to software? Patents for software, like
any other field require research and development, they save time and money,
they make things more efficient, they improve life for countless individuals,
they do require risk, innovation, and yes _reward_ to survive.

That's what patents are for. They are to reward the risk takers. In the case
of software patents, the reward goes to the programmers who take the risk to
write all the code that will be patented. They aren't "abstract" ideas, they
are lines of code that are concretely typed into a computer. They convert
information from one form to another. They control the physical world in
previously unidentified ways.

To say software patents are invalid or software can't be patented really puts
software programmers at a disadvantage relative to other fields of science and
innovation. Why should pharmaceutical companies, civil engineers, mechanical
engineers, and all other disciplines have the right to patent their inventions
-- but not software engineers?

~~~
tsally
What if civil engineers could file a patent that looked like that following:

 _A method and system for crossing a body of water via a constructed object.
The customer starts on one side of the water and walks across the object to
the other side._

Your average software patent is roughly equivalent to a patent on the concept
of a bridge. If there are useful software patents, they've been overshadowed
by the large number of abusive ones.

~~~
miloshh
Are you sure that's the typical software patent?

Some famous law-suits were about patents that are far less trivial than your
bridge example.

For example, Pixar holds a patent on Monte Carlo sampling, and has sued or
threatened a number of companies that used any sort of randomization in their
rendering algorithms. This despite the fact that Monte Carlo methods have been
known and used for many decades before Pixar was started. The issue here is
not that the concept of Monte Carlo integration is trivial, but instead that
Pixar's contribution to it is so tiny compared to the previous state of the
art that it should not give them a "right" to own the whole field.

Similarly, some lawsuits were about compression algorithms if I remeber right.
Same issue here - it's not that a given compression algorithm is trivial, it
is more the fact that it is probably a tiny increment on the top of existing
compression techniques, and anybody that also builds on the known ideas should
not be threatened by loosely related patents.

Of course, patents are a problem that should be addressed, but I don't think
trying to prove that software patents are somehow different than others is the
right way.

~~~
anamax
> For example, Pixar holds a patent on Monte Carlo sampling, and has sued or
> threatened a number of companies that used any sort of randomization in
> their rendering algorithms.

Actually, Pixar has a patent on certain uses of randomization in rendering. In
patent-speak, randomization is the mechanism and rendering is the result.

I mention patent-speak because patents are the use of mechanism to accomplish
result.

Would you object to a patent on certain uses of a lever to close a gate?
(Ignoring novelty issues - closing gates with levers is well known now, while
using randomization in rendering was presumably new when Pixar did their
thing.) In patent-speak, the lever is the mechanism while closing the gate is
the result.

If not, then you're arguing that a lever as a mechanism is somehow different
from randomization as a mechanism. If so, you're pretty much arguing against
all patents (using mechanism to accomplish result).

~~~
miloshh
I'm mostly arguing against patenting trivial increments over non-trivial
ideas.

It has been long known that MC can be applied to computing any integral over
any domain, so computing the integral of color over a pixel is simply a
specialization of a general technique, and should not be patented.

Similarly, in akeefer's post above, storing insurance claims in a relational
database is a specialization of the well known process of storing _anything_
in a database, so should not be patented.

------
grellas
Open source proponents need to realize that, while it is possible for the
Supreme Court to enter a ruling making software non-patentable, this likely is
wishful thinking.

The authority for patent laws ultimately comes from the Constitution and finds
its implementation in statutes passed by Congress. There is nothing in either
the Constitution or in the existing patent statutes that expressly allows
courts to limit process or business method patents (the type at issue in the
case before the Supreme Court) to those that pass the so-called "machine-or-
transformation" test imposed by the lower court. Thus, it is by no means
assured that such a relatively narrow test will be upheld. If it is not, then
the looser standards likely will be back in play, meaning that a broad variety
of process patents (include software-related) will be capable of being
granted.

For those interested, this case has generated _huge_ interest in the tech
world and, as of a couple of months ago, at least 44 such companies had filed
briefs with the Court (for what it is worth, most of them favor rejecting the
lower court's ruling and thereby letting more process patents be issued). A
good summary of the positions appears here:
[http://www.patentlyo.com/patent/2009/08/briefs-in-
bilski.htm...](http://www.patentlyo.com/patent/2009/08/briefs-in-bilski.html).

I am not saying that software patents shouldn't be abolished - just that such
a result is highly unlikely to come from any ruling in this case.

~~~
cabalamat
> I am not saying that software patents shouldn't be abolished - just that
> such a result is highly unlikely to come from any ruling in this case.

You're probably right. The best way for a person to help get software patents
abolished, IMO, would be to join their local Pirate Party -- <http://www.pp-
international.net/>

~~~
cookiecaper
Heh, no it's not. That'll just get you marked a radical and summarily ignored
by anyone with power. Not that I agree with that, but that's how things are.

The _real_ way to get software patents taken care of is, as with any other
matter of public policy, to convince large swaths of major, consistent
contributors to the campaigns of your incumbent representatives to press the
issue.

This will probably be difficult because people with money want to do evil with
these patents and they will just counter your pressure, though there is some
hope that the big players will decide that software patents are too dangerous
altogether if a few more injunctions like the one against the sale of
Microsoft Word come out (see i4i v. Microsoft). But right now, Microsoft is
trying to use its patents to neuter its open-source competitors, so they may
value that too highly. We'll have to see!

~~~
cabalamat
(on joining the Pirate Party)

> _Heh, no it's not. That'll just get you marked a radical and summarily
> ignored by anyone with power. Not that I agree with that, but that's how
> things are._

The Pirate Party already has one MEP. If (probably when) the Lisbon Treaty is
passed, they'll have two. The Pirate Party will probably _be_ in power in
several countries over the next 10 years (as part of coalitions).

> _The _real_ way to get software patents taken care of is, as with any other
> matter of public policy, to convince large swaths of major, consistent
> contributors to the campaigns of your incumbent representatives to press the
> issue._

This might be true in the USA under their current political system. But as you
imply from what you say, the USA isn't properly a democracy, it's an oligarchy
ruled by corporations. This is in fact a bigger problem than software patents.

It isn't true in Europe, where Pirate Parties have a siginificant chance of
getting people elected, due to using more democratic electoral systems.

If Pirate manage to get software patents abolished or neutered in one major
jurisdiction, they will probably indirectly win in the rest of the world.

> _This will probably be difficult because people with money want to do evil
> with these patents_

I agree.

> _But right now, Microsoft is trying to use its patents to neuter its open-
> source competitors, so they may value that too highly._

That's certainly part of Microsoft's plan for their patents.

------
yason
While reading these comments, someone quoted well that: "The intent of patents
is to get inventors to disclose their inventions to the public for the benefit
of all." This sounds like a good principle. Instead of applying the
traditional patenting method to software, we should find the equivalent of
that principle in software world.

So, patents apply to implementations, right? Also, code itself is the design,
right? And yet, so far we try to describe the implementation with vague words
of mostly English language, and to bend the boundaries by making it as broad
as possible. Doesn't seem to work too well.

In real world, you can patent an implementation of a bridge -- effectively the
design of its construction if it's novel. You can't patent the underlying,
generic bridge-construction principles. Code is design.

I think the principle could apply analogously to software patents by opening
the source of a proprietary implementation, and then licensing
interoperability with the patented implementation. In other words, that spells
like kind of a code-escrow for an exclusive licensing rights for limited time.

The patent would only apply to forks or third-party implementations that are
compatible with the patented implementation. If you invent a clever protocol,
you could require money for compatible implementations: this would hopefully
incentivize opening proprietary implementations.

On the other hand, if someone takes your ideas and builds his own
implementation, you would not be entitled to anything: that someone will be
required to build his own market share, compete with your implementation and
user base from the ground up, and effectively do the same work that you have
already done -- just to get on par with you.

Complete codebases and unit tests could be required to make it easy to verify
the compatibility or incompatibility of programs potentially based on the
patented codebase.

Reviews for novelty would be much easier to arrange if expert programmers
could study the working code and compare it to earlier implementations. That
is, as opposed to lawyers trembling with the words and semantics of patent
applications.

