Philip,
As far as I know, that is true. I think the only way that it could work would be for the original authors in R to dual license them and then for Roby to dual license JDistlib, etc.
That being said, I really think we are going to have a rough way of it if we try to get every package that we work with dual licensed and/or into Orbit. I get the distinct feeling that we (the Group) seem to be the only people who think that is a good idea. So, instead, I think we should take advantage of WORKS-WITH dependencies and the Eclipse Marketplace. We've been discussing this on the Steering Committee calls and I have been looking into it. I am also in the process of reconfiguring a machine at ORNL to host the bits,
eclipseice.ornl.gov (we can change the name if needed).
There is a bunch of stuff that we (again, the group) want to use, but can't because of license incompatibilities. The truth is that most of the code in the science world is released under licenses that are and will be incompatible with the EPL and I don't believe that we should spend our time trying to get them into Orbit. My understanding of the Marketplace is that it was essentially invented to provide a means for such content to be integrated into products, so I think we should take advantage of that. I propose that we develop a kind of "extras" Science project that contains everything we want to use but can't get into Orbit. Then users can download our projects from Eclipse.org, open the Marketplace and install the "extra" bundles either from ORNL or some other institution. Note that there are many ways to streamline this process to make it easy for the users.
This has certain architectural implications for our projects if we go down this route. The biggest thing is that we have to author our work to function without these TPLs and to turn on the extra functionality once they are installed. There will be a fair amount of code that we develop in that project to handle the wiring. This is most commonly done through service interfaces and extension points and is, for example, the primary reason that EAVP was designed around the IVizService interface. Ultimately this makes for a better design than directly coding to the TPL classes anyway.
Hopefully Wayne will correct me if I am wrong, but I think as long as there is a clear boundary defined by an interface on the Eclipse side and realized by a TPL on the... er... TPL side, then a WORKS-WITH dependency would be appropriate and we wouldn't have any IP issues if the TPLs were distributed via the Marketplace and not with our downloads at Eclipse.org.
We are already working in this direction on Eclipse ICE and EAVP. We typically have short deadlines on both of those projects and the government doesn't take "No, we can't distribute that because it isn't in Orbit" or "We can't use the software tools that you paid millions to develop because they are licensed under the GPL, etc." for answers. ;-) This strategy seems like a good alternative to me and we can always still work to get some stuff directly into Orbit. Hopefully
eclipseice.ornl.gov will be fully reconfigured in a week or so and we can start testing it.
As usual, I welcome your thoughts and those of the rest of the group.
Jay
