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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
