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
classpath.
> 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.
Thanks,
Thomas
[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: