Several files per license

[grv87]

Please consider that some licenses have several files.
For example, for LGPL 3.0 there are two files: COPYING and COPYING.LESSER. Both files form the whole license and should be distributed together. See e.g. http://git.savannah.gnu.org/cgit/guile.git/tree/ which even has third LICENSE file referring to those two.

Currently this ABOUT file:

about_resource: two_license_files.ABOUT
name: two_license_files
licenses:
  - key: LGPL-3.0-or-later
    file:
      - COPYING
      - COPYING.LESSER

doesn't pass check:

CRITICAL: about/two_license_files.ABOUT: Cannot load invalid ABOUT file: '\?\R:\!spikes\about\two_license_files.ABOUT': AttributeError("'list' object has no attribute 'strip'",)

List of files works with syntax from specification (license_file). But if there are several licenses then there is no correspondence between license_key and license_file items. So I would like to avoid that.

[chinyeungli]

Thanks for the report. I will look into this.

[mjherzog]

Another example would be Google/Go code where the BSD and Patent notices are typically separate.

[grv87]

@mjherzog, there is separate notice_file. I think it covers these cases. And it accepts several files (even though it is not mentioned in specification)

UPDATE: looking in PATENTS file I think you are right. This is part of the license, not some additional copyright notices

[chinyeungli]

@grv87 I am looking into this.
The current json output from inventory (with my fix) is

[
  {
    "about_file_path": "/two_lic_files.ABOUT", 
    "about_resource": "two_lic_files.ABOUT", 
    "name": "two_license_files", 
    "licenses": [
      {
        "key": "LGPL-3.0-or-later", 
        "file": "COPYING"
      }, 
      {
        "file": "COPYING.LESSER"
      }
    ]
  }
]

which is not very nice.
Perhaps the ideal output should look like:

[
  {
    "about_file_path": "/two_lic_files.ABOUT", 
    "about_resource": "two_lic_files.ABOUT", 
    "name": "two_license_files", 
    "licenses": [
      {
        "key": "LGPL-3.0-or-later", 
        "file": "COPYING"
      }, 
      {
        "key": "LGPL-3.0-or-later", 
        "file": "COPYING.LESSER"
      }
    ]
  }
]

although we have two duplicated "key"

Note that the CSV output from inventory looks good.

[grv87]

@chinyeungli, what about reading YAML? Will format be the same, i.e. several items with repeating key?

I've looked into sources, and I'm not sure all this will work correctly until you have separate License class.

[chinyeungli]

There are actually more things to consider.
For instance, should we consider the following correct?

about_resource: two_lic_files.ABOUT
name: two_license_files
licenses:
 - key: lgpl-3.0-or-later
    file:
     - COPYING
     - COPYING.LESSER
 - key: mit
   file: MIT
notice_file: NOTICE

i.e. for the license file field, should we accept both list and string type?
In addition, should all the FileTextField() support multiple files such as notice_file, author_file etc...

[pombredanne]

@chinyeungli whatever the solution you pick in the end, I would like to make sure this is aligned with the data structures used in ScanCode. Having several license texts for a single license is a possible issue.

I can think of a few alternative ways beside using a list of text files:

1. do nothing and keep a single license text. In this case the text used for the LGPL 3 should combine the text of the GPL and the text of the LGPL

2. treat lgpl-3.0 really as an exception and always use gpl-3.0 with lgpl-3.0

Other related cases may exist: any "exception" would typically only make sense if the main license is also there.

The -plus, or later variants of the FSF licenses have a text that is often more notice-like and they require the full text to be produced too in addition to this notice. If we have an lgpl-3.0-plus should we then consider always the lgpl-3.0-plus "text" whatever that is, then the lgpl-3.0 and the gpl-3.0 ? Should we also add an gpl-3.0-plus text too in this case?

We would also need to consider the impact on clarity: if there are a GPL and LGPL full text (an no ABOUT file) we are creating some ambiguities by adding the GPL text.

[chinyeungli]

@pombredanne

If we have an lgpl-3.0-plus should we then consider always the lgpl-3.0-plus "text" whatever that is,

Agree

Your suggested alternative ways are one of a solutions, but I don't think it makes much sense.
For instance, a user is using an external lgpl-3.0-or-later library, the user will just want to create an ABOUT file to reference the component instead of creating another license file or combine the COPYING and COPYING.LESSER into one.

We would also need to consider the impact on clarity: if there are a GPL and LGPL full text (an no ABOUT file) we are creating some ambiguities by adding the GPL text.

I am not sure what do you mean here. Can you elaborate a little bit :)

[pombredanne]

@chinyeungli about clarity:

My (weak) point here was that if we encourage having always two files we may not promote clarity about which one applies... but on the other hand the whole point of the ABOUT file is to bring clarity ... so this is a moot point I made.

[chinyeungli]

right.. that's the reason we need ABOUT files in every project :D

[grv87]

for the license file field, should we accept both list and string type?

Why not, for compatibility with existing ABOUT files?

@chinyeungli, I actually like your approach with dumb repetition:

      {
        "key": "LGPL-3.0-or-later", 
        "file": "COPYING"
      }, 
      {
        "key": "LGPL-3.0-or-later", 
        "file": "COPYING.LESSER"
      }

But right now it gives warning:

WARNING: gradle-about-plugin/gradle-about-plugin.ABOUT: Field license_key: ignored duplicated list value

treat lgpl-3.0 really as an exception and always use gpl-3.0 with lgpl-3.0

SPDX considers LGPL as separate license, not exception. gpl-3.0 with lgpl-3.0 is not valid SPDX license expression.

We would also need to consider the impact on clarity: if there are a GPL and LGPL full text (an no ABOUT file) we are creating some ambiguities by adding the GPL text

if we encourage having always two files we may not promote clarity about which one applies

I don't see the problem. Having two files for LGPL is GNU standard. It was never an issue. ABOUT file just describes things as they are, not promotes anything.

[mjherzog]

The license text files are in support of the license expression in the ABOUT file not to replace it. We should avoid adding a step to edit the license text files if possible. We will need to use license expression to determine how to display the multiple license text files in Attribution which may be "interesting" - e.g. the exception is usually more interesting, but second in the expression. Regarding SPDX, I cannot recall the latest on this discussion but I trust that they will eventually catch up and deal with this as we do.