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

Re: Object Management Group redistributable files

Hi Francecsco,

On Sun, Oct 01, 2006 at 10:45:32PM +0200, Francesco Poli wrote:
> >  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).

Sorry, I'm not sure I was clear enough in the first email. The OMG
writes the CORBA specs, and delivers the bare-minimum files matching
those specs as a base for a real implementation.  The JacORB team wrote
a compliant CORBA stack based on those files.

So yes, upstream thinks deviating from the standard they have written
should be avoided.

> Firstoff, forbidding *any* functional modification obstructs useful
> external contributions that could help to *enhance* compliance with the
> standard.
> But, more importantly, who says that deviations from a standard are bad
> in themselves?

Well, the standard authors :)

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

Indeed.  But I don't think this use case is forbidden by the readme.txt.
The next to last paragraph reads: `files [...] shall be provided by
*conformant* products "as is"' (emphasis is mine).  I believe this does
not prevent non-conformant products to alter them.

> 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

This has been discussed in [3] and lead to a rewrite of the files in

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

The Open Group handles compliance already[1], but not for free, even
though this has already happened[2].  A DFSG-free standard-compliance
test would be great, but I don't see this happening in a near future :(

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

I'm looking into this.



[1] http://www.opengroup.org/certification/corba-home.html
[2] http://www.opengroup.org/press/7jun99_a.htm
[3] http://lists.gnu.org/archive/html/classpath/2005-03/msg00025.html

Reply to: