Re: [jakartaee-platform-dev] javax.inject

[Mark Struberg <struberg@xxxxxxxxxx>]

Hi Bill!

> Our choices are to either use it as a dependency, and thus require
> Jakarta EE vendors to accept the JCP spec license for JSR-330,
> or to fork it.

The API (including JavaDocs) _and_ the TCK [1][2] are all available under ALv2. There is no JCP license needed for the TCK!
So no, afaict we do not inherit any JCP license into Jakarta. Or did I overlook something?

Btw, moving the existing JavaDocs to ESL is legally not possible. The ALv2 only allows sub-licensing but NOT re-licensing!

Whether we should move javax.inject to jakarta.inject or not is another story, but there is no legal need afaict.
Also the current bits would remain (C) as they are and ALv2. Only _newly_ added bits which clealy pass the threshold of originality might adhere under the ESL+ETCKL in the future. Just replacing the package name and other smallish changes clearly do not pass the bar to create originary IP.

txs and LieGrue,
strub

[1] http://repo1.maven.org/maven2/javax/inject/javax.inject-tck/1/javax.inject-tck-1.pom
[2] https://github.com/javax-inject/javax-inject


> Am 05.06.2019 um 21:43 schrieb Bill Shannon <bill.shannon@xxxxxxxxxx>:
> 
> I've talked to Bob Lee about javax.inject (JSR-330).
> He is *not* willing to move it to Eclipse.
> 
> Our choices are to either use it as a dependency, and thus require
> Jakarta EE vendors to accept the JCP spec license for JSR-330,
> or to fork it.
> 
> I believe we should fork it.
> 
> There is no spec document, only javadocs.  The API classes, implementation,
> and TCK are all Apache licensed.  I've confirmed that there are no legal
> issues at Eclipse with us forking it.
> 
> 
> For Jakarta EE 8 we would need a copy of the API classes available under
> the Apache license, and javadocs available under the Eclipse Foundation
> Specification License.  Likewise, we would need a copy of the TCK available
> under the Apache license and a version of the TCK available under the
> Eclipse Foundation TCK License.  And of course we would need to create or
> choose a specification project to hold these artifacts.
> 
> javax.inject is the foundation of CDI.  I would strongly recommend that
> these artifacts be managed by the (to be created) Jakarta CDI spec project,
> and that *Red Hat* do the work to fork this API into the CDI project.
> 
> For Jakarta EE 9, I think the Jakarta CDI spec project should consider
> subsuming the javax.inject->jakarta.inject API into the CDI spec, and
> Red Hat should consider subsuming the implementation into the CDI
> implementation project.
> 
> Comments?
> 
> In particular, does Red Hat support this plan?
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev