#4 Update header files from LRM 2.4

[Geoffrey Coram]

Verilog-AMS LRM 2.4 was approved and released last summer (May 2014), and the standard definitions in Annex D have been updated: disciplines.vams, constants.vams

In particular, constants.vams has different versions of the physical constants, which are periodically updated to "best accepted values" by NIST. For example,
define P_Q_SPICE 1.60219e-19define P_Q_OLD 1.6021918e-19
define P_Q_NIST1998 1.602176462e-19define P_Q_NIST2010 1.602176565e-19

Also, the header lines in the new files provides terms under which the material may be copied.

[Geoffrey Coram]

With better formatting:

`define P_Q_SPICE 1.60219e-19
`define P_Q_OLD 1.6021918e-19
`define P_Q_NIST1998 1.602176462e-19
`define P_Q_NIST2010 1.602176565e-19

[Guilherme]

Thank you. I will make sure it gets updated and marked on the Changelog.

[Richard C]

There's a problem here. What exactly are the terms, does it allow modification of the files?

Previously it did not, meaning we cannot incorporate them in Qucs. Doing so woud prevent us distribtuing Qucs via debian, which requires this permission in their policies. There are long discussions aout this on the mailing lists. We may need to back out any changes derived from the copyrighted files.

[Richard C]

I should add that, you cannot copyright a fact, so as long as we're just changing the values in our files based on our knowledge of the correct values, that will be fine.

[Guilherme]

Richard, what about this disclaimer in annex D. Will it be enough for Debian?

// Initiative ("Accellera") Verilog-AMS Language Standard. Verbatim copies of
// the material in this Annex may be used and distributed without restriction.
// All other uses require permission from Accellera IP Committee
// (ipr-chair@lists.accellera.org).
// All other rights reserved
//
// Version 2.4.0

[Geoffrey Coram]

So, presently, ADMS includes the header files from some previous LRM, marked with

Copyright C 2007 Accellera Organization, Inc.

The LRM specifies that you have to get permission from Accellera to copy it, so ADMS is presently in violation of those terms.

[Richard C]

As far as I know ADMS is not yet distributed by Debian?

[Richard C]

Yep, exactly, verbatim copies only. This is against Debian plolicy, which insists that you have the right to modify code. This is exactly the problem discussed at length on the dev mailing list, including contacting Debian themselves, and the authors of the standard. Trust me, I wa dismayed by this as well. The only way to get around it is to do a clean room implementation.

[Guilherme]

Richard,

I guess this is the status with Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501264

Is this the mail thread you mention?
https://lists.debian.org/debian-legal/2013/07/msg00042.html

[Geoffrey Coram]

The mail thread there sort of misses the point; the VAMS header files are copyrighted, and they were included in the ADMS source tree without the proper license terms, such that it appears they are under LGPL.

It sort of defeats the purpose of a standard if one can modify it willy-nilly.

[Geoffrey Coram]

And actually, there's no particular reason that ADMS needs to include the header files. When compiling a model that includes those files, if they are not present, then ADMS creates them for you. But it could just as well error out with a message saying how to get them from Accellera.

[Guilherme]

Let me see if I understand the situation. Clearly I am not a lawyer.

1) Accellera the copyright owner of LRM 2.4.0 (May 2014) provides a standard definitions of disciplines.vams andconstants.vams` headers (Annex D) allowing these to be "used and distributed without restriction. All other uses require permission from Accellera IP Committee"

2) ADMS is LGPL already includes the older versions of the headers (year 2007), which have no mention about usage and distribution.
https://github.com/Qucs/ADMS/blob/master/admsXml/constants.vams
https://github.com/Qucs/ADMS/blob/master/admsXml/disciplines.vams

3) ADMS wants to include the LRM 2.4.0

--

Fact 1) is quite sensible, Accellera does not want the standard to be modified.

Fact 2) is already in conflict. ADMS tries to help users by including and providing the headers on demand during compilation of models. However the LGPL enforce the right to modify of any source files distributed under it.

Fact 3) is also in conflict with LGPL since the permission does not allow for unrestricted modification.

--

Correct me if I am wrong, but it all boils to:

• LGPL enforcing the right to modify
• Accellera being protective about modifications and copying ownership

How can we solve the gridlock?

As for the constants.vams one could independently code an exact copy header contents. Many constants on this LRM header where taken from elsewhere.

For disciplines.vams, these are quite similar to examples already provided elsewhere on the LRM. Eventually one could come up with an equivalent header.

So, eventually we could work around the problem. However this would lead to a very bizarre situation. I don't think that anyone of sane mind would like to modify a fix standard.

Frankly I see no benefit to users in shipping a compiler without headers. It is tool with missing parts. It will only anger everyone.

LGPL cannot be changed. Accellera might release a more permissive header adequate for the open-source licenses. ADMS could (should actually) remove or replace the headers.

What can we do to solve this situation? How the situation is handled in other projects that include header files defined in copyrighted standards? Please advise.

[Geoffrey Coram]

Does LGPL actually require that these files be modifiable? These header files are not used in the compilation of the ADMS tool; they are used by ADMS when it runs on certain input files.

[Guilherme]

Geoffrey, that I do not know. I just replied the the email thread in the hope someone else (a lawyer) can help us to disentangle this.
https://lists.debian.org/debian-legal/2015/01/msg00011.html