compatibility and the OSD

[Lawrence Rosen]

What's wrong with the Sun Industry Standards Source License (SISSL) for this
purpose? It is already approved by OSI as an open source license. 

I note that JAVA is not made available by Sun under the SISSL.

/Larry

Lawrence Rosen 
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482 
707-485-1242 * fax: 707-485-1243 
email: lrosen at rosenlaw.com 



> -----Original Message-----
> From: Kevin Bedell [mailto:kevin at kbedell.com]
> Sent: Saturday, September 25, 2004 7:04 PM
> To: license-discuss at opensource.org
> Subject: Re: compatibility and the OSD
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
>