[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Object Management Group redistributable files

On Sat, 30 Sep 2006 21:15:27 +0200 Thomas Girard wrote:

> The readme.txt file included in the OMG zip file reads:
>  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.)

This is definitely a non-free restriction on modification (fails to meet

>  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.

This is a broken logic reasoning.
It seems that upstream think that, *since* modifying functionality could
deviate from a standard and break binary compatibility (which is true),
*then* the license must absolutely forbid any modification to
functionality (which is IMHO wrong).

Firstoff, forbidding *any* functional modification obstructs useful
external contributions that could help to *enhance* compliance with the

But, more importantly, who says that deviations from a standard are bad
in themselves?
A piece of software that conforms to a standard could usefully be
modified into a derivative work that does completely different things
and thus obviously does not conform to the above standard anymore!
Or the derivative work could even conform to another standard (maybe a
more recent version of the same standard!).

To sum up: modifications should be *not* be disallowed.  Upstream could
be recommended to release the work in a DFSG-free manner (suggested
licenses: GPLv2 <http://www.fsf.org/licensing/licenses/gpl.txt>
or Expat <http://www.jclark.com/xml/copying.txt>) and, if they feel
like, to separately provide a standard-compliance test (itself DFSG-free
under the same license, but with the official version GPG-signed by
them) that can check any standard-compliant-wannabe implementation in
order to see, well, if it can be claimed to be standard-compliant.
That way, derivative works would be allowed, even non-conforming ones.
Simply, there would be an easy test to tell conforming and
non-conforming derivatives apart and users could clearly know what they
would be using.
Does this make sense to you?
> 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?

As I said above, I agree that the quoted restrictions are non-free.

> (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)

A DFSG-free non-recent Java ORB is maybe better than a non-free
more-recent one.
But of course, it would be far better to have a DFSG-free recent one! 
If upstream is persuaded to do what I described above, we could manage
to reach this goal!

Usual disclaimers: IANADD, IANAL.

But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

Attachment: pgpgJ8jTiQmam.pgp
Description: PGP signature

Reply to: