Re: Standard implementation of constant, copyright or not ?
On Sat, 17 Jan 2015 01:58:09 + Simon McVittie wrote: [...] it is entirely possible to have a standard that does not change or is under strict change-control, without having copyright infringement as a stick to hit people with. A work derived from a standard is not, itself, the standard (unless/until the relevant standards body says it is), but it is potentially still a useful thing for a third party to be able to construct without breaking the law. I agree with you, I was actually going to reply with some very similar consideration... [...] Surely the harmful thing is not deriving new works from the standard, the harmful thing is misrepresenting those derived works by claiming that they are the standard when they are actually not? Exactly, and if the standards body feels like it, it may also cryptographically sign the official version(s) of the standard document, in order to give people a means to verify whether they are reading the unaltered version or some unofficial derivative work instead. I am convinced that this is the right tool to distinguish between official and modified versions of a standard specification. Using copyright in order to prevent other people from distributing modified versions is unnecessary and harmful! XMPP's XEPs (approximately equivalent to RFCs) are all permissively-licensed http://xmpp.org/extensions/xep-0001.html#appendix-legal and might be an interesting model. Very interesting indeed, thanks for pointing them out! Bye. -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpndpL8vkkVe.pgp Description: PGP signature
Re: Standard implementation of constant, copyright or not ?
The included headers are distributed verbatim. The headers are included verbatim (stored as a constant string) into the binary. The headers provide physical constants and physical concepts to a model compiler. In case the user does not have a set of headers of his own, the binary spits out the verbatim copy to allow the model to be processed. In other words, the user has rights over the LGPL portion and can bypass the non-LGPL pass if he/she wishes to. (...) So it seems it is not an integral part of the compiler, just a handy hardcoded value. I would change the compiler (preferably at upstream) to read those entries from individual files at /usr/share/ if not provided by the user. Put a package with just those files in non-free. If the compiler AND the user didn't provide those AND those default files don't exist (non-free pkg not installed), abort with a message explaining what they need. Note that I am not the original author of the ADMS package. I happen to maintain the latest LGPL version of it. I just read the LGPL 2.1 a couple of times. To be compliant with Section 2 of LGPL 2.1 the headers should not be in the ADMS package in the first place. I am afraid I will have to take the headers out. A non-free package with two header files might be a good option for Debian. Maybe it is just easier to inform users that the files need to be fetched from somewhere on the web and placed elsewhere on their system. Next I will contact Accellera IP Committee to check if they would consider a more permissive license on future versions of their headers. That would allow them to be included in free software. I don't have the knowledge and/or resources to argue on the claim that the headers are facts and not copyrightable. If not I will think about ways not to anger and frustrate the users offering a tool that does not work out of the box. As I understand it, the compiler _could_ work without those headers (assuming the unlikely case that the user had them himself). Otherwise, it can live in contrib and depend on the non-free package. That is right, the compiler does work without the headers. If the user adds a 00-Book-VAMS.fm `include disciplines.vams to the model and there is no such file on the working directory the compiler assumes the user wants the LRM standard header. It dumps the stored headers from the binary as text and things work as expected. From now on it will have to warn users about missing headers and where to find them.
Re: Re: Standard implementation of constant, copyright or not ?
Guilherme Brondani Torri wrote: Next I will contact Accellera IP Committee to check if they would consider a more permissive license on future versions of their headers. That would allow them to be included in free software. I asked the current VAMS TC chairman, who said he had long discussions with Richard Crozier, Bastien Roucaries (QUCS), Ryan Fox (ADMS maintainer) and Stan and Lynn from Accellera in 2013, and Accellera does not want more permissive licenses. In particular, Stan Krolikoski wrote: Upon looking at the standard, I would say that any sort of open source licensing of the packages in Annex D is to be strictly avoided. That Annex is clearly identified as being normative, which means that it is part of the standard. Licensing part of standard (as opposed to licensing examples) under open source seems counterproductive-- a standard is fixed until the relevant standards WG decides to update it. Indeed, I would strongly argue that if anyone is able to make changes to part of a given standard as they wish, then it ceases to be a true standard. I agree with him. If the user needs to download the headers, this is where to get them from: http://www.accellera.org/downloads/standards/v-ams -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b93b12.8070...@analog.com
Re: Standard implementation of constant, copyright or not ?
On 16/01/15 16:23, Geoffrey Coram wrote: In particular, Stan Krolikoski wrote: Licensing part of standard (as opposed to licensing examples) under open source seems counterproductive-- a standard is fixed until the relevant standards WG decides to update it. Indeed, I would strongly argue that if anyone is able to make changes to part of a given standard as they wish, then it ceases to be a true standard. I understand this position, but it is entirely possible to have a standard that does not change or is under strict change-control, without having copyright infringement as a stick to hit people with. A work derived from a standard is not, itself, the standard (unless/until the relevant standards body says it is), but it is potentially still a useful thing for a third party to be able to construct without breaking the law. For instance, here are a couple of useful derivative works: * a version of a standard with additional explanatory text (rationale, examples, ...) after each paragraph * a proposal for changes that someone would like to see in the next version of the standard, adapting some paragraphs from the current version to illustrate what they want Surely the harmful thing is not deriving new works from the standard, the harmful thing is misrepresenting those derived works by claiming that they are the standard when they are actually not? XMPP's XEPs (approximately equivalent to RFCs) are all permissively-licensed http://xmpp.org/extensions/xep-0001.html#appendix-legal and might be an interesting model. S -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b9c1b1.9020...@debian.org
Re: Re: Standard implementation of constant, copyright or not ?
Hi, On Thu, 2013-07-11 at 21:08 +0200, Bastien ROUCARIES wrote: Hi, I plan to package adms on the behalf of debian science in order to package qucs. I have a legal problem: Some file are : Copyright A9 2007Accellera Organization, Inc. Standard definitions This file contains the standard definition package constants.vams for Verilog-AMS HDL. Extracted from standard book http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/stddef.html The file is here: https://github.com/upverter/ADMS/blob/master/admsXml/constants.vams I do not believe it is copyrightable. Who has the copyright doesn't really matter. What matters is what permissions the license gives you. From https://github.com/upverter/ADMS/blob/master/COPYING it seems that the code is under the LGPL-2.1 - which means you can redistribute it. You are, however, not allowed to remove the copyright. Sorry to dig up such an old thread; I found this when I was looking to update the header files in ADMS to the latest ones, which are part of Verilog-AMS LRM 2.4, copyright 2014 Accellera Systems Initiative. I think there are some errors in the posts in this thread, which ought to be corrected. The files constants.vams and disciplines.vams are part of the copyrighted LRM. As such, they should not have been included in the ADMS source code under LGPL. (The copyright date is also incorrect, it should be 2000, since these files were extracted from the LRM 2.0: http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/cover.html ) The values in that mere list of facts (constants.vams) are actually tricky; NIST has updated the value of the electron charge (for example) as its best accepted value has changed, and some models use outdated values. If you extracted your diode model parameters using the value of P_Q from Spice 3f5 (which used 1.60219e-19), you would not want the diode to be simulated using the NIST 2010 value of 1.602176565e-19, because then the simulation would not match the measurement. Someone might think that they are improving the files by updating the values, but they are not, and this would detract from the standard. Further, I don't think that disciplines.vams is just a list of facts, and this file is also included in the git repository: https://github.com/upverter/ADMS/blob/master/admsXml/disciplines.vams though it was not mentioned in the original post. -Geoffrey (I am not a lawyer, but I am a member of the Accellera Verilog-AMS technical committee) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b7d561.9070...@analog.com
Re: Standard implementation of constant, copyright or not ?
Guilherme Brondani Torri guito...@gmail.com wrote: I am currently maintaining the ADMS package (LGPL 2.1). The package is now hosted at: https://github.com/Qucs/ADMS The two headers that are causing us trouble are these: https://github.com/Qucs/ADMS/blob/master/admsXml/constants.vams https://github.com/Qucs/ADMS/blob/master/admsXml/disciplines.vams We received a request to update to the latest version of the headers. See: https://sourceforge.net/p/mot-adms/patches/4/ The new headers from LRM 2.4.0 (May 2014), annex D. have the following copyright notice: // Copyright(c) 2009-2014 Accellera Systems Initiative Inc. // 1370 Trancas Street #163, Napa, CA 94558, USA. // // The material in disciplines.vams is an essential part of the Accellera Systems // 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-ch...@lists.accellera.org). // All other rights reserved. // // Version 2.4.0 How ADMS stand on this context? Can distribute at all the new headers? Does the new headers change anything with respect to Debian package inclusion policy? The license for the new headers is not a free license. I think it could go into non-free. You could, in principle, extract the constants from NIST yourself. The disciplines.vams file is more complicated, because it is not just constants. It looks like a number of tolerances that have been chosen somewhat arbitrarily. Maybe you could ask Accellera for a better license? IETF RFC's have the same problem, and cause recurring problems for Debian. https://wiki.debian.org/NonFreeIETFDocuments Cheers, Walter Landry
Re: Re: Standard implementation of constant, copyright or not ?
Thank you Walter. Perhaps I should be more specific about the usage of the headers. The included headers are distributed verbatim. The headers are included verbatim (stored as a constant string) into the binary. The headers provide physical constants and physical concepts to a model compiler. In case the user does not have a set of headers of his own, the binary spits out the verbatim copy to allow the model to be processed. In other words, the user has rights over the LGPL portion and can bypass the non-LGPL pass if he/she wishes to. The LGPL 3 seems to have a clause for combined work situation like the above, but the LGPL 2.1 does not. Confusing. Would a change of ADMS license help here? On the argument that the headers are facts (not copyrightable). On the reply by Geoffrey he disagrees that the disciplines.vams is just a list of facts. I read about the clean-room implementation. One has to read the LRM to be able to use the language,anyone that touches the LRM is contaminated and excluded from a clean-room implementation. I don't mean it ironically. I don't see how to handle it. At the moment I only see four options: - write a clean-room implementation (if by all means possible) - remove the headers and push the burden to the users - try to discuss an alternative license with Accellera - argue that the content of the headers are not copyrightable I really hope we can find a suitable way to distribute the original standard headers to the users. If not I will think about ways not to anger and frustrate the users offering a tool that does not work out of the box. Please advise. Guilherme 00-Book-VAMS.fm
Re: Standard implementation of constant, copyright or not ?
On 15/01/15 23:39, Guilherme Brondani Torri wrote: Thank you Walter. Perhaps I should be more specific about the usage of the headers. The included headers are distributed verbatim. The headers are included verbatim (stored as a constant string) into the binary. The headers provide physical constants and physical concepts to a model compiler. In case the user does not have a set of headers of his own, the binary spits out the verbatim copy to allow the model to be processed. In other words, the user has rights over the LGPL portion and can bypass the non-LGPL pass if he/she wishes to. (...) So it seems it is not an integral part of the compiler, just a handy hardcoded value. I would change the compiler (preferably at upstream) to read those entries from individual files at /usr/share/ if not provided by the user. Put a package with just those files in non-free. If the compiler AND the user didn't provide those AND those default files don't exist (non-free pkg not installed), abort with a message explaining what they need. If not I will think about ways not to anger and frustrate the users offering a tool that does not work out of the box. As I understand it, the compiler _could_ work without those headers (assuming the unlikely case that the user had them himself). Otherwise, it can live in contrib and depend on the non-free package.
Re: Re: Standard implementation of constant, copyright or not ?
I am currently maintaining the ADMS package (LGPL 2.1). The package is now hosted at: https://github.com/Qucs/ADMS The two headers that are causing us trouble are these: https://github.com/Qucs/ADMS/blob/master/admsXml/constants.vams https://github.com/Qucs/ADMS/blob/master/admsXml/disciplines.vams We received a request to update to the latest version of the headers. See: https://sourceforge.net/p/mot-adms/patches/4/ The new headers from LRM 2.4.0 (May 2014), annex D. have the following copyright notice: // Copyright(c) 2009-2014 Accellera Systems Initiative Inc. // 1370 Trancas Street #163, Napa, CA 94558, USA. // // The material in disciplines.vams is an essential part of the Accellera Systems // 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-ch...@lists.accellera.org). // All other rights reserved. // // Version 2.4.0 How ADMS stand on this context? Can distribute at all the new headers? Does the new headers change anything with respect to Debian package inclusion policy? Please advise. Guilherme Brondani Torri 00-Book-VAMS.fm
Re: Standard implementation of constant, copyright or not ?
On Thu, Jul 18, 2013 at 12:55 AM, Christian Holm Christensen wrote: On Thu, 2013-07-11 at 21:08 +0200, Bastien ROUCARIES wrote: The file is here: https://github.com/upverter/ADMS/blob/master/admsXml/constants.vams I do not believe it is copyrightable. Who has the copyright doesn't really matter. What matters is what permissions the license gives you. From His question was about whether or not this file can be placed under copyright at all. If it isn't copyrightable then we don't need any license to distribute/modify etc. Hard to tell but I guess not. In any case it doesn't matter if the code as a whole is LGPL. On another note, please ask upstream to drop generated .c files from the git repository and tarball. If they refuse, please ensure that these files are rebuilt from scratch during debian/rules build. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6g1ruxxopee-pf3uca8q32krlw3wzptdyeno9zdjkk...@mail.gmail.com
Re: Standard implementation of constant, copyright or not ?
Hi, On Thu, 2013-07-11 at 21:08 +0200, Bastien ROUCARIES wrote: Hi, I plan to package adms on the behalf of debian science in order to package qucs. I have a legal problem: Some file are : Copyright A9 2007Accellera Organization, Inc. Standard definitions This file contains the standard definition package constants.vams for Verilog-AMS HDL. Extracted from standard book http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/stddef.html The file is here: https://github.com/upverter/ADMS/blob/master/admsXml/constants.vams I do not believe it is copyrightable. Who has the copyright doesn't really matter. What matters is what permissions the license gives you. From https://github.com/upverter/ADMS/blob/master/COPYING it seems that the code is under the LGPL-2.1 - which means you can redistribute it. You are, however, not allowed to remove the copyright. Perhaps you can compare the situation to C. While the standard pretty much gives you all of the code you need to write to make various headers, it does not mean that the FSF cannot copyright their version of stdio.h (see /usr/include/stdio.h). What you do perhaps need to check, is that the license given in the above quoted URI covers the file in question. What is the legal status? How can I document on debian/copyright ? If all files are covered by the same copyright, then you only need to specify that in the debian/copyright. If some individual files (or perhaps groups that can be captured by a glob pattern) have _different_ copyright notices (not licenses necessarily) then that must be listed in debian/copyright. An example of such a situation can be seen in /usr/share/doc/root-system/copyright Note, this means you have to read _every_ file you intent to redistribute as source or otherwise and make sure that the proper copyright notices are reproduced in debian/copyright - a tedious job, but it has to be done. Note, even if a file does not carry a copyright notice it is _still_ the copyright of the author. But again - it's really the license that matters. Perhaps you want to contact upstream and hear what they have to say - does the LGPL-2.1 apply to all files? What kind of copyright notice applies to files that does not carry one explicitly? and so on. Do I need to do a clean room implementation ? Kinda hard to do a clean-room implementation when the standard tells you what it should be :-) Hope this helps. Yours, -- ___ | Christian Holm Christensen |_| | - | | Address: Sankt Hansgade 23, 4Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen NCell: (+45) 24 61 85 91 _|Denmark Office:(+45) 353 25 447 | Email: ch...@nbi.dkWeb:http://cern.ch/cholm | | -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374101724.11371.51.ca...@cholm.hehi.nbi.dk
Standard implementation of constant, copyright or not ?
Hi, I plan to package adms on the behalf of debian science in order to package qucs. I have a legal problem: Some file are : Copyright A9 2007Accellera Organization, Inc. Standard definitions This file contains the standard definition package constants.vams for Verilog-AMS HDL. Extracted from standard book http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/stddef.html The file is here: https://github.com/upverter/ADMS/blob/master/admsXml/constants.vams I do not believe it is copyrightable. What is the legal status? How can I document on debian/copyright ? Do I need to do a clean room implementation ? Bastien -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAZQbC0ntu2LqkPLptD_UVfiRvEDTX391F9Y_qVewM=_...@mail.gmail.com
