Object Management Group redistributable files
Hello,
I intend to package JacORB[1] but I need your advice on the Object
Management Group "redistributable-but-unmodifiable"[3] files.
JacORB includes a slightly modified version of the OMG Java definitions
for the IDL Java Language mapping. The original files are available
from [2].
Because modifications on those files are restricted, they are considered
non-free[4]. Eventually in the classpath project those files were
rewritten from the specs to prevent any problem[5].
The readme.txt file included in the OMG zip file reads:
This archive contains the Java definitions that are specified and
required by the IDL Java Language mapping as specified in CORBA 2.5.
A complete Java ORB implementation will need to provide more code,
either because it is generated from standard IDL (e.g. dynamic any) or
because it contains vendor-specific generated code (e.g stubs, helpers,
etc.)
This archive contains more files than are strictly necessary because it
is a goal that the whole package be compilable. Files, for which, dummy
implementations are provided are designated as such in the comment
header. (Examples include the helper classes that needed in order to
allow Interface Repository routines to be compiled.)
Files which are not so marked shall be provided by conformant products
"as is". Vendors may not add or subtract functionality from them
(though of course things such as comments, formal parameter names, etc.
which do not change functionality may be modified.)
The binary portability requirement implies that a user can take the
generated stub and associated files (helpers, holders, etc.) that were
generated using a particular vendor's IDL compiler, and use them on
another vendor's runtime. Hence the above limitations restricting an
implementor's freedom to modify the required classes.
and the corresponding specification[6] contains, in section 1.1.1:
1.1.1 org.omg.* Packages
The Java language mapping is highly dependent upon the specification
of a set of standard Java packages contained in org.omg.*. The
complete and exact contents (the Java sources) of all portions of
the Java mapping which cannot be mapped using the rules for mapping
IDL to Java are specified in an associated zip file, which is
available on the OMG's public server as document ptc/2002-01-02.
This includes Java classes for all PIDL, native types, and ORB
portability interfaces. The zip file is the definitive statement of
the exact contents of the packages. While every attempt has been
made to assure that the text contained in this document is accurate,
there may be some minor discrepancies. The zip file is the
authoritative statement of the specification because it contains the
actual Java code.
It is probable that OMG specifications that are adopted in the
future may make changes to these packages (e.g., to add a method to
the ORB). Care must be taken to ensure that such future changes do
not break binary compatibility with previous versions.
1.1.1.1 Allowable Modifications
Conforming implementations may not add or subtract anything from
the definitions contained in the org.omg.* packages except as
follows:
* Vendor-specific implementations for the init methods of
org.omg.CORBA.ORB must be supplied. Since these methods are
static, they cannot be overridden by the vendor-specific ORB
subclass, but must be provided in the org.omg.CORBA.ORB class
itself.
* The addition of javadoc comments for documenting ORB
APIs. Removal of specified javadoc comments, in particular
comments marking code as deprecated, is forbidden.
* The names of formal parameters for methods for which the
entire implementation is provided by the vendor.
My understanding is that those restrictions enforce binary
compatibility. But they *do* restrict modifications, and therefore
those files fail to comply with the DFSG.
What is your opinion on this?
(Note that if the OMG files do not fulfill the DFSG, I could still patch
JacORB so that it only use GNU classpath org.omg files, which are
aligned on CORBA 2.3 whereas JacORB is on 2.5. That would mean lowering
CORBA compliance but would give us a DFSG-free Java ORB)
Thanks,
Thomas
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349540
[2] ftp://ftp.omg.org/pub/docs/ptc/02-01-02.zip
[3] http://lists.gnu.org/archive/html/classpath/2004-12/msg00083.html
[4] http://lists.gnu.org/archive/html/classpath/2005-03/msg00025.html
[5] http://developer.classpath.org/mediation/ClasspathCurrentTopics#head-4561b50e237b0c8a0d2af19f65a44acb8945bca8
[6] http://www.omg.org/cgi-bin/apps/doc?formal/02-08-05.pdf
Reply to: