Here's my promised message about the rsync discussions in and outside the working group.
The sidr mailing list shows exchanges about rsync around Oct 30-31, 2006 with Joe Abley expressing concerns about interop of different implementations, and 28-31 Mar 07 starting with William Leibzon expressing concerns about IESG/IETF process. Those message also include messages describing the features that are needed and how rsync satisfies those. That's about it. But the discussion during meetings and in private exchnages has snowballed: (1) rsync is not a URI OK, we'll get it registered based on the RFC (2) rsync is not an rfc and the author is not interested in making it one OK, we'll do a third party registration based on the spec (3) there is no stable spec for rsync (aka "the code is the spec") OK, we'll register the URI based on ... the code? (if we can) (4) there are (a few) wg concerns about non-interoperability of independent implementations, due to lack of spec OK, we'll presume that everyone uses the open-source implementation. (5) rsync has gone through some non-backward-compatible version changes in the past. OK, we'll hope the rsync project doesn't do that again, else new versions of rsync with non-backward compatible features would require a flag day. You may recall a mention in Monday's meeting of license difficulties for commercial implementations. At this point in the history, I discovered that the rsync open source project used a license that forbid charging for any code that included their code. That would have made commercial implementations problematic. However, I just discovered that with the announcement of rsync 3.0 on March 1, 2008 they have moved from GPL version 2 to GPL version 3: http://www.samba.org/rsync/GPL.html >From a first glance through, I can not find similar text that would prohibit charging for code that includes their code. People who are used to reading these GPL licences should take a look to see if you see limits on commercial use of the rsync code. So the difficulty about commercial implementations could be OBE. --Sandy _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
