compatibility and the OSD

[Kevin Bedell]

At the risk of beating a dead horse...

>
> > Care to share *why* you're concerned about incompatibility?
>

The more I think about this, the more it seems like this is a classic example of
what I'd call 'Open Source/Closed Standards'.

Any company that would want to define a standard API and release an open source
implementation of that API would be apprehensive that 'the open source
community' would take the open source code and release derivative works that
extend/enhance that API (or even change the API itself).

For example, imagine that Sun were to release Java under an OSD-compatible
license. They would want to make sure that they (or at least the JCP process)
were still able to maintain control of Java from an API perspective.

[Of course, my picking Java here doesn't mean I know anything about why Bob is
concerned about this topic. It's just a convenient example.]

The most likely way to open source Java would be to also release a Reference
Implementation (RI) and a Technology Compatibility Kit (TCK). I believe that
the JCP process requires this already (at least in some cases).

Then, the open source license would need to dictate that derivative works were
fine as long as they still passed the tests in the TCK. Otherwise, there would
be limitations to the ability to redistribute derivative works. No 'derivative
works' would be allowable for the TCK.

This has the effect of allowing the company to own the standard while the open
source community can deliver ever-improving implementations of the standard.

Without this limitation (i.e., under Open Source/Open Standards), the open
source community could deliver derivative implementations of the technology
that diverge from the standard. If these 'derivative' implementations became
widely adopted, then the Sun could risk a battle to have *their* version of
Java remain the standard. I'm sure that putting themselves in the position of
having to 'out innovate' the open source community is not something that Sun
likely wants to do.

Worse yet, imagine if IBM (or even Microsoft) were to deliver a derivative of
Java that diverged from the TCK. With their market clout, they could literally
rest control of Java from Sun. (And this would likely happen as fast as you
could say 'embrace and extend'.)

Some concerns I'd have about approving this would be:

 o How exhaustive and complex would the TCK be?  Could a single developer run
and pass the TCK as part of a normal 'build process', or would it contain
thousands of individual tests and require complex setup to work? (Think of the
JAX-RPC TCK or the WS-I Basic Profile test harness here.)

 o Would the TCK require third-party libraries that are not open source and are
not free (as in beer)?

So is this bad? I don't believe so. I think that for a company to open source a
technology as core as Java is to Sun, they would need the assurance that they
could retain their control over the technology they created.

On the other hand, as more and larger companies attempt to 'open source' their
core technologies it may be worth considering at some point how to alter the
OSD to make a distintion between Open Source/Open Standards and Open
Source/Closed Standards and to allow companies a way to do either without
having to perform licensing gymnastics to do so.

-kevin





Kevin Bedell
Black Duck Software
http://www.blackducksoftware.com

"Imagination is more important than knowledge."
 - Albert Einstein