Je ne m'étais pas rendu compte que ce fil dégénérait...
Donc pour mettre les choses au clair, la license des sources du JDK est la SCSL, et pas la sun binary license agreement qui ne concerne que les binaires et que tu cites. Elle est utilisée entre autres pour le j2se, j2me, j2ee et jini. Il y a un lien vers un rtf ici: http://java.net/choose_license.csp(...)
Je reprends la question:
est-ce que la SCSL qui est la license du JDK peut imposer des restrictions sur d'autres implémentations compatibles avec Java?
La définition de Modifications par la SCSL indique que cette license couvre toute implémentation des spécifications; la license ne couvre pas que du code mais prétend couvrir les spécifications et leurs implémentaions. Petits extraits:
"Covered Code" means Community Code and Modifications.
"Modifications" means any (a) change or addition to Covered Code, or (b) new source or object code implementing any portion of the Technology Specifications, but (c) excluding any incorporated Reference Code.
"Technology Specifications" means the functional, interface and operational specifications and documentation for the Technology designated by Original Contributor at the Technology Site from time to time.
II. PURPOSE.
Original Contributor is licensing the Reference Code and Technology Specifications and is permitting implementation of Technology under and subject to this Sun Community Source License (the "License") to promote research, education, innovation and product development using the Technology.
Le problème est donc dans la définition de Modifications.
Ça peut sembler ridicule, mais l'application de la SCSL s'est soldée par un gros chèque (arrangement à l'amiable) de la part de jBoss, qui par malheur prétendait implémenter j2ee. Enhydra a cessé le développement d'un serveur d'applications open source pour ces mêmes raisons. Dans les deux cas le code était neuf, indépendant et sans copyright de Sun. http://www.javalobby.org/java/forums/m91797326.html(...)
Je note qu'il n'y a pas encore eu de procès, seulement des arrangements à l'amiable dans ces deux cas. Peut être que la license est invalide. Mais en tout cas, ça explique très bien pourquoi les projets de réimplémentation préfèrent n'avoir rien à voir avec cette license.
[^] # Re: Sun, pas de code source ?!?
Posté par Tobu . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
Donc pour mettre les choses au clair, la license des sources du JDK est la SCSL, et pas la sun binary license agreement qui ne concerne que les binaires et que tu cites. Elle est utilisée entre autres pour le j2se, j2me, j2ee et jini. Il y a un lien vers un rtf ici: http://java.net/choose_license.csp(...)
On trouve une analyse ligne à ligne dans un bouquin O'Reilly: http://www.oreilly.com/catalog/osfreesoft/book/(...) , chapitre 5.
Je reprends la question:
est-ce que la SCSL qui est la license du JDK peut imposer des restrictions sur d'autres implémentations compatibles avec Java?
La définition de Modifications par la SCSL indique que cette license couvre toute implémentation des spécifications; la license ne couvre pas que du code mais prétend couvrir les spécifications et leurs implémentaions. Petits extraits:
"Covered Code" means Community Code and Modifications.
"Modifications" means any (a) change or addition to Covered Code, or (b) new source or object code implementing any portion of the Technology Specifications, but (c) excluding any incorporated Reference Code.
"Technology Specifications" means the functional, interface and operational specifications and documentation for the Technology designated by Original Contributor at the Technology Site from time to time.
II. PURPOSE.
Original Contributor is licensing the Reference Code and Technology Specifications and is permitting implementation of Technology under and subject to this Sun Community Source License (the "License") to promote research, education, innovation and product development using the Technology.
Le problème est donc dans la définition de Modifications.
Ça peut sembler ridicule, mais l'application de la SCSL s'est soldée par un gros chèque (arrangement à l'amiable) de la part de jBoss, qui par malheur prétendait implémenter j2ee. Enhydra a cessé le développement d'un serveur d'applications open source pour ces mêmes raisons. Dans les deux cas le code était neuf, indépendant et sans copyright de Sun. http://www.javalobby.org/java/forums/m91797326.html(...)
Je note qu'il n'y a pas encore eu de procès, seulement des arrangements à l'amiable dans ces deux cas. Peut être que la license est invalide. Mais en tout cas, ça explique très bien pourquoi les projets de réimplémentation préfèrent n'avoir rien à voir avec cette license.