On the role of the SCA

Andrew Haley aph at redhat.com
Mon May 9 13:42:58 UTC 2011

On 05/09/2011 02:32 PM, Dr Andrew John Hughes wrote:
> snip...
>>> As I mentioned in the previous thread, much of this could be sorted
>>> out if Oracle simply cleaned up their binaries so that there was a
>>> clear GPL component with proprietary blobs to plug in.  That's both
>>> technically and legally possible AFAICS, but it does require a little
>>> work initially.  The benefit far outweighs this initial outlay though,
>>> as you'd be able to get rid of the OCA
>> I don't think you would.  I don't think it would make any difference
>> to the core issue, as I described above.  Improvements to the VM, for
>> example, can't be separated into proprietary blobs.
> Ok, so what you're actually saying is not that you couldn't drop the OCA
> in such a situation, but that you couldn't get to such a situation in the first
> place because the necessary prerequisite of separating the proprietary
> blobs isn't possible.

No, I'm not saying that.  I'm saying that dropping the SCA would force
a separate fork on Oracle's developers, and they'd then have two sets
of sources, one of which couldn't be used on some proprietary
projects.  This would be a second-class citizen, and that would be
very bad for free Java because much of the really interesting stuff
would probably happen in the proprietary tree.

In other words, the SCA is what you have to pay to keep Oracle's work
on OpenJDK open.

> On that, I can only make superstitions.  Only Oracle know what they bundle
> with their proprietary VM that's not part of OpenJDK.

I don't see why that's relevant.

>>> and actually start to make OpenJDK into a proper FOSS project.
>>> It goes a bit further than making "free software developers feel
>>> better" and actually removes a huge barrier for entry into the
>>> project.
>> It does, but this is insignificant when compared with the problems
>> that would be caused by forking.  The question is simply whether the
>> pain of maintaining a non-proprietary fork would be justified by the
>> amount of new software that would be contributed.
> Either way, you'll get forks.

I hope not.  We'll see.  [What we have ATM is not a fork, IMO.]

> For me, the current status quo actually works fine, with OpenJDK as
> an upstream and real work going on in IcedTea.  It means OpenJDK
> naturally fails at being the single source of Free Java development
> though, which I get the impression some people seem to want.

Well, it's a shame, but it may well be the least bad option.


More information about the discuss mailing list