[jsr330-eg] Status

25 views
Skip to first unread message

Bob Lee

unread,
Jul 16, 2009, 6:28:29 PM7/16/09
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



Paul Hammant

unread,
Jul 16, 2009, 7:01:18 PM7/16/09
to atin...@googlegroups.com

Bob,

Can you say more about the licenses they want us to use?

I'm happy with many license as long as there is no click-through required for download.  Or put it another way, for many years servlet-api was more or less unavailable in a maven repo and is only there today after some sleights of hand.  The transaction api is still scarred by such a requirement.

As it happens (IANAL) if a particular software fragment cannot be done any other way, then its not subject to IP protection.  That notwithstanding algorithms which may be different and subject to juristriction.

Consider 'Startable' (a beloved concept from the start of IoC 10 years ago).  Here it is:

     public interface Startable {
          void start();
          void stop();
     }

With Apache-Avalon it was Apache licensed.  OSGi had a similar under a different license.  PicoContainer has it as BSD licensed. JBoss, one more of their own design (I presume LGPL), and you can see many more here :- http://repository.sonatype.org/index.html#nexus-search;Startable   That someone could claim that they are copy of an original is not a legally relevant position.

Thus, for a bunch of annotations, and some interfaces, I feel there is potential for them being not subject to copyright.

The TCK may be a different thing (as would a RI if we get that far).

- Paul

PS

Avalon's Startable at various times was -

     public interface Startable {
          void start() throws LifecycleException;
          void stop() throws LifecycleException;
     }

     public interface Startable {
          void start() throws Exception;
          void stop() throws Exception;
     }

Bob Lee

unread,
Jul 16, 2009, 7:47:12 PM7/16/09
to atin...@googlegroups.com
On Thu, Jul 16, 2009 at 4:01 PM, Paul Hammant <PHam...@thoughtworks.com> wrote:
Can you say more about the licenses they want us to use?

Sun wants us to use any of the "Sun-approved" spec licenses, basically a license that's been used on a JSR before (they explicitly excluded JSRs 235-7). These are all click-through licenses with the standard compatibility restrictions.
 
Thus, for a bunch of annotations, and some interfaces, I feel there is potential for them being not subject to copyright.

The Javadocs themselves are copyrighted, so we need to license those if we want users to be able to copy and host them freely. The Apache license takes care of that. I agree that the API itself is not copyrightable.

The TCK may be a different thing (as would a RI if we get that far).

Sun is fine with using the Apache license for the RI and TCK. Only the spec license is in question.

Thanks,
Bob


Felix Meschberger

unread,
Jul 17, 2009, 10:21:39 AM7/17/09
to atinject...@googlegroups.com
Hi all,

Just from far apart ... I know that David Nuescheler (spec lead JSR-170,
JSR-283) and Roy Fielding went a long way towards a permissive license
as can be (according to Sun, that is IIRC) for JSR-170.

This might possibly be an option. Otherwise you might want to get in
touch with David with respect to licensing.

Regards
Felix


Bob Lee schrieb:

Ravi (Axolotl)

unread,
Jul 17, 2009, 12:53:35 PM7/17/09
to atinject-observer
As I understand the alignment of 330 and 299, I would rather delay
both than "rush things through" skipping EDR and other parts of the
process. These delays give people the chance to not just read specs
but make their own implementations of things and test things out
further. If only one person is rushing something through they have no
idea what other works will be trampled on because people will simply
not have the time to react. 2 cents.
My company has a DI framework that I am planning on using the 330
annotations, however if this is all released when EE6 is released I
won't have time to submit comments. I recently joined the JCP just for
330 but the process seems to be going so fast I may be too late.

Bob Lee

unread,
Jul 17, 2009, 2:57:55 PM7/17/09
to atin...@googlegroups.com
Sun just informed me that the license from JSR-286 is not "Sun-approved" either. Apparently, JSR-286 got special treatment like JSRs 235-7. I'm incredulous.

I told the PMO to just copy the licenses from JSR-284 instead; I don't think we got special treatment for that one. I said that this is a temporary solution to keep things rolling until the acquisition goes through, and that we intend to go final with Apache 2.

Bob


Bob Lee

unread,
Jul 17, 2009, 3:08:32 PM7/17/09
to atinject...@googlegroups.com
Ravi,

We're not rushing anything through. The spec has barely changed in the 2.5 months since we widely announced it. If we skip the EDR, that still leaves 14 days (PR posting time) + 30 days (Public Review & ballot) + 14 days (PFD posting time) + 14 days (FAB) + 1 day (Final Release), another 2.5 months. The spec consists of 5 annotations + 1 interface with 1 no-argument method. The spec is already informed by at least 6 different DI implementations. You should be able to retrofit your own DI implementation and post comments in 30 days, let alone the almost 3 months we're currently looking at (the EC doesn't even meet until the 21st).

Bob

Bob Lee

unread,
Jul 17, 2009, 3:12:45 PM7/17/09
to atinject...@googlegroups.com
On Fri, Jul 17, 2009 at 7:21 AM, Felix Meschberger <fmes...@gmail.com> wrote:
Just from far apart ... I know that David Nuescheler (spec lead JSR-170,
JSR-283) and Roy Fielding went a long way towards a permissive license
as can be (according to Sun, that is IIRC) for JSR-170.

Thanks for the suggestion, Felix. I think the license for JSR-286 is actually a little simpler, but of course, we can't use it. The appeal of the Apache 2 license is that everyone is so familiar with and trusting of it that they don't even have to read it (or have their lawyers approve it).

Bob

Tim Peierls

unread,
Jul 17, 2009, 3:15:24 PM7/17/09
to atinject...@googlegroups.com
On Fri, Jul 17, 2009 at 3:08 PM, Bob Lee <crazy...@gmail.com> wrote:
You should be able to retrofit your own DI implementation and post comments in 30 days, let alone the almost 3 months we're currently looking at (the EC doesn't even meet until the 21st).

And if you can't, then that's something worth commenting about sooner rather than (EDR-delayed) later!

--tim

Bob Lee

unread,
Jul 17, 2009, 3:18:21 PM7/17/09
to atinject...@googlegroups.com
On Fri, Jul 17, 2009 at 12:15 PM, Tim Peierls <t...@peierls.net> wrote:
And if you can't, then that's something worth commenting about sooner rather than (EDR-delayed) later!

Exactly. The JCP stages are purely formalities so far as we're concerned. You can open issues and we can update the spec any time between now and when we ship the final draft.

Bob

larry...@oracle.com

unread,
Jul 17, 2009, 6:02:56 PM7/17/09
to atinject...@googlegroups.com, atin...@googlegroups.com
Bob, just to clarify are you refering to the the specification (JSR),
the RI or the TCK when you state below that the intention is to
go fwd with Apache2?

- Larry

Bob Lee

unread,
Jul 17, 2009, 6:05:12 PM7/17/09
to atin...@googlegroups.com
On Fri, Jul 17, 2009 at 3:02 PM, <larry...@oracle.com> wrote:
Bob, just to clarify are you refering to the the specification (JSR),
the RI or the TCK when you state below that the intention is to
go fwd with Apache2?

I was referring to the spec, but the RI and TCK will also be Apache-licensed.

Thanks,
Bob


larry...@oracle.com

unread,
Jul 17, 2009, 6:10:58 PM7/17/09
to atinject...@googlegroups.com
thanks

Felix Meschberger

unread,
Jul 20, 2009, 3:24:22 AM7/20/09
to atinject...@googlegroups.com
Hi,

Bob Lee schrieb:

Right, ASL2 would of course be best of all ;-)

And maybe some day this will -- hopefully -- possible !

Regards
Felix

Reply all
Reply to author
Forward
0 new messages