[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-register-public] [task #14528] Submission of relax

From: Edward d'Auvergne
Subject: [Savannah-register-public] [task #14528] Submission of relax
Date: Fri, 4 May 2018 05:08:00 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #32, task #14528 (project administration):

> While mathematical equations may not be copyrigtable, their expressions

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
<>.  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
<> (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
>> 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+

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 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.

> 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

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
> holder is their university... 

In some cases yes, in most cases though it is not.  See for example  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
in the same directory
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
>> default to "proprietary" in the Inkspace application for any SVG without
>> <cc:license/> tags. But that does not make our vector graphics
>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
<>, 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


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]