On Tuesday, June 17, 2003, at 10:34 AM, Ethan Merritt wrote:
In article <20030609161925132-0700@cgl.ucsf.edu> you write:
The UCSF Resource for Biocomputing, Visualization, and Informatics is pleased to announce the newest release of UCSF Chimera, an interactive molecular modeling system. It is free to academic and non-profit users and is available for Windows, Linux, Mac OS X, IRIX, and Tru64 Unix. It can be downloaded from http://www.cgl.ucsf.edu/chimera
Chimera has the capabilities common to many molecular graphics programs, as well as a number of more unique features, including:
[snip]
- Extensibility as a design principle, allowing users to create custom modules without changing Chimera code.
This is unlikely to happen so long as Chimera is distributed with such a restrictive license.
The following 2 clauses pretty much kill my interest in developing any software to work with Chimera.
3 The Licensee agrees that any modifications or derivative works based on the Software are considered part of the Software and the Licensee hereby assigns all copyright in all such modifications and derivative works to the Regents.
4 The Licensee shall not disclose in any form either the delivered Software or any modifications or derivative works based on the Software to third parties without prior written authorization from the Regents.
This is a pity, since otherwise Chimera looks like an interesting target for integrating a number of graphics projects I am involved in.
I don't believe these clauses actually restrict your ownership or ability to redistribute modules/extensions you develop for Chimera. I believe they restrict your ability to modify/redistribute the Chimera source code itself. Extensions don't require modification of Chimera source code. Nonetheless, I have cc'ed this reply to the head of our lab, Tom Ferrin (tef@cgl.ucsf.edu), so he can hopefully confirm that what I have said is indeed the case. Certainly points 3 & 4 of the license could be explicitly clarified to _not_ restrict ownership/distribution of extensions. There are already two extensions being distributed by third parties (SSD: ssd.rbvi.ucsf.edu; ViewFeature: http://feature.stanford.edu/documentation.html) that I'm fairly certain did not require written authorization by the Regents.
Is there a forum in which we can request that these clauses be dropped from the license?
chimera-dev@cgl.ucsf.edu is used to handle concerns/questions of Chimera developers. I've cc'ed this reply there also. Sincerely, Eric Pettersen pett@cgl.ucsf.edu
Eric Pettersen wrote:
On Tuesday, June 17, 2003, at 10:34 AM, Ethan Merritt wrote:
In article <20030609161925132-0700@cgl.ucsf.edu> you write:
The UCSF Resource for Biocomputing, Visualization, and Informatics is pleased to announce the newest release of UCSF Chimera, an interactive molecular modeling system. It is free to academic and non-profit users and is available for Windows, Linux, Mac OS X, IRIX, and Tru64 Unix. It can be downloaded from http://www.cgl.ucsf.edu/chimera
Chimera has the capabilities common to many molecular graphics programs, as well as a number of more unique features, including:
[snip]
- Extensibility as a design principle, allowing users to create custom modules without changing Chimera code.
This is unlikely to happen so long as Chimera is distributed with such a restrictive license.
The following 2 clauses pretty much kill my interest in developing any software to work with Chimera.
3 The Licensee agrees that any modifications or derivative works based on the Software are considered part of the Software and the Licensee hereby assigns all copyright in all such modifications and derivative works to the Regents.
4 The Licensee shall not disclose in any form either the delivered Software or any modifications or derivative works based on the Software to third parties without prior written authorization from the Regents.
This is a pity, since otherwise Chimera looks like an interesting target for integrating a number of graphics projects I am involved in.
I don't believe these clauses actually restrict your ownership or ability to redistribute modules/extensions you develop for Chimera. I believe they restrict your ability to modify/redistribute the Chimera source code itself. Extensions don't require modification of Chimera source code. Nonetheless, I have cc'ed this reply to the head of our lab, Tom Ferrin (tef@cgl.ucsf.edu), so he can hopefully confirm that what I have said is indeed the case. Certainly points 3 & 4 of the license could be explicitly clarified to _not_ restrict ownership/distribution of extensions.
There are already two extensions being distributed by third parties (SSD: ssd.rbvi.ucsf.edu; ViewFeature: http://feature.stanford.edu/documentation.html) that I'm fairly certain did not require written authorization by the Regents.
This issue needs to be clarified in the licensing document because the document itself does not refer to extensions or define the nature of derived work, and because since the Chimera source code is not currently distributed (thus, those clauses are fairly irrelevant to most developers who write chimera extensions). It may be clear to the developers of Chimera whether extensions themselves are derivative, but it is not clear to an external user (as Ethan's message points out). The nature of extensions should be defined in the document because the idea of extension is conceptually core to Chimera and is the strongly preferred method of adding functionality to Chimera. I suspect that the Chimera developers believe that runtime-binding of Chimera functionality from an extension (such as a Chimera module import), and use of the Chimera object model does not render an extension a derivative work. Extensions such as SSD and ViewFeature which are independently distributed are not in any way "proof" that extensions are not derivatives. It just means that the Regents have not llitigated against their independent distribution. If the Regents do not litigate to ensure that extensions comply with the derivative clauses of the license agreement, then the license loses much of its legal foundation. In other words, if you don't go to court to protect your intelletual property, then it's much easier for other people to use your intellectual property without crediting you. Dave
On Tuesday, June 17, 2003, at 10:18 PM, David E. Konerding wrote:
This issue needs to be clarified in the licensing document because the document itself does not refer to extensions or define the nature of derived work, and because since the Chimera source code is not currently distributed (thus, those clauses are fairly irrelevant to most developers who write chimera extensions). It may be clear to the developers of Chimera whether extensions themselves are derivative, but it is not clear to an external user (as Ethan's message points out). The nature of extensions should be defined in the document because the idea of extension is conceptually core to Chimera and is the strongly preferred method of adding functionality to Chimera. I suspect that the Chimera developers believe that runtime-binding of Chimera functionality from an extension (such as a Chimera module import), and use of the Chimera object model does not render an extension a derivative work.
Extensions such as SSD and ViewFeature which are independently distributed are not in any way "proof" that extensions are not derivatives. It just means that the Regents have not llitigated against their independent distribution. If the Regents do not litigate to ensure that extensions comply with the derivative clauses of the license agreement, then the license loses much of its legal foundation. In other words, if you don't go to court to protect your intelletual property, then it's much easier for other people to use your intellectual property without crediting you.
Tom Ferrin should be returning from an out-of-town trip today, so I expect his feedback here soon. Just a couple of comments from me... The Python part of the Chimera source code is distributed. Eventually the C++ will be too, once the compilation process is organized and documented well enough that someone besides the internal developers would be able to follow it. According to Title 17, section 101 of the US code: A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. So again, I think the license only restricts modification and redistribution of Chimera itself. I agree wholly that the license should state this explicitly, in terms a non-lawyer can understand. Eric Pettersen UCSF Computer Graphics Lab pett@cgl.ucsf.edu http://www.cgl.ucsf.edu
On Wednesday 18 June 2003 10:38, Eric Pettersen wrote:
The Python part of the Chimera source code is distributed. Eventually the C++ will be too, once the compilation process is organized and documented well enough that someone besides the internal developers would be able to follow it.
The fact that the python source is distributed makes these license clauses even more problematic than if it were not. As it stands I am reluctant to even download the chimera source, out of concern that reading it would open up the worst-case scenario in which my future python code is considered "a derivative work", having been tainted by knowledge of the details on the chimera source. Yes, this is a paranoid view of licensing, but one supported by events in the larger open source world (cue replay of the great SCO/IBM/linux soap opera now playing on a media channel near you). If you are going to distribute the Chimera source, then you should do so under some more reasonable open source license. I do not like the GPL myself, but some variant of the "artistic license" or the BSD or python licenses would probably work.
According to Title 17, section 101 of the US code:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
So again, I think the license only restricts modification and redistribution of Chimera itself. I agree wholly that the license should state this explicitly, in terms a non-lawyer can understand.
You may think so, and I may agree with you it should be so, but if there is any universal consensus on the issue at all, it is that the legal definition as applied to computer code has yet to be pinned down. The current SCO brouhaha is an extreme case, but just look - they are claiming that all unix development since about 1985 is a "derivitive work" based on the System V code. We all hope they are laughed out of court, but the point is that billion dollar law suits are being filed over the issue of what is or is not a derivitive work. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195
participants (3)
-
David E. Konerding -
Eric Pettersen -
Ethan Merritt