Add licenses

[Paebbels]

This adds the Apache License, 2.0 headers and license texts.

Fixes #9.

[Paebbels]

@umarcor what copyright to use?

[umarcor]

While I agree with adding a license to all the sources, and it being Apache 2.0, I am unsure about:

• Copyright 2020-2021 pyTooling. I would use The pyTooling contributors, or The pyTooling authors, as done in SymbiFlow (e.g. https://github.com/SymbiFlow/fpga-interchange-tests/blob/master/utils/quiet_cmd.sh#L2). In Licensing (GHDL, libghdl, libghw, GRT, pyGHDL, etc.) ghdl/ghdl#1812 concerns were raised about the legal validity of such wording. IANAL, but the risk is acceptable to me, since this is mostly a utility repo.

• I don't like fixed width symbol rows. I don't find them particularly helpful and it is annoying to me that the width is not adjusted to the user's preference. I believe that the first 5 columns are the most relevant while quickly scrolling through a document. For this same reason, I prefer if author names are the first word found in their respective rows.
  Hence, I would propose the format used in hdl/containers (see https://github.com/hdl/containers/blob/main/debian-bullseye/boolector.dockerfile).

• I would not add doc/Doc-License.rst yet, because we don't have proper documentation, just a couple of markdown files. I would delay it until we add an Sphinx site (which we will need soon).

• I wanted to wait until adding "tip" (add Action 'releaser' #10) in order to add license headers to all the sources at once.

[Paebbels]

For: Copyright [...]

• Copyright 2020-2021 pyTooling vs.
• The pyTooling contributors vs.
• The pyTooling authors

The beauty of Apache License is, it brings all contributions under the copyright of the copyright owner. So if copyright is owned by XXX, any contribution from users A, B, C becomes copyrighted by XXX. By defining XXX as a very wide audience, all members of XXX must be ask in case the project / license needs a transformation, correction etc.

No saying I want to move away from Apache License, but imaging there could be Apache License, 3.0 somewhen or a better or wider accepted license. Another use case might be if we later somewhen found a society (according to dict.cc - ES: asociación) for e.g. pyTooling and/or EDA², we might want to transition such rights to a legal body. I don't want to ask potentially dozens or hundreds of people for permission. That's why I would like to keep the range small.

So with using authors I would feel better then with contributors.

---

For: I don't like fixed width symbol rows. [...]

I agree on reformatting the header section around Authors to:

# Authors:
#   Patrick Lehmann
#   Unai Martinez-Corral

I check different variant without horizontal lines, but I think it's not as readable as with some section lines.
We could use a more light-weight style based on ---- instead of ====.

Reasons why:

• separation between authors and license text

  # Authors:
  #   Patrick Lehmann
  #   Unai Martinez-Corral
  #
  # ------------------------------------------------------------------------------
  # Copyright 2020-2021 pyTooling

• separation between header comment and e.g. module doc-string

  # SPDX-License-Identifier: Apache-2.0
  # ------------------------------------------------------------------------------
  #
  """
  This is my fancy module
  """
  from pathlib import Path

  

---

For: documentation license

I consider the README as a major part of the documentation. There for I would like to have this covered from beginning under CC-BY 4.0. I just added the license file at the usual place and linked it in the README.

---

For: waiting on #10.

Yes, we can merge #10 first.

[umarcor]

The beauty of Apache License is, it brings all contributions under the copyright of the copyright owner. So if copyright is owned by XXX, any contribution from users A, B, C becomes copyrighted by XXX. By defining XXX as a very wide audience, all members of XXX must be ask in case the project / license needs a transformation, correction etc.

My point is that the beauty of such feature is arguable.
Bringing all the contributions into a single person is desirable in case all contributors agree with the copyright holder potentially changing the license in the future. They are not only providing the contributions under the terms of the currrent license, but also granting permissions to change it to an incompatible license.
Conversely, using a collective as the copyright holder makes the granting reciprocal. The contributor provides the code under the terms of the current license, and at the same time it is given the opportunity to oppose to license changes in the future (i.e. it is made a protector of the openness of the project).
There are recent examples of the risks of open source projects being taken over. See e.g. Freenode or Audacity.

Another use case might be if we later somewhen found a society (according to dict.cc - ES: asociación) for e.g. pyTooling and/or EDA², we might want to transition such rights to a legal body. I don't want to ask potentially dozens or hundreds of people for permission. That's why I would like to keep the range small.

While I understand that case, an hypothetical organisation/company/entity can always take this repo, preserve the license and specify the new content with a different copyright. As long as whatever is added is compatible from a license point of view. We might even use this in a closed source project, without publishing the enhancements. Those are not problematic. The problem is if whoever wants to change the license itself, not the holder.

If Apache 3.0 was released, and it was compatible with Apache 2.0 (not more less restrictive), I believe updating it would not need permission from inactive authors.

Overall, I don't feel I/we need to keep tight control on the licensing of this repo. This (pyTooling/Actions) is not something we want to put lots of effort on, but a utility we need for doing the actual interesting work. That is different in other repos of this org, in EDAA or HDL. In those cases, there is a very strong commitment from some developers, which I understand deserves the right to "freely" handle the project as a whole.

So with using authors I would feel better then with contributors.

I agree. In practical terms, I'd say "the author list retrieved through git".

---

I check different variant without horizontal lines, but I think it's not as readable as with some section lines.
We could use a more light-weight style based on ---- instead of ====.

I think the main point is that you expect all the header blocks to have continuous comment symbols. That is, a single header block. That's why additional separators are required. Conversely, I expect each header to be different, if they contain different data (shebang, authors, license, etc.). To me, the first line of code is the first non-empty line not starting with a comment symbol, not just the first non-empty line (which is a separator, per se).

In the example below, I really don't find the one on the right more readable. In fact, I would use single empty rows, instead of double; however, I'm good with using two, as required above Python functions/classes. The fact that white space has meaning is in the DNA of Python.

---

I consider the README as a major part of the documentation. There for I would like to have this covered from beginning under CC-BY 4.0. I just added the license file at the usual place and linked it in the README.

Since CC does not require the license body to be provided (it can be just linked), what about adding a paragraph at the end of the README and adding the rst source when we add the Sphinx site?
Otherwise, let's keep it.

[umarcor]

In a video meeting, we decided to use 120 chars wide headers with separators, in order to keep the whole header in a single block (for consistency regardless of the language).