Bob Lee
unread,Jul 16, 2009, 6:28:29 PM7/16/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to atin...@googlegroups.com
EG members and observers,
I apologize for the lack of communication over the past few weeks.
We've been in continuous and ongoing talks with Sun et al. about a)
finalizing the annotation portion of the spec as soon as possible, and
b) how to license the spec.
As you know, Java EE 6 and JSR-299 both need us to release the
annotations JSR as soon as possible. Sun and Oracle originally asked us
to hand the annotations over to JSR-250 ("Common Annotations") so they
could be released as part of the maintenance draft. This idea fell
apart for a few reasons:
1) Licensing - The JSPA doesn't say anything about transferring IP
between spec leads (i.e., from Google and SpringSource to Sun).
2) Ownership - JSR-250 insisted upon owning this part of our API
indefinitely. We think our DI-focused EG is better suited to owning the
API than the JSR-250 EG.
3) Compatibiltiy - The JSR-250 EG wanted to make arbitrary changes to
our API such as leaving out Provider, and they wanted to apply the same
lax compatibility restrictions that apply to the rest of that JSR:
arbitrary subsetting would be allowed and a TCK wouldn't be required.
In the end, we decided that releasing the spec a month or two earlier isn't worth the long term risks and headaches.
Now, we plan to go ahead and finalize JSR-330 with the annotation
portion of the API only. We will (concurrently) work on the
configuration API and release it in a subsequent maintenance draft.
We've already submitted the current annotation-related portion of the
spec for Early Draft Review (EDR). It would normally take ~4.5 months
to finalize the spec, but we're working on ideas for abbreviating the
process.
Given the extreme openness and small size of our JSR, we believe that
the full blown JCP process is overkill. JSR-330 EG member Roberto
Chinnici sent a very nice letter to the Executive Council (EC) mailing
list asking them to let us skip EDR and jump to Public Review (PR). We
think it would be most beneficial to the community if we could jump
straight to the next stage, Public Final Draft (PFD). This would allow
30 days for the public to submit comments and for us to address them
before submitting the Final Draft (FD). Of course, we'd need to spread
the word about the review period to ensure that no one feels left out
once we submit the FD. Our hope is that the EC can discuss and vote on
this issue in the July 21st meeting.
The last blocking issue: how do we license the spec? We feel very
strongly that the spec should be licensed under the same, familiar
Apache 2 license as the RI and TCK. Sun insists that the JSPA requires
us to use a more restrictive license that only permits compatible
implementations. Lawyers from several other organizations disagree with
Sun's interpretation and contend that the JSPA allows more permissive
licenses. We think compatibility is more of a community issue than a
legal issue and wish to use a more permissive, open source-friendly
license. Strategies like providing an easy-to-run, Apache-licensed TCK
seem more likely to engender compatible implementations.
We
pointed out that Sun allowed more permissive specification licenses in
JSRs 235, 6 and 7. Sun has yet to explain why we're receiving different
treatment.
We copied a Sun-approved license from JSR-286
(Thanks, IBM!) for the purposes of the EDR, but I think we should
insist on the Apache 2 license for the final draft. Sun maintains that
they won't allow this. Bill Shannon pointed out that JSRs 235-7
remained in limbo for nearly four years and hinted that something
similar could happen here. If that were to happen, I presume Java EE 6
would move on without JSR-330, resulting in fragmentation of the Java
DI space. We sincerely hope it doesn't come to that, but we feel
strongly that we should be able to choose the license that's best for
our users. Imposing a more restrictive license makes no sense.
This may seem like a lot of effort for one JSR, but if it paves the way for future Apache-licensed specs, I think it's worth it.
Thanks,
Bob