On Jul 30, 2010, at 1:58 PM, Jean Brefort wrote: > Somebody argued about the same kind of issue for another project (namely > Goffice, see https://bugzilla.gnome.org/show_bug.cgi?id=463248) that > even if all the code was rewritten, the code ownership would not change > at least if the changes are incremental. If this is true, ...
There is a gray and fuzzy area where it's hard to tell. That's what lawyers and lawsuits are for. But OpenBabel isn't near that point, since there's parts like the SMILES parser which has a distinctive Roger Sayle code style to it. That link states basically the same thing. I was going to bring up the USL v. BSDi lawsuit where there was a rewrite of the non-public domain code, but I see now that that was settled out of court. Craig James <[email protected]> > OpenEye should first consider whether they're willing to relicense their > contributions to OpenBabel under a less restrictive license. They've been > asked several times, and have ignored the requests. While that would be nice, everyone who started with OpenBabel came into it with clear knowledge that the license was GPLv2 only, so it shouldn't have been a surprise. Did you contribute your canonicalization changes in the hopes the OpenEye would some day make their code v2 "or later"? (And should I contribute code in the hopes of it being "or BSD" in the future? ;) ) What's the meaning of "less restrictive license?" It's the GPLv2. It's not compatible with GPLv3, but then GPLv3 isn't compatible with GPLv2, so why not call them both restrictive? Or is the restriction that others can't retrospectively change the license? And, what obligations does OpenEye have, or advantages are there, for them to change the license? Do you really want to deny access to the InChI library as a bargaining chip, and is that a useful goal for the InChI Consortium? Remember, they spent a developer-decade or so working on OELib, released under the GPL. They found it wasn't a good business model for them and switched to a new code base with a proprietary license. The old code was still free, and the fact that after a decade more of time that the code hasn't been replaced or otherwise rewritten is a statement to its quality and usefulness. So why the bad vibes towards their past contribution? Imagine if it the contributor had been one person who is now a beach bum on some island in the South Pacific, and who is impossible to contact. Would you have worse or better feelings towards being unable to change the license? On Jul 30, 2010, at 2:51 PM, Geoffrey Hutchison wrote: > Incidentally, I find it ironic that a few years ago, > Open Eye was publicly bashing InChI and now want to use it. People change. So do companies. So does the perception of InChI. A few years ago some people pushed that InChIs would be a replacement for SMILES. Some people at OpenEye pushed strongly against that perception - since InChIs CANNOT replace SMILES for many things. Roger Sayle was the most vocal about it, and he's not even at OpenEye these days. Or, perhaps their customers are asking for it, so the extra overhead of dealing with a foreign code base might now be worthwhile, but not a job they want to take on willingly. I'm personally still amazed that InChI has had such uptake given that it's a single implementation with no human-language explanation of what the code does, an incomplete format spec, a hard-to-read code base, and when the Indigo people did their own implementation, they came up with differences in interpretation for some things. My best guess is there was a lot of high-level politics to get it seeded in some of the big databases, tied with a low cost of entry. But I'm not privy to such matters. Andrew [email protected] ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Blueobelisk-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
