Potential patent issues

Daniel Gibson metalcaedes at gmail.com
Fri Jan 21 13:37:17 PST 2011


Am 21.01.2011 21:55, schrieb Don:
> spir wrote:
>> On 01/21/2011 03:51 PM, Don wrote:
>>> Don wrote:
>>>> BlazingWhitester wrote:
>>>>> I spotted some patents that can theaten current DMD implementation.
>>>>> Wanted to clarify things.
>>>>>
>>>>> http://www.freepatentsonline.com/6185728.pdf - this patent describes
>>>>> method pointers implementation (delegates)
>>>>
>>>> This was obviously a patent aimed at protecting Delphi from VB. It's
>>>> all about the RAD designer: visual connections between GUI elements
>>>> and events has a 1:1 correspondence with code; delegates are used to
>>>> achieve this.
>>>>
>>>> D delegates can store a data pointer to a nested function, or to an
>>>> object. This is rather more general (not an object-oriented feature),
>>>> and doesn't provide a 1:1 correspondence to visuals.
>>>> I presume they were only able to satisfy the requirements for novelty
>>>> and non-obviousness, because of the RAD usage. In fact, there doesn't
>>>> seem to be any suggestion that delegates would be used for anything
>>>> else.
>>>> The more general idea of storing a data pointer and a function pointer
>>>> together is simple and obvious, and surely has prior art.
>>>
>>> D's delegate scheme is essentially the same as described by Richard
>>> Hickey, "C++ report" (Feb 1995).
>>>
>>> See also a discussion on comp.std.c++, Feb 1996, titled "Generic Object
>>> Callbacks". Ian Willmott states:
>>> "I suggest that a new data type needs to be added to the language. We
>>> could call it "pointer-to-bound-member-function".
>>> ...
>>> Conceptually, it is a two-element structure consisting of
>>> pointer into data space, identifying an object, and a pointer into
>>> code space, identifying a member function on that object. The static
>>> type of such a variable is the signature (return type and arguments)
>>> of the member functions it is compatible with, just as the type of a
>>> regular function pointer is the signature of the functions it can
>>> reference. The only operations defined for this type are assignment,
>>> equality, and callthrough. Static typechecking is done at the point
>>> where a value of this type is created, and where a call is made
>>> through it. "
>>>
>>> Borland's patent dates from Feb 6, 2001. They were SIX YEARS too late.
>>> <g>
>>
>> IIUC, the structure you describe is /exactly/ the same, both
>> concretely and semantically as Oberon-2 "type-bound procedures" (read:
>> virtual methods). Oberon-2 was created in 1991, IIRC. This makes 10
>> years ;-)
>> Unlike you, I don't consider D's delegate to follow the same scheme.
>> Sure, it's a pair of pointers, one of which point to a routine (to use
>> a neutral word). But in the case of D the second one does not point to
>> to a type/object, but to the definition scope (environment). This is
>> very different, isn't it?
>> Thus I would consider D to not even be concerned by the patent. If you
>> use a 3-integer struct to store a color, do you have to pay royalties
>> to the owner of a patent about a 3-integer struct used to store a
>> position? Indeed, lawyers...
>
> Yeah. I think we can be certain that that patent has zero risk for D.
> On the positive side -- I think that the rise of public source
> repositories (with complete histories) means that public disclosure has
> become much more common (factor of 1000 or more) than the days when
> these junk patents were issued.
> That doesn't help.
> Imagine you're a patent examiner, who has to work out if a particular
> code idea has been previously published. How can you be confident that
> it doesn't already exist in the billions of lines of open source code on
> the web? And how much would you charge someone who asked you to check
> them all?
>
> I used to be quite depressed about software patents, but now I just
> don't think they are workable. The prior art is just growing too fast.

I don't think this makes patents much less of a harm.
1. There are still these old patents around from the times not much free 
prior art was around for checking. If they fall in the hands of the 
wrong people they still can do much harm.
2. New software patents are issued anyway - by big corporations who have 
a lot of money and lawyers.
If they claim that you infringe their patents you're probably screwed 
anyway.
When you're living from selling your software (like a small software 
firm), they could get your products removed from the stores (this has 
even happened to Microsoft because of some XML patent their OOXML 
infringed) and you're bankrupt before you can have the patent 
invalidated because of prior art (this whole process probably takes 
years..).
If you're just a hobby developer you may have even less money for legal 
defence than small companies..

So while in theory probably most patents could be invalidated because of 
prior art, I guess that in reality this won't happen because the patents 
owners have more money and lawyers.
Also I *think* that the european patent system doesn't even care about 
prior art..

When you're dealing with very recent technology (like newest 3D 
hardware), it may even happen that you "discover" some algorithm that 
someone else discovered and patented before you and really happened to 
be the first one to discover it (or at least the first one to publish 
it). This has happened to John Carmack, see 
http://en.wikipedia.org/wiki/Shadow_volume#Depth_fail

IMHO when you have a specific (algorithmic) problem and you let 10 smart 
programmers solve it independently, you have a high chance that you'll 
get several similar solutions.. so it makes no sense to patent software, 
because other people are likely to have the same idea independently.
It's not like developing new medicine that may take years and high costs 
to be done, so it *may* make sense to protect it from rip-offs.
(Yeah, developing software can take years as well, but there's copyright 
to protect this - developing a clone takes almost as long when you don't 
steal code).

Cheers,
- Daniel


More information about the Digitalmars-d mailing list