[R-SIG-Finance] Interactive Broker API
jeff.a.ryan at gmail.com
Sat Jun 6 04:32:07 CEST 2009
The OSS issue:
>> You can now (with IBrokers and R) pull data from a secondary source
>> (of your own API/etc) and use IB to execute. This is probably the
>> smartest route if you require top-notch feeds. Coding this isn't
>> entirely trivial, but is easy enough. I may (or may not) be making a
>> DTN interface available, though the structure of the terms on that
>> from DTN make open-source not possible. Contact me off list if you
>> are interested.
[Very off topic...]
The problem isn't in making it open-source per se. That I would tend
to agree is OK. The problem is that DTN requires a API developer
subscription at $x per year, plus they need to _approve_ all API
before use. This is to protect the integrity of their service I
suspect, as well as the other customers they have.
Essentially the R code would be available, but unusable without this
developer registration 'key'. If one distributes the key (which
likely is not to be made "public" per the developer agreement --- so
this is moot) then others could use it.
So the basic code could be GPL'd (most likely) but to use it you would
need to pay a developer fee. It is more economical for each user to
pay one developer to use his code (which is OK --- that is the model
they are employing), than for each to pay the full fee.
A small example of divergence between OSS theory and practice. :)
> Of course, I am not a lawyer, but at least in the United States, courts have
> repeatedly held that API's for a commercial software product cannot be held
> to be "confidential", and that writing your own code to interface to those
> API's is legal. Thus Samba for connecting to windows-style file shares. As
> such, an open source connector to the DTN API would likely violate no law in
> the United States.
> - Brian
> Brian G. Peterson
> Ph: 773-459-4973
> IM: bgpbraverock
jeffrey.ryan at insightalgo.com
ia: insight algorithmics
More information about the R-SIG-Finance