Yes, most likely this is just an issue of properly setting the permissions, and not a bug. If you are going to register the EasyOPC-DA as a Service too (as I recommended), the problem may go away. If it does not, or if you still want to make it work as Local server, read further.
First, you need to determine whether the problem is that
a) your application cannot call EasyOPC-DA, or
b) EasyOPC-DA cannot call the target OPC server.
In order to figure this out, try accessing something in the EasyOPC-DA component that does NOT need the target OPC server. For example, try to retrieve value of some property , such as Timeouts.ReadItem. If this fails, it is a); if it succeeds, it is b).
For a): Run DCOMCNFG from the command line, and navigate to Console Root -> Component Services -> Computers -> My Computer -> DCOM Config. Do right-click on "EasyOPC-DA (COM) 5.0", and select Properties. Configure the settings on Security and Identity as needed (below).
For b): Run DCOMCNFG from the command line, and navigate to Console Root -> Component Services -> Computers -> My Computer -> DCOM Config. Locate the entry for your target OPC server, right-click on it, and select Properties. Configure the settings on Security and Identity as needed (below). I am assuming that the OPC server is not remote; if it is, you will need to do this on the computer where the server is located, and things would complicate even further.
The Identity tab determines which user account the EasyOPC-DA component or the OPC server runs under. The Security tab determines which user accounts can launch/activate and access the EasyOPC-DA component or the OPC server. You need to think about which accounts you want to use, and then configure the Identity and the Security accordingly. For start, just to verify that this is a permissions issue, select "Customize" for both "Launch and Activation Permissions" and "Access Permissions", add following accounts: Everyone, INTERACTIVE, SYSTEM, NETWORK, and give them at least "Local Launch", "Local Activation" resp. "Local Access" permissions. If you make this work, you can later restrict the security back to what is precisely needed.
The DCOMCNFG stuff I described was for Windows 7. On other systems, it may be a bit different, but still quite similar.