No, Section 2 of the BCL doesn't say that at all (to me).
When Section 2, part (iv) says you can only redistribute "subject to a license... consistent with the terms in this Agreement..." I take that to mean that the BCL applies to each receiver of the software. When you pass on the Software, you pass on the license, in total.
And Section 1 says "use internally... for the sole purpose" of developer support. This applies to any use of the software, whether you get it direct from Sun or by FedEx from an Open Source pure-hearted goodnik. The point isn't the redistribution as such, it is the limitation on the use, a limitation which I am concerned many users of open source software may not know about.
I don't see the escape... first, there isn't a conflict (only an extension), but even if there was then the superceding supplemental license is pretty clear about your right to use being limited to internal, development support.
I'm not saying JBoss organization violates a license by redistributing the binaries of the Sun code; I'm saying the code so redistributed apparently cannot be used in production/deployment.
No, SCSL isn't about restricting code modifications; it's about restrivting the use the code is put to, and who gets to do it.
The license to redistibute seems to require that you impose the same license on those to whom you redistribute, right? (See section 2(iv) as cited). Now go back to that same supplemental license, Section 1, and look at what rights you (or those to whom you redistribute) have with respect to actual use:
1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software for the sole purpose of designing, developing and testing your Java applets and applications ("Programs").
This says to me that you can use Sun code to help you build your programs, but not to deploy them. And that restriction is transitively applied.
The primary license Section 1 grants you the right to "internal use" only.
So as I (no lawyer) read it, when JBoss et al redistributes Sun RI code in their codebase, they restrict the codebase they supply to being used only for developer support purposes. When I as a user adopt the JBoss codebase, I accept the possibility that the license owner (Sun) may come and demand I stop using the code in deployed production use.
Nope - the Lutris enterprise app server doesn't use Sun RI code. Take a look at the codebase, it was open source until fairly recently.
The "monolithic" aspect is that if you use a branded J2EE platform you get all the APIs, of the specified version. Agreed you don't have to use all the APIs; your app can be portable to non-J2EE platforms, but the platform has to carry them, and in exactly those API levels. So you can't (legally) have an EJB 1.1 container and a Servlet 2.3 container, for instance - they belong to different monoliths. If you mix those, your platform isn't "J2EE." Thus your app can't call Servlet 2.3 APIs on a J2EE 1.2 platform. Simple as that.
Slashdot Mirror
When Section 2, part (iv) says you can only redistribute "subject to a license ... consistent with the terms in this Agreement..." I take that to mean that the BCL applies to each receiver of the software. When you pass on the Software, you pass on the license, in total.
And Section 1 says "use internally ... for the sole purpose" of developer support. This applies to any use of the software, whether you get it direct from Sun or by FedEx from an Open Source pure-hearted goodnik. The point isn't the redistribution as such, it is the limitation on the use, a limitation which I am concerned many users of open source software may not know about.
I'm not saying JBoss organization violates a license by redistributing the binaries of the Sun code; I'm saying the code so redistributed apparently cannot be used in production/deployment.
The license to redistibute seems to require that you impose the same license on those to whom you redistribute, right? (See section 2(iv) as cited). Now go back to that same supplemental license, Section 1, and look at what rights you (or those to whom you redistribute) have with respect to actual use:
1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software for the sole purpose of designing, developing and testing your Java applets and applications ("Programs").
This says to me that you can use Sun code to help you build your programs, but not to deploy them. And that restriction is transitively applied.
The primary license Section 1 grants you the right to "internal use" only.
So as I (no lawyer) read it, when JBoss et al redistributes Sun RI code in their codebase, they restrict the codebase they supply to being used only for developer support purposes. When I as a user adopt the JBoss codebase, I accept the possibility that the license owner (Sun) may come and demand I stop using the code in deployed production use.
The "monolithic" aspect is that if you use a branded J2EE platform you get all the APIs, of the specified version. Agreed you don't have to use all the APIs; your app can be portable to non-J2EE platforms, but the platform has to carry them, and in exactly those API levels. So you can't (legally) have an EJB 1.1 container and a Servlet 2.3 container, for instance - they belong to different monoliths. If you mix those, your platform isn't "J2EE." Thus your app can't call Servlet 2.3 APIs on a J2EE 1.2 platform. Simple as that.