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

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;
     }

On Thu, Jul 16, 2009 at 4:01 PM, Paul Hammant <PHamm...@thoughtworks.com>wrote:

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

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:

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

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

On Fri, Jul 17, 2009 at 7:21 AM, Felix Meschberger <fmesc...@gmail.com>wrote:

Bob

--tim

Bob

- Larry

On 7/17/2009 11:57 AM, Bob Lee wrote:

Thanks,
Bob

thanks

On 7/17/2009 3:05 PM, Bob Lee wrote:

Bob Lee schrieb:

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

Regards
Felix