Follow-up Comment #32, task #14528 (project administration): > While mathematical equations may not be copyrigtable, their expressions are.
The text around the equations are copyrightable, but the expression of the formula itself is not. The formulae expressed in the relax manual are standard forms of mathematics that any 1st year university student would be able to derive themselves, and express in LaTeX in exactly the same way. This is covered by a concept called the idea-expression divide <https://en.wikipedia.org/wiki/Idea%E2%80%93expression_divide>. A practitioner would come up with exactly the same expressions in the relax manual without ever seeing the manual, and would come up with the same LaTeX code for it. For example, according to the US Copyright Office <https://www.copyright.gov/circs/circ31.pdf> (my emphasis added): "Copyright law does not protect ideas, methods, or systems. Copyright protection is therefore not available for ideas or procedures for doing, making, or building things; scientific or technical methods or discoveries; business operations or procedures; mathematical principles; *formulas or algorithms*; or any other concept, process, or method of operation." Due to the limited and standardised way of presenting mathematical equations, the formula and its expression are not dividable. So it does not satisfy the idea-expression divide. >> Using the GPLv3+ was >> determined to be far less complicated than having a FDLed document >> interspersed with a huge number of GPLed text, graphic, and data components. >> So we chose licensing simplicity for legal clarity. > > Does it invalidate Savannah policies? The GNU guidelines say when some code > may be useful both in program and in documentation, it should be released > in parallel under the GPL and the FDL. I believe that this would be abused by some in our field to make changes that cannot be reincorporated into relax. A small subset of scientists are rather unscrupulous and only consider immediate personal gain rather than mutual benefit. If dual licensed, they could take one of the complex scripts in the manual (these are direct copies from the relax sample_scripts/ directory) and release their changes solely under the FDL licence, as is allowed with dual licensing. These changes hence cannot be reincorporated into relax as they must in turn be dual licensed by the 3rd party. So we cannot take the FDL changes and incorporate them into our GPL scripts, then copy that into the manual and dual FDL+GPL license it. This is a real issue and the pressures of academia will almost guarantee that it will be exploited! This, together with the other large quantity of GPLv3+ material in the manual, including a large percentage of auto-generated content from GPLv3+ Python source code, is why we have licensed the relax manual and API documentation GPLv3+ instead of FDLv1.3+. This concern does not apply to our webpages (excluding the HTML versions of the API and manual), hence they are FDLv1.3+ licensed. We also calculated that the GPL free software licence would have been acceptable for documentation at Savannah. The following text appeared to us to be non-exclusive for the FDL: "GNU GPL-compatible license: your license should be listed as compatible at http://www.gnu.org/licenses/license-list.html. You can also use the GNU Affero GPL, since it is effectively compatible with GPLv3. For documentation, we accept the GNU Free Documentation License (and compatible), even though is not compatible with the GNU GPL. Always use the "or any later version" wording in your notices, as otherwise future compatibility problems are crated. (Aside: for the LGPL, we can technically accept LGPL(star)-only since it can be converted to any version of the GPL, but we nevertheless strongly recommend against using LGPL(star)-only.)" After listing the GPL, the text "we accept the [FDL], even though is not compatible with the GNU GPL" reads to be discretionary. I.e. Use the GPL or FDL. We also assumed that the optional nature of the FDL in this text is because there are cases where the GPL is a better choice than the FDL. For example our auto-generated API documentation which includes annotated copies of all our source files (e.g. http://www.nmr-relax.com/api/4.0/auto_analyses.dauvergne_protocol-pysrc.html). > I don't think this addresses my concerns: the license for those files isn't > expressed consistently, and it isn't clear what tools you used for relicensing. That was fixed when I posed the previous comment. They are now consistently labelled as being LGPLv3+ licensed everywhere. > If it was a student who created the file, the chances are that the copyright > holder is their university... In some cases yes, in most cases though it is not. See for example https://www.jisc.ac.uk/guides/copyright-guide-for-students. It depends on the University's policy, as well as the copyright law in each country. In any case, it is not possible determine who the original copyright holder is with any certainty. So we cannot credit the original copyright holders in the public domain PDB 3D structure files. Only the authors listed in the headers of the files themselves are credited as being authors (but not necessarily copyright holders). > ...but anyway, when the user looks at these PDB files, their copyright > status should be clear, without asking the developers of the package. > When I look at these files, their status isn't clear for me even after > your explanation (I'm sorry, I couldn't find the statement about the data > being in public domain on Protein Data Bank websites, I admit I didn't > look for it very well). There is a README file <https://sourceforge.net/p/nmr-relax/code/ci/master/tree/test_suite/shared_data/structures/README> in the same directory <https://sourceforge.net/p/nmr-relax/code/ci/master/tree/test_suite/shared_data/structures/> that lists the files as being in the public domain. >>> and why opening SVG files in an editor like Inkscape shows that they have a proprietary license, >> >> This new Inkscape "feature" of listing the licence, which I've only just >> found out about, did not exist when these graphics were created. It seems to >> default to "proprietary" in the Inkspace application for any SVG without >> <cc:license/> tags. But that does not make our vector graphics "proprietary". > >No, but it raises an issue. > >The task is to prominently and unambiguously notify the user >about the status of each file. > >Inkscape is one of the natural ways to edit SVG files, and it doesn't show >your embedded comments; moreover, it may even not preserve them after minor >unrelated edits. This is not quite good. > >> Should we be adding "Creative Commons" tags to our SVG files just for the >> benefit of the current version of the Inkscape application? > >CC? Your comments say "GPLv3+". The XML SVG tag invented by the Inkscape developers is <cc:license/>. The "cc" in this tag refers to "Creative Commons". I think that the Inkscape developer who came up with this needs to be educated about free software! Also, the <cc:license/> tag is not part of the SVG standard <https://www.w3.org/TR/2011/REC-SVG11-20110816/eltindex.html>, as defined by the W3C. As <cc:license/> is not part of the SVG standard, editing the SVG in any other vector graphics editor will cause the Inkscape-Creative-Commons-specific tag to be lost. A quick test using LibreOffice Draw to open and save such an Inkscape SVG shows this to be the case. And it may change in a newer Inkscape version, as it is not part of the SVG standard. I also cannot find any mention of this specific tag on the Inkscape mailing lists. I cloned their repository and can see it was added prior to their first git commit back in 2006. But their old SVN repository no longer seems to be online so I cannot chase down the origin of this tag. So again I would prefer not to add such narrow, software and CC license specific tags. This does not advance the free software cause. The fact that they list a file as being "proprietary" if that file does not adopt their non-SVG-standard Inkscape-specific and Creative-Commons-specific XML tag is clearly a bug/failure on their part. > I can't see the second page in PDFs; would the copyright line be valid > for them all? The manual is only generated with each relax release. We used to have about 6-10 releases per year. Since the Gna! shutdown over a year ago, we do not have the required free software infrastructure behind the project to make any releases. The copyright line now added to the source code repository will appear in the PDFs once we can perform our long overdue next release. The copyright statement has now been slightly clarified: """ Copyright (C) 2001-2018 the relax development team Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License (GPL), Version 3 or any later version published by the Free Software Foundation. The Oxygen Icons used herein are licensed under the terms of the GNU Lesser General Public License (GPL), Version 3 or any later version published by the Free Software Foundation. """ > Anything more than 15 lines long is presumably copyrightable; if not, > it makes sense to add an explanation why it isn't. As I am not a lawyer who can say that a list of names is not copyrightable, I have modified the graphics/oxygen_icons/README file to list the AUTHORS files under the same LGPLv3+ licensing and authorship as the rest of the Oxygen Icon files <https://sourceforge.net/p/nmr-relax/code/ci/master/tree/graphics/oxygen_icons/README>. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/task/?14528> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
