[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: COMCIFS approval for imgcif dictionary version 1.0
- To: <imgcif-l@bnl.gov>
- Subject: Re: COMCIFS approval for imgcif dictionary version 1.0
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Wed, 27 Dec 2000 21:52:36 -0500 (EST)
- In-Reply-To: <Pine.SGI.3.96.1001227120230.4046B-100000@lsx12n.nsls.bnl.gov>
There are two copyright questions: 1. The intellectual property status of the dictionary itself. 2. The intellectual property status of the API and various software development efforts. The dictionary itself is covered by the IUCR policy, the most recent version of which is at: http://www.iucr.org/iucr-top/ipr.html I think most people will find that the IUCr policy is reasonable and very supportive of both academic and commercial development efforts. Additional intellectual property restrictions come into play for particular software development efforts. For example, the CBF API is covered by an assortment of notices which are given in http://www.bernstein-plus-sons.com/software/CBF/doc/CBFlib_NOTICES.html none of which an academic developer or an open-source commercial developer should find particularly onerous. A closed source commerical developer, since they would be trying to assert additional intellectual property rights would have to exercise some care to avoid conflicts with existing intellectual property rights. Clearly only a lawyer can give a person in such a situation meaningful advice. However, to a layman, it seems highly likely that no problems would arise for a closed source developer wishing to use the existing CBF API in support of a closed source program if, 1. They carry the existing credit lines and notices with respect to the API forward in the documentation of the closed source package; and 2. Simply use the API through its specified interfaces; and 3. Do not assert any new intellectual property rights with respect to the API per se. This is not to say that other arrangements might not be possible, just that such a highly conservative approach should allow a closed source developer to move forward without fuss, using this API as easily as they move forward using the many other libraries needed for modern software development. Naturally, other conditions may apply to other software packages. Personally I highly recommend an open source approach for all software packages used in science, but, if a closed source program of value to the community needs to be adapted, I suspect we will be able to work things out in a spirit of scientific cooperation. Regards, Herbert J. Bernstein P.S. You may notice that the copy of the IUCr policy in the CBFlib notices differs from the wording of the IUCr policy on the IUCr web page. The copy on the IUCr web page is a more recent release, and it is our intention to update the copy in the CBFlib notices to agree at a future date. -- HJB ===================================================== **** BERNSTEIN + SONS * * INFORMATION SYSTEMS CONSULTANTS **** P.O. BOX 177, BELLPORT, NY 11713-0177 * * *** **** * Herbert J. Bernstein * *** yaya@bernstein-plus-sons.com *** * * *** 1-631-286-1339 FAX: 1-631-286-1999 ===================================================== On Wed, 27 Dec 2000, Robert Sweet wrote: > Dear Brian, > > I'm gratified that the version 1.0 dictionary has been approved. I hasten > to say that if I might have played some early catalytic role, the bulk of > the original inspiration came from Andy Hammersley, and the real work to > tune it up and prepare a workable set of subroutines was done by Paul > Ellis and Herb Bernstein. It is they, along with the others who attended > our workshop > (http://www.iucr.org/iucr-top/cif/mmcif/ndb/cbf/cbf-workshop.html) who > deserve the credit, and I'm happy to accept any blame. > > As we attempt to disseminate the ideas and to gain acceptance of the > standard within the community, it will be good if we understand what this > approval by COMCIFS means. Specifically, on this document > http://www.iucr.org/iucr-top/cif/mmcif/ndb/cbf/index.html I see this > statement: "CIF is copyrighted by the IUCr and it is intended that CBF > would eventually be treated in the same manner." I presume that the CBF > standard reflected in the dictionary below is now actually copyrighted. I > gather that the fundamental description of the copyright is in this > statement: > http://www.bernstein-plus-sons.com/software/CBF/doc/CBFlib_NOTICES.html I > wonder if perhaps there is an equivalently detailed statement within the > IUCr site; I can't find it. > > I presume there are teeth to the copyright in that no-one may use this > standard and sell it, nor may they corrupt it then call it imgCIF or CBF, > or be subject to some legal problems from IUCr. On the other hand, I also > presume there's no coercion from the IUCr to vendors or programmers to use > it, and that this sort of persuasion will need to come from the community. > > Perhaps we need specifically to understand what this copyright means in > terms of commercial groups like MSC using the Stanford APIs. I believe > we'd like it if they were able to use them in the packages they sell but > with attribution to the authors; somehow they're selling their code but > not the Stanford APIs. Does this make sense or am I too naive? Can > anyone help, please? > > Thank you, Brian and David Brown, for your enthusiastic support with this. > Best wishes to all for the new year, or, depending how you count, the new > millennium. > > Bob > > ========================================================================= > "Reply" may fail. Better to use the address below > Robert M. Sweet E-Dress: sweet@bnl.gov (that's L > Biology Dept. Phones: not 1) > Brookhaven Nat'l Lab. *New* 631 344 3401 (Office) > Upton, NY 11973 Area 631 344 5642 (Beamline at NSLS) > U.S.A. Code 631 344 3407 (Facsimile) > ========================================================================= > > On Fri, 22 Dec 2000, Brian McMahon wrote: > > > I am pleased to announce that the IUCr Committee for the Maintenance of the > > CIF Standard (COMCIFS) has approved version 1.0 of the imgCIF dictionary for > > use in the creation and interpretation of imgCIF and CBF data files. > > Members of this list are invited to preview the release dictionary at > > ftp://ftp.iucr.org/pub/cif_img.dic > > or in a navigable HTML version at > > http://www.iucr.org/iucr-top/cif/imgcif/cif_img_1.0.html > > > > This early release is to allow members of the imgcif list to verify that > > there are no major errors in this version. An official release notice will > > be posted early in the New Year. > > > > I should like to take this opportunity to congratulate and thank Herbert > > Bernstein, Andy Hammersley, Bob Sweet, Paul Ellis and the many other > > participants at the Brookhaven workshop and in community discussion who have > > brought this work to this stage. > > > > Best regards to all. > > > > Brian McMahon > > Co-ordinating Secretary, COMCIFS > > > > >
Reply to: [list | sender only]
- References:
- Re: COMCIFS approval for imgcif dictionary version 1.0 (Robert Sweet)
- Prev by Date: Re: COMCIFS approval for imgcif dictionary version 1.0
- Next by Date: CoreCIF dictionary version 2.2 released
- Prev by thread: Re: COMCIFS approval for imgcif dictionary version 1.0
- Next by thread: More thoughts on polarization, divergence, time-stamps in CBF
- Index(es):