Comments (32)
I like the idea of a CC-BY badge in the PDF if we can work that.
from article_templates.
Do we need the licensing terms IN the article, or is in the github repo adequate? It seems to me the latter would be fine (most readers won't need it in the article I don't think).
from article_templates.
Do we need the licensing terms IN the article
Those terms then make it clear what can be done with that particular .pdf; in theory, the GitHub repository license might not apply to that particular version of the .pdf.
from article_templates.
The pdf
must include the terms of the license, however even a markdown badge would do. Technically there is no automatic association between the platform license (the github repo in this case) and the materials distributed (the pdf of the article).
Indeed, the tex
template should also include the license, as otherwise it is valid to simply recompile and distribute the compiled pdf.
from article_templates.
A few quick questions:
- For CC-BY, you mean this, right? https://mirrors.creativecommons.org/presskit/buttons/88x31/png/by.png
- Are we thinking of a macro for the LaTeX class or just a "put your license here" spot in the template with sample text / graphics?
- Can we come up with a short list of the expected licenses? There can always be the option of something different, but what if we make things easy by having the usual licenses ready to go.
- CC-BY
- Government "non-license" license
I can work up some examples.
from article_templates.
Can we come up with a short list of the expected licenses? There can always be the option of something different, but what if we make things easy by having the usual licenses ready to go
I think that these are the ones that will be used; we want to use CC-BY, unless not allowed. I think that we should require them to put SOMETHING there; there must be some license. Note that there's still some pending question on whether CC0 is the correct one to use for government -- search for CC0 on https://github.com/livecomsjournal/livecomsjournal.github.io/blob/master/_author_instructions/01_policies.md -- but for now we can use whatever language was suggested by your legal office.
Are we thinking of a macro for the LaTeX class or just a "put your license here" spot in the template with sample text / graphics?
I was thinking of a macro that had the sample text for the possible choices (Gov, CC-BY, something you put but it has to be something).
For CC-BY, you mean this, right? https://mirrors.creativecommons.org/presskit/buttons/88x31/png/by.png
As long as we are sure we are displaying it correctly according to their instructions, yes.
from article_templates.
Here are some first attempts at including license information in the "blurb" box of the frontmatter:
CC-BY 3.0 Unported: https://github.com/dwsideriusNIST/article_templates/blob/license_macros/templates/CC-BY.pdf
CC-BY 4.0 International: https://github.com/dwsideriusNIST/article_templates/blob/license_macros/templates/CC-BY-4INT.pdf
Text used by NIST for the governmental "non-license license" copyright disclaimer:
https://github.com/dwsideriusNIST/article_templates/blob/license_macros/templates/govt.pdf
As far as I can tell, NIH does not require its staff to include any sort of disclaimer statement or denial of copyright explicitly in the paper. Does anyone have any insight on NIH's requirements?
from article_templates.
Also, more generic US Govt disclaimer that is inspired by the Open Government Data initiative: https://github.com/dwsideriusNIST/article_templates/blob/license_macros/templates/govt-PD.pdf
What do you all think of the placement? There is some whitespacing issue, but longer author lists and abstracts would solve that particular issue here.
OR... should the license text be in the document footer or in a section near the end of the paper? I'm open to ideas
from article_templates.
These look right. There's a whitespace issue, but in MOST cases, the whitespace issue wouldn't pop up. Maybe file it as a potential issue so we remember it's there if it's not totally obvious how to make room for it if the abstract WASN'T very long.
OR... should the license text be in the document footer or in a section near the end of the paper? I'm open to ideas
I think this looks good.
from article_templates.
After doing some additional trials, I think the whitespace issue is going to be a problem in more cases than we would hope. E.g., https://github.com/dmzuckerman/Sampling-Uncertainty/blob/license_macro/main.pdf, page 1. I added the US Govt open-data-initiative style disclaimer, but I think the aesthetic appearance would be really terrible if whitespace were added to allow the entire disclaimer in the 'blurb' area.
Another option is to put the license information in a separate section toward the end of the paper: https://github.com/dwsideriusNIST/article_templates/blob/license_macros/templates/govt-PD.pdf, page 7. Please ignore the dithered CC0 badge; I need to convert the SVG graphic into something LaTeX friendly.
from article_templates.
Leaving it on the front is useful. Some options are narrowing the right hand panel, narrowing the margins between the right and left hand panel, and moving the right hand panel (with github repository/license information) up the page.
from article_templates.
Here is a second attempt at adjusting the "blurb" location: https://github.com/dmzuckerman/Sampling-Uncertainty/blob/license_macro/main.pdf
I need to test the class file with a few other papers to see if the positioning is consistent.
from article_templates.
I had to work on the vertical alignment a bit more and have zeroed in on a compromise.
See, for example:
https://github.com/dmzuckerman/Sampling-Uncertainty/blob/license_macro/main.pdf
https://github.com/dwsideriusNIST/TransportCheckList/blob/license_macro/TransportChecklist.pdf
https://github.com/dwsideriusNIST/gmx_tutorials_livecoms/blob/license_macro/gmx_tutorials.pdf
The blurb+license+date block in the left column is (more or less) centered vertically relative to the box containing the title+author info+abstract+metadata.
How is this as a compromise alignment? It's not greatly different from the previous alignment (which was closer to the abstract position).
from article_templates.
I think that looks great. @davidlmobley, @dmzuckerman, any thoughts?
from article_templates.
Also, we want to make sure that the license text appears in human readable form in the .tex itself, since that can be copied - it might be enough to haver what appears in the pdf. or maybe there's some extra suggested verbiage that can be included in comments in the repository.
from article_templates.
I think they look very good, but I see two different govt ones in the three listed by @dwsideriusNIST. Either is ok with me but I wasn't sure which was proposed.
from article_templates.
Also, we want to make sure that the license text appears in human readable form in the .tex itself, since that can be copied - it might be enough to haver what appears in the pdf. or maybe there's some extra suggested verbiage that can be included in comments in the repository.
So, you're in favor of both a macro that autofills most of the licenses and then also including the raw license description somewhere in the tex? I'm not sure what the point of the macro is in that case.
from article_templates.
I think they look very good, but I see two different govt ones in the three listed by @dwsideriusNIST. Either is ok with me but I wasn't sure which was proposed.
There are some inconsistencies between agencies/departments, so I've put some different govt licenses together as examples. Documentation will have guidance on how to use the "stock" text versus a custom license for non-conforming agencies (e.g., mine).
from article_templates.
That makes sense. Thanks for sweating the details.
from article_templates.
I'm not sure what the point of the macro is in that case.
If the FULL text that should be included is in the PDF. then that's all that needs to be in the .tex file. Which it probably is. I was just trying to make the point that the .tex file needs to be copyrighted, too.
from article_templates.
The full text used for the pdf will not really be needed for the tex
file as well.. The license header for code is more appropriate for a source file.
Also the alignment looks great.
from article_templates.
OK, let me make sure I'm understanding this correctly. @mrshirts is proposing:
-
The PDF needs to have a license statement. No arguments from me on this point.
The approach I've taken thus far is: the current macro creates this automatically in the PDF via: selection from a list of "stock" licenses for which the license statement is actually part of the livecoms.cls file, and a "custom" option that allows the user to provide their own TeX code to handle some other situation. -
The inclusion of a license statement in the TeX source file also. I take it that you mean something along the lines of:
This work is licensed under a Creative Commons Attribution 4.0 International License.
needs to be in the TeX file, probably in a comment in the preamble.
Some problems I see with this approach:
- I would not include the "stock" license texts in the class file if the authors have to enter the same raw text elsewhere in the source file. It creates a new point of failure that editors have to police: the raw text must match the macro text precisely. We can still provide examples, if that is the ultimate decision.
- What about manuscripts that use multiple TeX files (via \input commands) - does the license in the "main" file infect the files it depends on? Or does the license statement need to be in each dependency?
- I'm more familiar with situations where the entire project is covered by a license statement that is not in a source code file, but in some other file in the repo; like a LICENSE.md file or similar. (I think this is what @HaoZeke is suggesting - please clarify!)
If the decision is to have the license text in the main (or all) TeX files, then I would prefer to write the macro in a way that it only formats TeX code provided by the authors. Please advise.
from article_templates.
In general, a license is mentioned by it's header which may point to a full text version, which is not typically part of the source code at all. For example, given the following project layout:
.
├── input
│ ├── partOne.tex
│ └── partTwo.tex
├── LICENSE.md
└── main.tex
1 directory, 4 files
It is imperative, that the full text of the chosen license is in LICENSE.md
, however, (assuming the Apache v2 license) each tex
file would have the following:
% Copyright [yyyy] [name of copyright owner]
%
% Licensed under the Apache License, Version 2.0 (the "License");
% you may not use this file except in compliance with the License.
% You may obtain a copy of the License at
%
% http://www.apache.org/licenses/LICENSE-2.0
%
% Unless required by applicable law or agreed to in writing, software
% distributed under the License is distributed on an "AS IS" BASIS,
% WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
% See the License for the specific language governing permissions and
% limitations under the License.
%
At this point it needs to be clarified, that technically the CC licenses are for content and not code, therefore they do not have any official code-header style inclusion line which is problematic. This however is not really an issue for the journal, since my own understanding is that the content may be CC licensed, while the template code may be MIT licensed.
In effect, the code license pertains to the layout of the journal (and therefore only the tex
structure) and the content license details the usage rights for the content (including equations and other). I believe a dual license line might be most appropriate:
.
├── contentLicense.md
├── input
│ ├── partOne.tex
│ └── partTwo.tex
├── LICENSE.md
└── main.tex
1 directory, 5 files
Each file can now contain something along the following:
% The contents of this file are dual-licensed under the terms and conditions mentioned in contentLicense.md and LICENSE.md in the project root
The issue with this is that it is not descriptive enough to prevent (possible) abuse.
% The contents are public domain by CC-BY-NA
% CC-BY-NA (C) Authors
% The layout is public domain as per the terms of the GNU GPL v3
% -- code header for layout --
This is very verbose though not really very different from the headers from existing journals. The main take-away here is that the authors will probably never modify the tex
code license, just the content license. In that case:
% -- code header for layout --
% Content (C) Authors
Then the rest of the licensing details can be offloaded to the pdf
. Again, there is a distinction between CC licenses for the pdf
s and the source.. Even if the authors retain the full copyright to the source material, they may still distribute the compiled pdf
under CC terms.
from article_templates.
Just to chime in, I think the full text of the license does not need to be in the TeX nor in the PDF, though an identification of which license is applied would be good to have in both places. Additionally, the full text of the license SHOULD be in the repo as was pointed out in a comment.
from article_templates.
an identification of which license is applied would be good to have in both places. Additionally, the full text of the license SHOULD be in the repo as was pointed out in a comment.
I'm OK with this; that seems to be a good way to do this. Which means that we should stick a license in the template repo. There would need to be instructions to REMOVE it if it was not applicable (for example, if government).
from article_templates.
It seems that we're settling on a combined approach:
- Typeset the license "blurb" in the PDF, similar to my examples
- Put the full license text in the repo (the license.md file?)
- Put the license "blurb" in the TeX header (of all files), similar to @HaoZeke
If this is accurate, then I can put together some examples. Author instructions will have to be pretty explicit in stating that the authors are responsible for ensuring consistency among the different instances.
from article_templates.
Sounds great!
from article_templates.
from article_templates.
Here are two trial runs:
https://github.com/dmzuckerman/Sampling-Uncertainty/tree/license_macro
https://github.com/dwsideriusNIST/gmx_tutorials_livecoms/tree/license_macro
To see the net effects:
- The PDF is formatted as in my previous examples
- A header in the top of each TeX file includes a blurb about the license.
- The full license is in another file, like LICENSE or LICENSE.txt in the repo [QUESTION: Is it satisfactory to just include the full license file, or should it be pointed to in either the TeX headers or README.md?]
I plan to remove code from the class file that automatically generates text for certain license, and just make the formatting macro generic. Since authors have to include the license blurb in the TeX header, this will help prevent inconsistencies between the TeX header blurbs and the formatted PDF; not a guarantee, but a help. We will need to create examples, definitely in the author guide but perhaps also in the article template repo itself.
@HaoZeke, I would greatly appreciate your opinion on this approach. I think we're getting close to a final form.
from article_templates.
@dwsideriusNIST thanks for asking, sorry for the delay..
Sampling uncertainty does not show the pdf
badge though the tex
file is correct.
- The
.pdf
looks great - The header is also correct
- This actually depends on the license. For the use cases here it is more than sufficient, however for certain licenses, or content where multiple license texts are present, instead of linking to the license website, it would be expedient to link to the
readme
in the repository.
It would be a good idea to make things more generic (in terms of the .cls
file), I believe whatever difficulty the authors have can be handled during the review process. It looks great and seems compliant too!
from article_templates.
The full license is in another file, like LICENSE or LICENSE.txt in the repo [QUESTION: Is it satisfactory to just include the full license file, or should it be pointed to in either the TeX headers or README.md?]
Just to complicate things a bit: in the case of the CC licenses (other than most source code licenses) including a copy of the license text is actually not the recommended way of applying the license, see https://creativecommons.org/faq/#how-do-i-apply-a-creative-commons-license-to-my-material
The recommended way is to include their HTML snippet (which works in Markdown on GitHub) ore a simple sentence saying
This work is licensed under the Creative Commons [insert description] License. To view a copy of the license, visit [insert url]
The plaintext versions of the license are provided mainly for software projects that are used to the practice of including copies of the license with their project:
For most works, plaintext legalcode doesn’t matter as linking directly to the deeds (say with the copy-paste output you get with the license chooser) is good enough, even ideal. And it’s important to note that the XHTML licenses are still the canonical versions. But for some projects plaintext legalcode may be a very good thing. For example, it is traditional practice in free and open source software projects to bundle your licenses along with your project. More and more FOSS projects are using Creative Commons licenses or CC0 for their non-software content, so having plaintext legalcode will probably be very useful in these instances.
from article_templates.
Hi, all - resurrecting this. This has come up again for applying for various journal databases, so I think we do want to move forward on this (which we never did!) But better late than never.
- It seems like for CC, then we should link to the web page, not the license.
- Seems like putting it in the right-hand column on the first page is a good place to put it?
- @dwsideriusNIST what else would need to be done for this?
from article_templates.
Related Issues (20)
- Section / subsection titles intruding into gutter and margins HOT 9
- Number references by order of appearance HOT 4
- Reference standards for bibliography. HOT 26
- Formatting at time of publication (DOI, volume, etc.)? HOT 14
- Templates producing weird 'fi' characters? HOT 6
- How to include version number in the title of articles HOT 14
- Reference formatting: should pMID's be in the references? HOT 5
- Bolding of Editor names, no author names HOT 2
- Posting DOI's properly in articles and on website HOT 10
- Can we figure out how to make white-spacing easier? HOT 1
- List of things to fix/adjust before issue 1 published (we will ask for people to redo the templates then). HOT 23
- Issue number HOT 9
- Create a way to add translators to the article? HOT 3
- Template had old name for software analyses section HOT 1
- Switch from `natbib` to `biblatex` in `livecoms` document class HOT 12
- Consider using Github's "template repository" mechanism
- Bibliography Modernization HOT 4
- Fix display long URLs in GitHub link HOT 1
- Consider adding line numbers to review versions?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from article_templates.