Can ICE be used to create an Open OPC?

Originally posted by Ken Carpenter
While posts from the ZeroC founders indicate that they welcome other such implementations, I have not seen any formal statement of this. Also, I don't think there is a well-defined line yet as to what parts of ICE are "specification" (which can be used to write your own version of ICE) and what parts are "implementation" (which are proprietary to ZeroC). For example, can I copy the class interfaces exactly? Or is it only the wire protocol that is open? I think a statement clarifying these issues would be very beneficial for ICE's future.

Nothing in Ice is patented by us, so there is legally no reason whatsoever why somebody couldn't develop a "clone" of Ice, as it happened with many other applications before. Our implementation is copyrighted, and could not be used in such a clone, but of course everybody is free to use our interfaces.

Originally posted by Ken Carpenter
There is also no guarantee that ZeroC will evolve ICE in a way that is beneficial to the process control industry (or any particular industry for that matter). No offense is intended to ZeroC in this statement. It simply recognizes that what might be best for ZeroC is not necessarily what is best for others.

Well, the question is rather, is there anything missing in Ice that is needed by the control industry? Ice can certainly do everything that DCOM can do.

Originally posted by Ken Carpenter
Licensing is also a concern. Although ZeroC generously licenses ICE under the GPL for use in open source software, they do require significant licensing fees for commercial use of ICE. If your goal is a standard that is free of licensing fees, then you'll have to wait until there is a version of ICE with a more commercial-friendly open source license (perhaps like the Apache license). Of course, nobody's stopping you from creating this yourself (I think).

If the goal is to develop an open source process control solution, no special commercial license is needed. Ice is available under GPL, and this allows others to write GPL (or compatible license) applications. Such other applications can be used commercially. This doesn't violate the GPL. Otherwise you couldn't use Linux commercially either.

Originally posted by Ken Carpenter
As I mentioned previously, if your goal is truly to have Ice clones become common, then your documentation should clearly state what is open and what is not. Can I, for example, take an Ice header file, save it, change the copyright, reformat the spacing and braces to my coding standards and call it my own? Probably not. Can I type in basically the exact same thing myself based on reading your header files and documentation? I don't know. Hopefully you see where I am going with this.

Hi Ken,

I take your point. We may need to clarify this a bit more, I agree. (Right now, it's not really an issue because there is no other implementation but, as you say, this may become an issue in the future.) The spirit of things is that we want to encourage other implementations, and that we'd actively support efforts to create an alternative implementation. As far as copyright is concerned, I suspect we would draw the line if people started to lift our code wholesale and claimed it as their own.

In practice, I think this means that all Slice definitions that define APIs to the Ice run time would be considered part of the Ice interface, and therefore other people would be free to use those. The same would be true for the Ice protocol, and any language-native APIs that are for use by applications. (There are a few Slice definitions and language-native definitions that exist for Ice-internal purposes--I would consider those part of the implementation, not the Ice interface.)

I intuitively described the spirit of things with those words--finding a formal definition that would satisfy a lawyer would be quite a bit of work, I'm afraid. For example, copying a header file wholesale would probably constitute a copyright violation if, for example, the private sections of the header define implementation detail so, therefore, copying of the header would imply copying the implementation. In the end, I suspect we'd have to look at such things on a case-by-case basis. (In theory, we could rewrite Ice to strictly separate interface and implementation, for example, using the C++ pimpl idiom to create "private" and "public" header files. But doing so would have a performance impact on the implementation...)

The real question is political (or maybe just practical). Can an entire industry take the risk that a small startup company like ZeroC is going to:

a) be around for a while; and
b) evolve Ice in a way that is compatible with the industry's needs? (e.g., ZeroC decides to focus Ice on massively multiplayer gaming and changes the APIs and wire protocol to reflect common usage in that area)

Good questions. The way I see it, no amount of standardization (or any other kind of formal process) provides an iron-clad guarantee to a customer. Just think about what has happened to CORBA customers in the past, with vendors going out of business, customer lock-in through proprietary features, and differences in ORBs due to lack of standardization (as is the case for C++ header file names, IDL compiler switches, library names, configuration, implementation repositories, and a host of other things). So, even if we were to formally standardize Ice, this would provide some degree of assurance to customers, but no guarantee. (To give another example, think about what the change from the BOA to the POA did to CORBA customers, and the costs that were associated with that change--just because something is specified by the OMG in no way guarantees that APIs will be stable.)

Ultimately, any kind of choice of platform for a project entails some risk: the platform may not be supported for the life of the product, a vendor may go out of business, the platform may not be ported to an environment that may be needed in the future, etc. In the end, choosing a particular platform is a matter of faith as much as anything else.

What Ice has going for it is technical excellence. Our hope is that this excellence will translate into a growing user base (and, so far, things are coming along nicely). The more people use Ice, the safer they are because this creates a base for ZeroC that keeps the company and the platform viable. To put this differently, if you want to feel safer, start using Ice and encourage as many people as you possibly can to do the same--a large user base for Ice is a better guarantee of avoiding platform obsolescence than anything else I can think of.

Maybe you (or someone) could start an "OpenIce" organization to maintain the protocol and interface specifications. Any materials provided by that organization would explicitly state that they are available for any Ice implementor to use. Companies with an interest in Ice could join the organization so that their interests could be fairly represented as changes are proposed.

In principle, I agree. Doing this would be useful. But, to be honest, I don't see this as a process that ZeroC should initiate but, rather, as a process that ZeroC should participate in. There is no point in doing all this work unless there are third-party implementations of Ice. And, to be honest, without someone who actually goes through the pain of creating such an implementation, any standardization effort would probably be moot. CORBA is a good example of this: what actually requires standardizing is often not recognized until people go and create real implementations (because that is what uncovers flaws and omissions in the standard). The OMG has spent many years creating standards without implementations, with the result that the specs that are published are often broken, irrelevant, unimplementable, etc. I'd rather not be party to yet another "pie-in-the-sky" standardization process.

I promise, as soon as someone comes along and creates a third-party implementation of Ice (or of a subset of Ice), I'll be the first person to jump in and help create a standard that actually captures what is needed to ensure interoperability and portability. But we cannot honestly create such a standard out of a vacuum: without the real-life problems that only a third-party implementation can expose, I don't see a way to create a standard that would actually be worth the name...

Cheers,

Michi.