Mark,
I am in Vienna briefly for tomorrow's DemoCamp. Not sure, if you'll have
time at such short notice, but feel free to come by tomorrow;-)
It's far from "my legal understanding", but as only Individual Member who
has been in the EC for some time now from "Sun" days to a
"transition"
phase if you want or time of inactivity till today, I am among those who
need to attend meetings and other responsibilities myself, as there is no
"deputy" or "proxy" for Individual Members;-)
The JSPA itself does not describe the license, but for the Spec there is
only one license, see
.
The "choice" (also a bit outdated, but Apache was there already) is for
RI/TCK, for the Spec it says "the PMO will help" and there's even the
notion of "your own license".
That has mostly been applied to J2ME licenses, with the effect, that some
JSRs including the old Sensor API for J2ME (JSR 256, which a few
"requirements" apply to JSR 363, but we certainly won't use anything else)
had license constructions so complicated and weird, even Oracle's own
lawyers did not want to go there and simply abandoned such JSRs not just
from a technical point of view;-D
I won't name anybody, but there are several fellow EC members who openly
admit, "looking at the code" is not their priority, so I think that answers
your question if the LICENCE.txt and license cover page of a Spec document
matters to them or license headers in source files?;-)
Cheers,
Werner
On Fri, Jul 4, 2014 at 12:01 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
Werner, maybe we can talk this over at a beer? It seems evident that
our
different legal view points are way too far apart for sorting this out via
email?
As an example I just like to quote from the respective JSP [1]:
"The Spec Lead will provide the EC with confirmation of the terms under
which the RI and TCK will be licensed at each review period."
The JSPA does not define _the_ license. It just defines that the EG must
pick a propriat one.
Also it's really established thinking that basically ALL what counts are
the license headers in the respective source files. And the JavaDoc only
being a 'secondary byproduct'. This is nothing I did define and neither did
Oracle - this is established IP right. If Oracle lawyers see this different
then I would be really worried.
LieGrue,
strub
[1]
https://jcp.org/en/procedures/jcp2_7
On Thursday, 3 July 2014, 23:17, Werner Keil <werner.keil(a)gmail.com>
wrote:
>
>
>Most of this remains to be discussed by a dedicated IP WG of JSR 358.
Which I ocasionally join and if you (or others here) have particular
interest, transparency means pretty much everything, especially minutes,
etc. is available also to those outside the WG or EC.
>
>
>
>On Thu, Jul 3, 2014 at 10:47 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
>
>Hi!
>>
>>
>>
>>> The "Spec" and its Software Manifestation (normally all artifacts
>>
>>> under "javax.something" or "java.something" (for the few
JSRs
>>
>>> like 310 that changed their package name in the course of
>>
>>> the lifecycle) in Oracle's (the PMO) understanding is under
>>
>>> the Spec License.
>>
>>
>>Werner, this might be Oracles understanding, but to me and many legally
trained colleagues it still seems factually wrong from a purely legal
aspect.
>>
>>If I write something under ALv2 and contribute it to the JCP under ALv2,
then no one (but me) has the right to change this license without asking
me. Not even Oracle. Also the JSPA only talks about sublicensing (which
does NOT include re-licensing under a different license!) and even
explicitly says 'same license'. It does _not_ say _which_ license, it only
defines (in §5E) "terms and conditions that are non-discriminatory, fair
and reasonable".
>>
>>
>>It surely does not allow Sun/Oracle to re-license the original ALv2 work
of JSR-330 (and other specs) with any other license. And it also doesn't
matter what Oracle defines as 'Spec'. The important legal definition is the
term 'work' which is used throughout almost all OSS licenses. And if Oracle
provides a download with a zip which only contains ALv2 licensed 'work',
then it also must prompt this license on their download page - and not any
other license which no single piece of the downloaded archive is licensed
under. You can check Androids 'system config -> licenses' page to see how
this is done ;)
>>
>>
>
>
>JSR 330 Spec was never ALv2 licensed, see
>The RI and TCK will be licensed under the Apache 2 license, and the
Specification will be licensed under an agreement that satisfies the
requirements of the JSPA.
>
>
>
>under
https://jcp.org/en/jsr/detail?id=330
>
>The "agreement that satisfies the requirements of the JSPA" is the Spec
License.
>
>
>
>>If you find such a paragraph which would allow such a re-licensing then
please tell me.
>>
>>
>
>
>There isn't any, again, Oracle has never said there would be any other
license than the Spec License for these materials, even if you download
"jsr XXX.jar" from a different place other than
jcp.org.
>
>
>>Oracle would have had to refuse that spec and force the EG to pick
another one. But now this is too late. This ship has pretty much sailed.
Changing or 'reinterpreting' this work as under some different license is
simply breaking a law.
>>
>>
>>
>>>Just see Java EE 7:
http://docs.oracle.com/javaee/7/api/
>>
>>> the JavaDoc (for all JSRs within that umbrella)
>>
>>> is therefore covered by the EE 7 Spec License
>>>>Copyright © 1996-2013, Oracle and/or its affiliates.
>>
>>> All Rights Reserved. Use is subject to license terms.
>>
>>Which is again factually wrong imo!
>>
>>I can also copy random files from the internet and claim that I own all
the copyrights.
>>It gets a bit more complex when we go into the legal details. On the one
hand JavaDoc is always more complicated as the 'work' of bringing it into a
nice representation might constitute own Copyright. And this is also fine
as ALv2 allows to add your own 'work' in any license you like. But (often
misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: the
original work (the parts which were ALv2) are STILL ALv2. This is btw
almost always the case - this is what eventual Contributor License
Agreements are for...
>>
>>It might also be that the 'collection of work' creates an own originary
copyright. Like a prose book might constitute own IP _in addition_ to the
original IP. But this 'collection IP' doesn't change the 'meat'
content of
javax.inject for example as explained above.
>>
>>
>>
>>>CDI refrains from this breach. At least there is no contradicting
JavaDoc license pointer.
>>
>>
>>Again wrong:
https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enter...
>>Clearly ALv2...
>>And Oracle also cannot force JBoss to amend or change this license
easily. JBoss would have to go to EVERY contributor and ask for permission!
>>
>>
>>
>
>
>The license headers in Java files are irrelevant in reality, and nobody
(especially not the EC or PMO) cares about them. They are interested in a
single license text provided with the JCP page, and again, for CDI you'll
find the same as for JSR 330 or others..
>
>
>Even in the IP savvy circles, people tend to mix up what's "Spec/API"
and
what's "RI/TCK". IMHO the likes of JSR 107 got this pretty right, also 354
and a few others.
>Look into each class if you want and you'll find a pointer to the Spec
License or a short version.
>
>
>The API is often ignored or misunderstood, but the JSPA is pretty clear
about it, though it was phrased with strong emphasis on the JVM itself:
>
>
>1.10 Java Specification (Specification or Spec): a written specification
for some aspect of the Java technology.
>This includes the language, virtual machine, Platform Editions, Profiles,
andapplication programming
>interfaces.
>https://jcp.org/aboutJava/communityprocess/JSPA2.pdf
>
>
>
>I assume almost every one of you here signed it, or had your HR/legal
department do;-)
>
>
>"application programming interfaces" - API meaning, the JSPA considers
them to be part of the Spec under the subsequent license, but the sentence
is so vague, that I'm sure, you'll find 3 different oppinions or
interpretations if you just ask enough lawyers;-)
>
>
>
>>Btw, I've talked with a few lawyers who reviewed ULA and they did all
not sound happy about it...
>>
>>
>>
>>I also got a bunch of weird answers from Oracle lawyers, e.g. that we
must not do a RI which is ALv2, EPL, OSGI, etc because 'they are not
compatible with the licenses we use in Glassfish'.
>>Totally sick argument. If that would be true than Oracle would need to
remove 50 jars from Glassfish4, including
>>* Weld
>>* Eclipselink
>>* all OSGi
>>* Tomcat (yes, core-web.jar is nothing but a repackaged tomcat)
>>
>>* JNDI (org.apache.naming)
>>to just name a few.
>>
>>
>>Would this make sense? Do we really like to go down this route?
>>
>>
>>To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And
exactly the ClassPathException is the case why EPL and ALv2 jars inside
Glassfish are totally fine and this legal info we got from Oracle legal is
imo nuts.
>>
>>
>>
>
>
>Look into OpenJDK and especially the whole of the (additional) java.time
APIs contain BSD licensed material, despite the fact, that JDK as such is
licensed under different agreements. I asked the people in the EC and IP WG
discussing these things, and only Azul (not a lawyer but also caring a lot
about IP) said their understanding was, it should be OK for "Non EG
Members" to contribute this under BSD, but EG Members should have
contributed all of that either under the Spec License or the one by
OpenJDK. None of the classes in question seem to ever have been touched by
anybody other than the Spec Leads as there was no other contribution when
310 was still in places like GitHub or
SF.net.
>
>
>
>
>>I know there is tons of legal b******t going round these days. But
repeating it over and over again doesn't make it more true...
>>
>>If you think I have an error in my argumentation then please feel free
to correct me and help me understand the problem.
>>
>>
>>
>
>
>I think I'd have to leave that to people in the IP circles or legal team
of either Oracle, IBM, Red Hat or others, as soon as they find a common
understanding about it;-D
>
>LieGrue,
>>strub
>>
>>
>>
>>
>
>
>Cheers,
>Werner
>
>
>>On Thursday, 3 July 2014, 20:33, Werner Keil <werner.keil(a)gmail.com>
wrote:
>>>I must correct you in the sense, that the license (that "Accept and
Download" page) for the Spec is not Apache, though there is practically no
spec here for these 6 annotations.
>>>So it is a bit of a grey zone, and even EC Members with a large legal
department are in ongoing discussions over that. The "Spec" and its
Software Manifestation (normally all artifacts under "javax.something" or
"java.something" (for the few JSRs like 310 that changed their package name
in the course of the lifecycle) in Oracle's (the PMO) understanding is
under the Spec License.
>>>
>>>
>>>So strictly speaking annotations under "javax.inject" are the
"Spec",
not RI or TCK, and therefore they don't fall under Apache 2. Google Guice
and the TCK did and still do.
>>>
>>>
>>>Looking at JSRs like 107
https://github.com/jsr107/jsr107spec or 354,
you'll notice they all have this in common.
>>>Especially the JavaDoc as manifestation of the Spec (and for 330 that
is all there is of a Spec) therefore naturally fall under the Spec License,
too.
>>>
>>>
>>>Just see Java EE 7:
http://docs.oracle.com/javaee/7/api/ the JavaDoc
(for all JSRs within that umbrella) is therefore covered by the EE 7 Spec
License
>>>>Copyright © 1996-2013, Oracle and/or its affiliates. All Rights
Reserved. Use is subject to license terms.
>>>
>>>see the link under "license terms"
>>>
>>>
>>>JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a
different license footer in the standalone distribution (Apache 2) as in
the overall Java EE 7 umbrella.
>>>Which is a nightmare for users, a reason I voted against the MR or
abstained from this particular JSR as it denies what is reality at least
for the Spec and artifacts like the JavaDoc.
>>>
>>>
>>>CDI refrains from this breach. At least there is no contradicting
JavaDoc license pointer.
>>>
>>>
>>>Red Hat considers a "Dual Licensing" option for the Spec, but from
all
I heard so far, this is not how Oracle and the JCP PMO (or at least
Oracle's lawyers) see this. With the proposal of the ULA Oracle tries to
get all future JSRs to use a single license for RI and TCK.
>>>
>>>
>>>There's an ongoing discussion over details, but unless Oracle's
legal
department and PMO make a dramatic turn on these matters, JSRs filed in the
near future (including CDI 2 or beyond) would likely fall under Spec and
ULA license.
>>>
>>>
>>>Cheers,
>>>Werner
>>>
>>>
>>>On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg <struberg(a)yahoo.de>
wrote:
>>>
>>>As far as I know the history (and I have been tracking and contributing
to JSR-330 back then) most of the people were fed up _because_ they got
pushed to change the license from ALv2 to something else (cannot remember
anymore what exactly).
>>>>
>>>>
>>>>The original Apache v2 licensed work can be found here:
>>>>https://code.google.com/p/atinject/
>>>>
>>>>
>>>>
>>>>I have no clue why Oracle added the 'accept license' radio
button on
their JSR-330 download page. Maybe just a copy&paste error? The text in
this license window is in fact not ALv2 but something else which is wrong
information at best.
>>>>
>>>>
>>>>The good news: ALL the assets in JSR-330 still are ALv2!
>>>>Thus anyone can take it and enhance it.
>>>>Of course it would be good to have Bob and Jürgen on board, but
legally it might not even be necessary.
>>>>
>>>>
>>>>LieGrue,
>>>>strub
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>On Thursday, 3 July 2014, 17:35, Werner Keil
<werner.keil(a)gmail.com>
wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>I guess with only 5 or 6 annotations (and that's all the JSR
consists
of;-) if changing/improving only one or two of these was what's needed,
this could be easiest as MR, otherwise 330 is history as it would require a
new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay
there, I don't think it can move to a newer version of the JCP:
https://jcp.org/en/resources/guide-maintenance#2_7
>>>>>
>>>>>
>>>>>
>>>>>The trouble is, both Spec Leads seem unresponsive or no longer
around
(Rod Johnson left Pivotal, Pivotal in its current form does not even seem
JCP member and VMware may not be able or interested to step in for them)
maybe Pete knows best if Bob was, as until JSR 364 or even a new version of
the JSPA are finalized he could probably do it if he wants and has the time
for this right now (especially if another JSR like CDI 2 depends on it,
that can't be delayed even if this JSR may technically still be unaffected
by JCP 2.8+)
>>>>>
>>>>>
>>>>>Except for active corporate members Oracle, Red Hat or IBM the whole
EG practically disintegrated. Doug Lea and Tim Peirls may be involved
elsewhere (mostly OpenJDK from all I heard) but they have not been active
in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead
in the first place, so it is unlikely under the current circumstances it
will play an active role. Jason VanZyl and Maven I know they at least use
JSR 330 quite a bit, so they should at least be interested in its future
direction. Thoughtworks I don't recall them to be involved and Martin
Fowler himself told me of his "allergy" against such form of
standardization, so I would not count on them here either.
>>>>>
>>>>>
>>>>>So assuming a separate @Inject spec shall be maintained there are 3
options:
>>>>> 1. Bob Lee (or the other Spec Lead) responds in a timely manner
to contact attempts by Antoine and ultimately the PMO (who needs to handle
such situations) in which case a simple MR was possible
>>>>> 2. A replacement of Maintenance Lead, along the lines of
https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the
case for an MR, but should work pretty much the same way here, so the main
candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM
or Oracle for most part;-) If such condition can't be resolved, both PMO
and JCP EC would be able to help find a suitable replacement, too
>>>>> 3. A whole new JSR is filed. Although it is often the case that
the Spec Lead(s) are the same, that is not necessary, especially if the old
ones moved on or can't do this any more right now.
>>
>>>>>HTH,
>>>>>Werner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann
<kito-public(a)virtua.com>
wrote:
>>>>>
>>>>>My $0.02 is that it's worth the effort to evolve JSR-330 for the
community as a whole. I've been on projects where they tend to use those
annotations even in a CDI environment, and it makes it much easier to
switch between Spring and CDI if necessary.
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
>>>>>>
>>>>>>Hi all,
>>>>>>>
>>>>>>>Since the first mention of CDI 2.0 preparation work,
we've received
a lot of comment about JSR 330 evolution. With the release of the proposal
draft yesterday, this topic came up again. So let me give my point of view
on this subject to have an open discussion here.
>>>>>>>
>>>>>>>When we started to discuss about modularity with Pete in
last
november, my first idea was to go see what we could add in JSR 330 to make
it a true specification that could be the first module of CDI. My idea at
that time was to discuss with JSR 330 owner to see if we could bring basic
concept we have in CDI to AtInject spec. In my mind the main features would
have been:
>>>>>>> - Enhance the javax.inject.Provider<T> interface to
bring it at
the same level than javax.enterprise.inject.Instance<T>. That would have
included support for AnnotationLiteral and TypeLiteral as well
>>>>>>> - Add a Container interface (a very light BeanManger) in JSR
330
to be able to resolve beans instance from outside managed beans
>>>>>>> - Add a mechanism to get this Container from non managed
beans
(like we get access to BeanManager from JNDI or CDI class)
>>>>>>>
>>>>>>>At that time, I contacted Bob Lee without success (didn’t
tried
Pivotal since I don’t have contact there). I checked with JCP what could be
done if we’d like to see an evolution of JSR 330 and the owner doesn’t
care, there seems to have solutions but I let it aside since we were in the
middle of CDI 1.2 MR at that time.
>>>>>>>
>>>>>>>Today I’m a bit torn about this point. Working on opening JSR
330
could be like opening pandora box, since I see 2 scenarios :
>>>>>>>
>>>>>>>1) former JSR 330 owners wake up and are ok to get for a new
spec
version they lead:
>>>>>>>Knowing the history of JSR 330 vs JSR 299 I’m not sure
everything
we’d need would be heard and even if the people leading this would be
cooperative, a lot of discussion and negotiation would be needed to be sure
that this new AtInject wouldn’t contain features incompatible with CDI. So
it’d be very time consuming with no guarantee to get what we’d need at the
end.
>>>>>>>
>>>>>>>2) former JSR 330 owner don’t mind others take ownership of
their
spec to enhance it and we (Red Hat) are the one to take this ownership to
secure CDI:
>>>>>>>The best solution to minimize risk. But leading a new
specification
is a lot more work than just deciding that we have a specific basic inject
« part » in CDI 2.0. Leading a spec is very time consuming, so it could be
better on the paper but will impact CDI 2.0 new features.
>>>>>>>
>>>>>>>To sum up, as a Java EE user (like I have been for 10 years)
I’d be
happy to see this (scenario 2), but as CDI spec lead I fear that it could
lead us in a trap (going to scenario 1 or consuming precious time on
AtInject+1 instead of CDI 2.0)
>>>>>>>
>>>>>>>Your input, solutions or comment would be appreciated on this
point.
>>>>>>>
>>>>>>>Antoine
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>cdi-dev mailing list
>>>>>>>cdi-dev(a)lists.jboss.org
>>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>cdi-dev mailing list
>>>>>cdi-dev(a)lists.jboss.org
>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
>
>