Reworked / Created Copyright Documentation

[PhoneDroid]

Changes

Overview

• Created documentation relating to SPDX License Identifiers
• Rewrote documentation relating to copyright headers

Details

• Moved related documentation into their own files.
• Created one file for explaining the topics.
• Created another for easy to copy paste snippets.
• Documentation is on purpose written to mostly only address internal copyright application.
• Documentation is on purpose using preferred license identifiers in examples ( LGPL-2.1-or-later )

Copyright

For a while now I've made the effort of adding SPDX License Identifiers to more and more files
in FreeCAD.

While going through thousands of files I've noticed the inconsistencies of the INTERNAL copyright headers.

While I want to update most / all of them at some point, I wouldn't wanna waste my time doing so if I don't have the best headers ready ( snippets ) when doing so.

To this end I've made a couple of changes to the headers.

Changes

• ( Not a change ) I've documented the use of SPDX License Identifiers

• I've added the use of SPDX-FileNotice to replace the custom
  line in the copyright header with a standardized annotation.

  Before This file is part of FreeCAD. ( In copyright header )

  After

  # SPDX-FileNotice: Part of the FreeCAD project.
  

• I've removed the previously mentioned
  custom line from the copyright header

• I've standardized the width of the copyright header from
  somewhere between 77-78 to a set 80 which is the
  smallest size people usually go by with code formatting.

• I've made the Python header into a proper thing, not just the C++ header pasted in with # appended in front of it.

• I've typeset the text - NOT CHANGED IT'S CONTENT

• I've used the copyright symbol instead of the double Copyright (c)
  which is documented by SPDX as being ENTIRELY equivalent and anyone expected to understand copyright headers will know it's meaning.

  While working through the thousands of files in FreeCAD I noticed that some notices had broken declarations due to excessively long name / org / email combinations.

  This will give them a bit more space.

  To repeat they are equivalent, universal and anyone expected to understand a copyright header is expected to know that symbol.

---

Reminder, this documentation MOSTLY aims to inform contributors
about how to handle NEW CODE they write FOR FREECAD and NOT
how to UPDATE EXISTING CODE.

[PhoneDroid]

~~I've added an agenda point for
this weeks Developer Meeting.~~

• Meeting
• Agenda
  

Agenda point was not merged.

---

Discussed in developer meeting anyways.

Outcome: Don't go with the organizational copyright declaration, rest was fine.

[chennes]

Thanks for the update. A few comments:

1. The manual line-wrapping should be eliminated from the prose portions of this PR. The Developer's Handbook doesn't use manual line-wrapping. Obviously it's appropriate for the source code portions.
2. "FreeCAD" is not a legal entity, and can't hold the copyright to anything. The Software Freedom Law Center suggests "Copyright 2012 The Foo Project Developers."
3. The comment suggesting conversation be held elsewhere is inappropriate. CONTRIBUTING.md Process pt. 9 specifically and intentionally requests that discussion be held on GitHub.

[chennes]

I am still of the opinion that we should never do any manual line-wrapping. I'll leave it for others to weigh in. @obelisk79 is probably the most relevant ping.

[PhoneDroid]

How it looks with / without formatting.

[sliptonic]

I am still of the opinion that we should never do any manual line-wrapping. I'll leave it for others to weigh in. @obelisk79 is probably the most relevant ping.

I agree. Manual line-wrapping actually reduces downstream use. Let whatever is showing the markdown (browser, obsidian, something else) worry about wrapping it.

[hyarion]

I do agree that it looks better in your specific case, but we can't assume it will look the same for everyone.

For example, here is how it looks for me:

In general I think it is best to avoid it when possible and let the renderer take care of the formatting.

[PhoneDroid]

Removed the manual line breaks and added native text wrapping with line length limited to the ideal ( 66ch )

https://en.wikipedia.org/wiki/Line_length https://www.uxpin.com/studio/blog/optimal-line-length-for-readability/

[PhoneDroid]

Bump

[PhoneDroid]

I removed the manual line break that affect the rendering, which is fine as it can be achieved via native CSS wrapping.

However I was also told to remove line breaks from the markdown source code, I don't see how this is in any way good practice.

As this PR doesn't seem like it's gonna be merged otherwise and I'm already demotivated enough, I will comply even if I disagree.