Re: Potential patent issues
On Sat, 2011-01-22 at 15:54 -0500, Jean Crystof wrote: > Nick Sabalausky Wrote: > > > I've been under the impression that, as a rule, the USPTO doesn't check for > > prior art and deliberately leaves "invalid due to prior art" up to the > > courts. > > That's how it works. The patent threat is always there. Someone can > patent delegates, classes, and whatever language feature whenever they > want. In the courts if Walter is much poorer than the competitor, he > can't win. The SCO case was a great example. They didn't own the Unix > rights and couldn't find any patent infringing code. Nevertheless, the > Microsoft money kept them fighting. If Apple or Microsoft wants to > compete with Walter, he simply can't win. Isn't this why the US system of software patents is wrong? "Big Money" keeps insisting that the whole patent system is designed to allow people who have inventions but not the resources to exploit them, a route to obtaining remuneration by allowing others to do the exploitation. This has always been a specious argument. Even if it were not, and whatever the original use of letters patent that led to the patent system, this system, especially in the USA, has turned into a business tool for "Big Money" to ensure control of all exploitation is handled by "Big Money". To preserve power in the hands of "Big Money" the patent system has been evolved into a game that only "Big Money" can play, small players are systematically excluded. (Of course, lawyers are the only real winners as they get paid win or lose.) Where the invention is something that can only be exploited by there being something physical that must be manufactured, then there are arguments that patents are a useful tool. Where the invention is a business process or a software technique (or a user interface technique?) then I don't see that it serves any purpose other than preservation of control by "Big Money" over innovation. The exact opposite of the avowed purpose of patents. I have yet to see how business processes, algorithms, and programming techniques are anything other than ideas or mathematics, and ideas and mathematics are supposed to be not patentable. As far as I am aware the UK Patent Office still does not issue software patents, though the EU Patent Office, seems to have started to try, under pressure from "Big Money" I suspect. (I agree it is easy to blame US companies and ignore the fact that European and Asian companies are part of the cartel when Microsoft, IBM, HP, etc. are the easy names to roll off the tongue, so "Big Money" here does not mean large US corporate.) Sadly, the Anti-Counterfeiting Trade Agreement (ACTA -- cf. http://en.wikipedia.org/wiki/Anti-Counterfeiting_Trade_Agreement) appears to have been somewhat hijacked by US "Big Money" via the US Trade Representative (USTR -- cf. http://www.ustr.gov/) as a tool for imposing the US way of patents onto the rest of the world (*). This means software patents will have to be granted everywhere that ACTA applies. No matter how much lobbying the FLOSS community do, I bet "Big Money" will not fail to sieze the opportunity to ram through the whole "software techniques are not ideas, they are patentable" philosophy. Perhaps then the only defence these days, especially in the USA, and sadly if ACTA is signed into place, the rest of the world, is to be a signatory to the Open Invention Network (OIN -- cf. http://www.openinventionnetwork.com/). However appealing though, even this is just a tool for "Big Money" since only by having significant resources can you actually patent something that you can then magnanimously donate to the OIN patent pool -- have you noticed that "Big Money" is very selective about which patents get donated and which don't? So it seems the only hope for small players to do any innovation, indeed any work, in the software arena, is to be ignorable by "Big Money", i.e. do stuff that doesn't matter or doesn't constitute a threat to "Big Money". Either that or the policitians of the world spontaneously see the light, that they are being herded by "Big Money", and disallow software patents forever. All in all though it seems the days of the small independent software development organization doing anything innovative are strictly limited. (*) You might want to follow Simon Phipps (Wild Webmink) on this http://webmink.com/2010/03/19/acta-roundup/ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Potential patent issues
Nick Sabalausky Wrote: > I've been under the impression that, as a rule, the USPTO doesn't check for > prior art and deliberately leaves "invalid due to prior art" up to the > courts. That's how it works. The patent threat is always there. Someone can patent delegates, classes, and whatever language feature whenever they want. In the courts if Walter is much poorer than the competitor, he can't win. The SCO case was a great example. They didn't own the Unix rights and couldn't find any patent infringing code. Nevertheless, the Microsoft money kept them fighting. If Apple or Microsoft wants to compete with Walter, he simply can't win.
Re: Potential patent issues
"Don" wrote in message news:ihcrve$1t5l$1...@digitalmars.com... > 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. >>> >> >> 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. > > 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've been under the impression that, as a rule, the USPTO doesn't check for prior art and deliberately leaves "invalid due to prior art" up to the courts.
Re: Potential patent issues
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. 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 disc
Re: Potential patent issues
Am 21.01.2011 21:31, schrieb spir: On 01/21/2011 09:18 PM, Daniel Gibson wrote: You're thinking of closures (which are also "delegates" in D), but D's delegates can also be used to simple point to a member of an object. It's kind of hidden in the definition: "Delegates to non-static nested functions contain two pieces of data: the pointer to the stack frame of the lexically enclosing function (called the frame pointer) and the address of the function. _This is analogous to struct/class non-static member function delegates consisting of a this pointer and the address of the member function._ Both forms of delegates are interchangeable, and are actually the same type: [...]" Thank you for the information, Daniel. You are right: I didn't even know "delegate" is used in the second sense. Then, what is he difference between a delegate in the second sense and a (non-static) "member function" (I mean a method)? Or is "delegate" the name of the data structure (implementation side) and "member function" or "method" the name of what it holds or means (semantic side)? Denis _ vita es estrany spir.wikidot.com A delegate is like a function pointer to a method. So like a function pointer is not a function a delegate is not a method ;) See also Steves code example. Cheers, - Daniel
Re: Potential patent issues
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. 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. 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.
Re: Potential patent issues
On 01/21/2011 09:18 PM, Daniel Gibson wrote: You're thinking of closures (which are also "delegates" in D), but D's delegates can also be used to simple point to a member of an object. It's kind of hidden in the definition: "Delegates to non-static nested functions contain two pieces of data: the pointer to the stack frame of the lexically enclosing function (called the frame pointer) and the address of the function. _This is analogous to struct/class non-static member function delegates consisting of a this pointer and the address of the member function._ Both forms of delegates are interchangeable, and are actually the same type: [...]" Thank you for the information, Daniel. You are right: I didn't even know "delegate" is used in the second sense. Then, what is he difference between a delegate in the second sense and a (non-static) "member function" (I mean a method)? Or is "delegate" the name of the data structure (implementation side) and "member function" or "method" the name of what it holds or means (semantic side)? Denis _ vita es estrany spir.wikidot.com
Re: Potential patent issues
Am 21.01.2011 21:20, schrieb Steven Schveighoffer: On Fri, 21 Jan 2011 15:18:46 -0500, Daniel Gibson wrote: On Fri, 21 Jan 2011 15:18:57 -0500, Steven Schveighoffer wrote: Damn, beat my by 11 seconds :) -Steve *g*
Re: Potential patent issues
On Fri, 21 Jan 2011 15:18:46 -0500, Daniel Gibson wrote: On Fri, 21 Jan 2011 15:18:57 -0500, Steven Schveighoffer wrote: Damn, beat my by 11 seconds :) -Steve
Re: Potential patent issues
Am 21.01.2011 21:06, schrieb spir: 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. 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? You're thinking of closures (which are also "delegates" in D), but D's delegates can also be used to simple point to a member of an object. It's kind of hidden in the definition: "Delegates to non-static nested functions contain two pieces of data: the pointer to the stack frame of the lexically enclosing function (called the frame pointer) and the address of the function. _This is analogous to struct/class non-static member function delegates consisting of a this pointer and the address of the member function._ Both forms of delegates are interchangeable, and are actually the same type: [...]" from http://www.digitalmars.com/d/2.0/function.html 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... Denis _ vita es estrany spir.wikidot.com
Re: Potential patent issues
On Fri, 21 Jan 2011 15:06:37 -0500, 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.
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?
The pointer could be an object:
class C
{
int x;
void foo() {x = 5;}
}
void main()
{
auto c = new C;
auto dg = &c.foo; // context pointer is pointer to c, not main's stack
frame
}
Really, the context pointer could be anything.
-Steve
Re: Potential patent issues
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. 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... Denis _ vita es estrany spir.wikidot.com
Re: Potential patent issues
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.
Re: Potential patent issues
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.
Re: Potential patent issues
Am 20.01.2011 11:19, schrieb spir: On 01/19/2011 10:09 PM, retard wrote: Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Don't put everything on the back of the US ;-) We in Europe have our own financial mafia pushing for the same kind of extortion system as in the US! Deins _ vita es estrany spir.wikidot.com Yes. Of course it's also US companies like Microsoft who want software patents here - but we've got a few ones ourselves, for example SAP and Siemens. Don't know if there are many more european companies who want this, though.
Re: Potential patent issues
On 01/19/2011 10:09 PM, retard wrote: Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Don't put everything on the back of the US ;-) We in Europe have our own financial mafia pushing for the same kind of extortion system as in the US! Deins _ vita es estrany spir.wikidot.com
Re: Potential patent issues
On Wed, 2011-01-19 at 22:37 +0100, Simen kjaeraas wrote: > Nick Sabalausky wrote: > > > "retard" wrote in message > > news:ih7jv4$q49$7...@digitalmars.com... > >> Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: > >> > >>> "Andrej Mitrovic" wrote in message > >>> news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... > Or pack your bags and move to Europe. :p > >>> > >>> I thought Europe was getting software patents? > >> > >> It's the US intellectual property mafia pushing software patents to EU > >> via WIPO, bribes, and extortion. > > > > Well yea, but whatever the source of it, I was under the impression that > > it > > was succeeding, or had already succeeded. > > In the EU, it is succeeding at least to an extent. However, many EU members > do not want software patents, and few European countries outside EU would > consider it. (about half of Europe is not part of the EU) The EU Patent Office is trying hard to succumb to the US pressure to start issuing software patents in the same way USPTO does. It will be a disaster if they are allowed to get away with this. So anyone in the EU, make sure your MEP (or whatever you label your elected representative) knows what is going on, knows that this is a "land grab" by the US corporates to stiffle competition and innovation in EU. The problem here is ACTA. The software patents advocates (via USTR) have managed to infiltrate this global agreement so as to force all signatories to follow US rules on software patents. This will force EU members to do the unthinkable and honour all US software patents. If this happens we might all as well give up writing software unless we work for a huge corporation who can play the patent cross-licencing game. If the populace doesn't act, they will be shafted. PS Read the relevant articles at http://webmink.com/ especially http://webmink.com/?s=ACTA. Simon Phipps is 110% correct on the issues associated with ACTA. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Potential patent issues
Nick Sabalausky wrote: "retard" wrote in message news:ih7jv4$q49$7...@digitalmars.com... Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Well yea, but whatever the source of it, I was under the impression that it was succeeding, or had already succeeded. In the EU, it is succeeding at least to an extent. However, many EU members do not want software patents, and few European countries outside EU would consider it. (about half of Europe is not part of the EU) -- Simen
Re: Potential patent issues
"retard" wrote in message news:ih7jv4$q49$7...@digitalmars.com... > Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: > >> "Andrej Mitrovic" wrote in message >> news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... >>> Or pack your bags and move to Europe. :p >> >> I thought Europe was getting software patents? > > It's the US intellectual property mafia pushing software patents to EU > via WIPO, bribes, and extortion. Well yea, but whatever the source of it, I was under the impression that it was succeeding, or had already succeeded.
Re: Potential patent issues
Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: > "Andrej Mitrovic" wrote in message > news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... >> Or pack your bags and move to Europe. :p > > I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion.
Re: Potential patent issues
You're thinking EU. :p On 1/19/11, Nick Sabalausky wrote: > "Andrej Mitrovic" wrote in message > news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... >> Or pack your bags and move to Europe. :p > > I thought Europe was getting software patents? > > >
Re: Potential patent issues
"Andrej Mitrovic" wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... > Or pack your bags and move to Europe. :p I thought Europe was getting software patents?
Re: Potential patent issues
Or pack your bags and move to Europe. :p
Re: Potential patent issues
"retard" wrote in message news:ih7dih$q49$2...@digitalmars.com... > Wed, 19 Jan 2011 12:50:46 -0500, Jeff Nowakowski wrote: > >> On 01/18/2011 05:52 PM, BlazingWhitester wrote: >>> >>> Walter, could you give some comments about this? Does dmd violate >>> anything? >> >> It's probably in Walter's best interest to not even look at it. >> >> On the one hand, it's probably a crap software patent that the Patent >> Office has been handing out like candy, and removing basic features that >> have been patented could cripple D. Whoever owns it might not decide to >> sue, Walter's implementation might not infringe, it might be >> invalidated, etc. >> >> On the other hand, if Walter is sued and found to have infringed the >> patent, and if he "willfully infringed", meaning he had knowledge of the >> patent, then he could face up to three times damages. > > At least he knows it now unless he deliberately ignores all newsgroup > posts containing the word 'patent'. I think only C# and D market the > language with a feature 'delegate'. What's fun is that even if you're > right and there's prior art or the patent is way too trivial, the patent > trial can become very expensive. I'm no lawyer, and there are probably reasons why this wouldn't work, but what I would consider doing in that situation is pull together a clear-cut example of obvious prior art, stick it in their faces, *record*/*document* showing it to them, and when they don't back down, hire a lawyer to counter-sue for frivolous lawsuit or harassment or something.
Re: Potential patent issues
Wed, 19 Jan 2011 12:50:46 -0500, Jeff Nowakowski wrote: > On 01/18/2011 05:52 PM, BlazingWhitester wrote: >> >> Walter, could you give some comments about this? Does dmd violate >> anything? > > It's probably in Walter's best interest to not even look at it. > > On the one hand, it's probably a crap software patent that the Patent > Office has been handing out like candy, and removing basic features that > have been patented could cripple D. Whoever owns it might not decide to > sue, Walter's implementation might not infringe, it might be > invalidated, etc. > > On the other hand, if Walter is sued and found to have infringed the > patent, and if he "willfully infringed", meaning he had knowledge of the > patent, then he could face up to three times damages. At least he knows it now unless he deliberately ignores all newsgroup posts containing the word 'patent'. I think only C# and D market the language with a feature 'delegate'. What's fun is that even if you're right and there's prior art or the patent is way too trivial, the patent trial can become very expensive.
Re: Potential patent issues
On 01/18/2011 05:52 PM, BlazingWhitester wrote: Walter, could you give some comments about this? Does dmd violate anything? It's probably in Walter's best interest to not even look at it. On the one hand, it's probably a crap software patent that the Patent Office has been handing out like candy, and removing basic features that have been patented could cripple D. Whoever owns it might not decide to sue, Walter's implementation might not infringe, it might be invalidated, etc. On the other hand, if Walter is sued and found to have infringed the patent, and if he "willfully infringed", meaning he had knowledge of the patent, then he could face up to three times damages.
Re: Potential patent issues
On 2011-01-19 01:15:03 +0200, Daniel Gibson said: This is trivial, what idiot grants these kind of patents? And were there really no delegates before Jan. 31 1996 when this was filed? If I'm not mistaken, Oberon-2 implemented pointers to record-bound procedures as fat-pointers
Re: Potential patent issues
Am 18.01.2011 23:52, schrieb BlazingWhitester: 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 is trivial, what idiot grants these kind of patents? And were there really no delegates before Jan. 31 1996 when this was filed? http://www.freepatentsonline.com/5628016.pdf - describes compiler support for SEH, also this is the reason GNU toolchain does not support SEH right now Both patents were owned by Borland, right now, I believe Microsoft owns them. Walter, could you give some comments about this? Does dmd violate anything?
Re: Potential patent issues
"BlazingWhitester" wrote in message news:ih55mp$2gtl$1...@digitalmars.com... >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) > http://www.freepatentsonline.com/5628016.pdf - describes compiler support > for SEH, also this is the reason GNU toolchain does not support SEH right > now > > Both patents were owned by Borland, right now, I believe Microsoft owns > them. > > Walter, could you give some comments about this? Does dmd violate > anything? > I don't think there's a piece of software in existence that doesn't violate about ten different software patents.
