Godot: Add copyright and license info as a script resource properties in Visual Script
Godot version:
New feature request (as of 3.1-stable)
Issue description:
Its normal to add copyright header information to GDScript files, such as:
Copyright (C) You're Perfect Studio, All Rights Reserved.
Licensed under the MIT license, see LICENSE.txt in the project root folder for more information
But there is no (AFAIK) proper way to do this in Visual Script (other than adding comment nodes) My preference would be in the scripts properties here (under Name in the scripts resource info in inspector):
and there to be two string properties: Copyright and License
Bonus Points (I can dream right?):
- Implement this generally to cover scene files, and other resorce file types
Have an option in Project Settings for (autopopulate) defaults for these fields when creating new files, to save lots of work
Have a (default-to-on) editor option to show the copyright string when viewing Visual Script files - this would be in a very non-obtrusive position and color (like slightly off from the background color, or semi transparent gray in the lower right corner - like here but not bright red and not this big... something subtle).
By default it would only show the Copyright string but if you click it, it will show you the Copyright and License info. If Licesne is set but not Copyright is, it would show the license info instead. It should elide long text. Subtle and non-obtrusive are important here I think.
Random info:
I once filed this same bug for UE4 Blueprints also, :-)
TheRealCatherine
All 13 comments
Would all resources have a copyright and license info? Would that make sense?
fire
on 16 Apr 2019
Well I put that in "Bonus Points" because I mostly care about Visual Scripting for this bug report - but if its something that can be implemented generally I think that is probably even better.
TheRealCatherine
on 16 Apr 2019
fire
on 16 Apr 2019
My idea would be some sort of key in each resource to a dictionary of entities. These entities are specified in xmp or dublin core, pick a standard where the naming of things has already been defined and agreed on.
fire
on 16 Apr 2019
https://omeka.org/classic/docs/Content/Working_with_Dublin_Core/ mentioned some interpretation and http://www.dublincore.org/specifications/dublin-core/usageguide/elements/
fire
on 16 Apr 2019
If its going to support all the Dublin Core fields instead of just the two I originally mentioned then here are my comments from Discord while thinking through this:
IMHO putting the data right into the resource is preferable - but only if that data is less than 3ish variables (which is why I originally proposed only 2 fields.) I don't think we want to add 20 usually empty String fields to every resource. But having an Array of metadata thats been actually added to the resource is just one often empty Array per resource, not too bad.
Having an array of key/value String pairs for the metadata also opens the door for a user-defined metadata keys. It also allows for listing multiple Contributors, Copyright holders, etc. (so it can't be a unique-key-only Dictionary)
So really something designed exactly the autoload scripts dialog , with the selection boxes at the top and an add button, and then little icons to edit/remove/etc the entries. Except the first field is a dropdown of the common metadata fields like copyright, contributor, etc from the Dublin Core page and the second field could just be a text input. Ideally the last item in the metadata dropdown would be "Custom" and this would add another input box to specify the key name. I don't think we should enforce "suggested format" for dates, ISBN, language, etc. Just let the user input whatever.
I'll mention too - I don't think the metadata should included in Exported applications and it should not be quarriable through GD Script (at least by default I guess there could be an off-by-default option). To me its an important point that this is for source documentation purposes and not runtime purposes.
Oh also about where to store the array of string pairs of metadata - definitely I think in the resource because, say, I make a copy of a GD Quest resource off of github, if the metadata isn't included in that file then it defeats a major reason to have it.
One might be tempted to look at the dublin core list and think "oh I'll make the keys enums that correspond with the fields to save some bytes" - but that would make custom metadata fields more difficult. If we strip metadata from Exported builds by default then I think a string/string pair for the fieldname/value is best. Especially since most applications wont use more than one or two metadata fields on their files anwyay. (and probably 80% wont ever set metadata fields IMHO, mostly just companies or larger open source projects.
Additionally, this info is just used in the editor and does not require quick lookup, so iterating over an array of string pairs (versus like a hash table or something) should be totally fine. so for me, an array of string/string seems to be the best.
TheRealCatherine
on 17 Apr 2019
If it helps, there's some work for an encoding of Dublin Core [to rdf] to Json-LD.
https://gist.github.com/edsu/9005070
So we can attach one dictionary and call it metadata and store our elements in it.
Edited: https://www.w3.org/2008/WebVideo/Annotations/drafts/API10/JSON/normative_json_ma_dc.json
fire
on 17 Apr 2019
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc= "http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://www.w3schools.com">
<dc:title>D-Lib Program</dc:title>
<dc:description>W3Schools - Free tutorials</dc:description>
<dc:publisher>Refsnes Data as</dc:publisher>
<dc:date>1999-09-01</dc:date>
<dc:type>Web Development</dc:type>
<dc:format>text/html</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
</rdf:RDF>
Becomes through https://rdf-translator.appspot.com/ to:
{
"@context": {
"dc": "http://purl.org/dc/elements/1.1/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@id": "http://www.w3schools.com",
"dc:date": "1999-09-01",
"dc:description": "W3Schools - Free tutorials",
"dc:format": "text/html",
"dc:language": "en",
"dc:publisher": "Refsnes Data as",
"dc:title": "D-Lib Program",
"dc:type": "Web Development"
}
Its normal to add copyright header information to GDScript files
Are you sure about that? Normally I see copyright information stored in a LICENSE.md file, which can either be located in the project root, or in a subfolder if that folder's contents have copyrighted material. Why do you need copyright information stored within the script file?
If this is added, it would make sense to have it just be a generic "Notes" text area, which can contain anything, including a license/copyright or a description of the file.
aaronfranke
on 22 Jun 2019
@aaronfranke even the Godot project itself has what I'm pasting below at this top of its own individual source files. This is a feature request to add a way to have an equivalent in Visual Script.
/*************************************************************************/
/* array.cpp */
/*************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/*************************************************************************/
/* Copyright (c) 2007-2019 Juan Linietsky, Ariel Manzur. */
/* Copyright (c) 2014-2019 Godot Engine contributors (cf. AUTHORS.md) */
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.*/
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/*************************************************************************/
youreperfect
on 22 Jun 2019
Why adding a comment node isn't enough? There is also the possibility of adding the LICENSE file, which, afak, is legally enough to """copyright""" the whole project and all its files. You can also add an addon to your project that will always show a label in this area you've pointed whenever a VisualScript is open. Really there are so many ways to achieve that.
The ability to add copyright notice on text files in general is just because they allow you to add any text. But like, imagine adding copyright notices to each individual resource, and having the inspector polluted by a field with a giant copyright notice...
Not to mention that it would be very unlike to happen, or to be noticed that this happened, like why would someone take the effort to:
- Ignore the LICENSE file
- Copy/rip your project
- Open it in Godot
- Open the VisualScript
- Ignore the Comment node with the copyright notice
- Rip the VisualScript anyway
- Use it in another game
- Contest your lawsuit (if you want to take the effort and resources to do so)
- Hire a lawyer to defend them
- Just to say "Ohh there was no copyright notice on the screen in these specific methods during my ripoff you know, the other 2 notices weren't enough, not even the one that includes the whole project nor the one in the Comment node ¯_(ツ)_/¯"
henriiquecampos
on 9 Jul 2019
The proper place to put a copyright text field is on the resource class.
However, as @henriiquecampos mentioned, it's not really feasible to do so for EVERY SINGLE RESOURCE.
fire
on 30 Sep 2019
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
mhilbrunner
on 28 May 2020
Related issues
mefihl
·
3Comments
blurymind
·
3Comments
ndee85
·
3Comments
testman42
·
3Comments
gonzo191
·
3Comments
Most helpful comment
Are you sure about that? Normally I see copyright information stored in a LICENSE.md file, which can either be located in the project root, or in a subfolder if that folder's contents have copyrighted material. Why do you need copyright information stored within the script file?
If this is added, it would make sense to have it just be a generic "Notes" text area, which can contain anything, including a license/copyright or a description of the file.