Forgot your password?
typodupeerror
Databases Programming Software GNU is Not Unix IT

Copyright Status of Thermodynamic Properties? 154

Posted by kdawson
from the consider-crown-copyright dept.
orzetto writes "I work at a research institute, and programming models of physical systems is what I do most of the time. One significant problem when modeling physical processes is finding thermodynamic data. There are some commercial solutions, but these can be quite expensive, and to the best of my knowledge there are no open source efforts in this direction. In my previous job, my company used NIST's Supertrapp, which is not really that expensive, but is written in Fortran, and an old-fashioned dialect at that. As a result, it is a bit difficult to integrate into other projects (praised be f2c), and the programming interface is simply horrible; worse, there are some Fortran-induced limitations such as a maximum of 20 species in a mixture. I was wondering whether it would be legal to buy a copy of such a database (they usually sell with source code, no one can read Fortran anyway); take the data, possibly reformatting it as XML; implement a new programming interface from scratch; and publish the package as free software. Thermodynamic data is not an intellectual creation but a mere measurement, which was most likely done not by the programmers but by scientists funded with our tax money. What are your experiences and opinions on the matter? For the record, I am based in Germany, so the EU database directive applies."
This discussion has been archived. No new comments can be posted.

Copyright Status of Thermodynamic Properties?

Comments Filter:
  • NIST - Public Domain (Score:5, Informative)

    by John Hasler (414242) on Sunday July 26, 2009 @08:18AM (#28826089) Homepage

    If the NIST program is the product of the work of US Government employees it is in the public domain. I would not be surprised if many of the commercial closed-source programs for the same purpose are based on it. In any case, tabulated data is not protected by US copyright so someone in the US could certainly do as you suggest.

  • Re:FORTRAN (Score:4, Informative)

    by Anonymous Coward on Sunday July 26, 2009 @08:25AM (#28826117)

    Huh? Recent versions (ie, in the past couple decades) of Fortran are really very decent for scientific calculation, in many respects better than C. There's a ton of computational chemistry software, for example, written primarily in modern Fortran.

  • FAQ claims copyright (Score:2, Informative)

    by Mathinker (909784) on Sunday July 26, 2009 @08:46AM (#28826225) Journal

    The FAQ [nist.gov] claims that the US government has a copyright on the material. This could be possible if the material was not directly generated by the NIST itself --- for example, they paid a contractor to generate it and it is considered a "work for hire".

    The facts themselves probably can't be considered to be under copyright.

    OTOH, I agree with a previous poster that you should consult a lawyer if you want to actually do anything which isn't sheeple-ish with the data.

  • Re:Department (Score:3, Informative)

    by morgan_greywolf (835522) on Sunday July 26, 2009 @08:58AM (#28826273) Homepage Journal

    Anything produced by the United States Federal Government (which the National Institute of Standards and Technology certainly qualifies as), is in the public domain.

    That's what he meant.

  • by morgan_greywolf (835522) on Sunday July 26, 2009 @08:59AM (#28826283) Homepage Journal

    OTOH, Maybe they just ripped off the Koreans.

    Looks like the same info to me. [korea.ac.kr]

    (But IANAP)

  • by SwashbucklingCowboy (727629) on Sunday July 26, 2009 @09:01AM (#28826291)

    A database is copyrightable. See http://www.bitlaw.com/copyright/database.html [bitlaw.com]

  • by modrzej (1450687) <<m.m.modrzejewski> <at> <gmail.com>> on Sunday July 26, 2009 @09:27AM (#28826391)

    People using this NIST data do it because it has NIST sign on it, so they don't risk being dependent on tabulated values from not exhaustively verified source. If you're rewritting the source code, you should take care to establish means by which users could check that data are unaltered with respect to what NIST servers contain. If you work for renowned institute, that should be easy, just store the database on your server and sync it with NIST, along with sources of data cited at NIST website.

    As it comes to Fortran programming, it's optimal language for scientific computing. Modern dialects have some of the power of C (allocatable arrays, long subourtine names, free format code, modules, interoperability with C), but, what is preferable in scientific computing, programmer isn't encouraged to tinker with machine-specific stuff. Many existing codes are written in Fortran, e.g. powerful LAPACK library and many computational chemistry packages, so for many physicists/chemists/engineers Fortran is the only language they know and care of. Moreover, Fortran in recent years has gained parallel-programming functionality thanks to OpenMP (it's provided with features eqivalent to that in C/Cpp).

  • by Alsee (515537) on Sunday July 26, 2009 @09:44AM (#28826461) Homepage

    The EU database law specifically does not protect foreign databases unless that foreign country also creates a database a law and establishes mutual protection. The US has no such protection, in fact it seems no country outside the EU has established reciprocal database protection. It should be possible to do this open source project based on data from the US or from anywhere outside the EU.

    The FAQ [nist.gov] claims that the US government has a copyright on the material.

    The factual data in that database cannot be protected by copyright, it is not protected as a database in the US, and is not covered under EU law. The only copyright they could claim on it is either if it contains creative images or creative text or the like, then those particular elements could be protected, or they could perhaps claim a copyright on the creative arrangement and formatting of the data in the database. Both of those issued can be avoided.

    What can be done is use this database and read out the needed factual data elements and then re-write it into the database for the open source project. Purely factual text-fields such as the name of an element or compound or whatever can be copied, just be careful not to copy any images or free-form text fields such as descriptive text or explanatory text. Then write the data out in your own arrangement. The best thing to do there is to arrange the data in some strict alphabetical or numerical order - there is no creativity and no copyrightability in that sort of unique ordering. That means not only storing the records in alphabetical order, but also order the data elements within each record in name-of-field alphabetical order. It might even be a good idea to rename any fields that care reasonably open to custom naming. There is no need to rename a field like "name" or "address" or "phone number", but a field like "work contact number" could easily be called "work phone".

    The best way to go about it would be to create a mostly-empty, but functioning, database before even looking at your intended source material, that way by definition there is no copying of the formatting of the database. Once there is a functioning database design then the factual data elements can be copied from the source to fill the already-designed database.

    -

  • by GPSguy (62002) on Sunday July 26, 2009 @09:49AM (#28826493) Homepage

    I tend to work in the atmospheric sciences, where, as one might guess we work with microphysical processes and thermodynamic data. I would second the recommendation that working from the original, authoritative publications would be a good approach. If you're well-versed in the field already, you're familiar with the seminal works. If you're not, your job is bigger than you realize, as programming for a scientific project is rarely just finding equations and re-coding them, or finding a database of physical constants and calling them. You've got to understand where in the domain in question they come into play and use appropriate equations and parameterizations.

    Fortran, even Fortran-66, is rarely unreadable. However, it often is written like a short story in a local dialect. The author has a method and style, and you have to understand it, or at least become conversant with it, before reading and understanding the flow of the code occurs. I should point out that this is really not different from any other language. Fortran, however, has been maligned because its roots were not in object-basis. Fortran 90 and Fortran 95 both, however, comply with the OO paradigm. The inherent problem is, CS departments often don't teach Fortran, and their faculty will tell you how horrid it is. Why? Because their discipline is COMPUTER science, not, say, solid earth geophysics, and they're conversant with a number of languages.and feel they can pick the best one for the job. The geophysicist, on the other hand, spent his time learning how and why those pesky tectonic plates move around, something the computer scientist never really studied unless, maybe, he took a rocks-for-jocks class and got really interested. Rather than mastering C, C++, Java and C#, the geophysicist learned just enough Fortran to get his work done, and proceeded down a different path. Since Fortran ("FORmula TRANslation") was developed to help discipline scientists transform their equations to operable code, this really makes sense.

    My first computer initiation was using Fortran (Fortran-II) on an IBM 1401 while I was still in junior high school. My first formal course in programming used SWIFT, BASIC and SNOBOL, over the course of a summer while in high school. Virtually every course in college I took (I was not a CS major, but could/should have been from my transcript) was in Fortran (plus a pair of assembly language courses) because the choices were Fortran, Cobol or assembly. Imagine, if you will, not having a "modern language around, and having to code decent I/O or even decent APIs with that choice.

  • by pearl298 (1585049) <<moc.liamg> <ta> <zasretawekim>> on Sunday July 26, 2009 @10:46AM (#28826947)

    A database is copyrightable, but the applicable case law from when I practised (YEARS AGO!) was the phone directory - it was held to be sufficient that the copier rearranged and reorganised the information to provide a "mere spark of creativity".

  • by Anonymous Coward on Sunday July 26, 2009 @12:23PM (#28827673)

    I am a federal worker and I oversee some contracts that involve writing Fortran codes for simulating nuclear reactors. That is not quite right. You need to consult the Federal Acquisition Regulation (FAR), Chapter 27. Specifically, see

    27.404-2 Limited rights data and restricted computer software.
    and
    27.404-3 Copyrighted works.

    http://www.acquisition.gov/far/current/html/Subpart%2027_4.html#wp1041836

    If you read those sections, and take the time to really understand the definitions they use, and read the appropriate appendices, etc, you will find that the legalese seems to indicate that the contractor IS allowed to copyright data generated in performance of the contract (with the government's permission), and that the goverment maintains an exclusive, irrevocable license to use such data for its purposes, but the government does not necessarily maintain an exclusive right to "redistribute" such data.

    It is my belief that the law is written this way so as to give potential contractors an incentive to do business with the government. If a company can't build a portfolio of intellectual property, then it has no means of distinguishing itself from the competition. In the long run, the government would not get the best value for its $.

  • Re:FORTRAN (Score:5, Informative)

    by MaskedSlacker (911878) on Sunday July 26, 2009 @02:51PM (#28828701)

    I used to work solely in FORTRAN for simulation work. The big advantage of Fortran90/95 over C is that the compilers are heavily optimized for doing iterated operations over every value of an array. So for say, fluid dynamics, it really is the best. I suspect you might be able achieve a similar speed in C, but that you would have to hand optimise instead (ugh).

  • What database? (Score:3, Informative)

    by ephraimhorse (707223) on Sunday July 26, 2009 @09:49PM (#28832103)
    All the formulation for the prediction of water properties are published by International Association for the Properties of Water and Steam (IAPWS) so that they can be used. It is often important to use exactly the same correlations so that that all the thermodynamic data are self-consistent. Therefore the formulations are standardized by an international body. I do not think that the use of this formulae is in any way restricted because such restriction would defeat the very purpose - standarization. See http://www.iapws.org/ [iapws.org] for the collection of the current formulations. There may be a restriction for a particular implementation (computer program) or sets of tables ( "lookup tables" and interpolation are often used for performance). Not sure. Hope someone starts an extension to implement these kind of things in Gnumeric. Cheers. Ephraim the horse.

I'm all for computer dating, but I wouldn't want one to marry my sister.

Working...