www.pudn.com > ejbca_3_5_3(1).zip > LICENSE

EJBCA is released under the LGPL license (see LICENSE-LGPL or
http://www.opensource.org/licenses/lgpl-license.html).

A clarification about the relationsship between the LGPL and Java can be found on:
http://www.gnu.org/licenses/lgpl-java.html
In short, LGPL works exactly the same way in Java or in C. I.e. using a library (jar) 
from an application does not make the application a derivatve work that must be 
licensed under the LGPL.

To clarify the case for EJBCA, this means that:
The code itself (java code, tools, jars, etc) can NOT be changed without changes beeing 
put under the same licence as EJBCA.
Using the interfaces to use or integrate EJBCA in another project, without 
modifying EJBCA code is allowed and does not put any constraints on the product 
(the derived work).

Any modification to java code which is part of EJBCA should fall under LGPL.
For example creating a new MyAlgSigningSession (implementing interface
ISignSession) replacing the EJBCA RSASigningSession and deploying
MyAlgSigningSession by modifying src/ca/META-INF/ejb-jar.xml to use the new 
MyAlgSigningSession should make MyAlgSigningSession a piece of LGPL code.

Taking EJBCA and integrating it into a web application by using the interfaces to 
the RA (IUserAdminSession through rmi) to create users for EJBCA from another source
(integrated with user registration in the application) does NOT put any 
constraints on the whole application itself. A notice that the application uses 
EJBCA and the possibility to get the source of EJBCA used in the application 
should be provided.

Using the plug-in APIs it is possible to add functionality to EJBCA that does not fall under the LGPL.
Implementing the plug-in API usually means implementing an interface in EJBCA and entering the
classpath in a configuration page (for example custom publishers).
A custom publisher would not have to be released as LGPL.