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 DFSG#3). > > 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 standard. 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