Haikuports: Recipes should be allowed to install exact copies of the licenses their project uses.

[fbrosson]

They way we handle the licenses in our packages is not correct in many cases because our packages do not include the exact copies of the licenses.
And in some cases, e.g. BSD (3-clause), the license files we have in /boot/system/data/licenses/ contain placeholders:

grep -in holder /system/data/licenses/BSD\ \(3-clause\) 
1:Copyright (c) <year>, <copyright holder>
15:THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
18:DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY

So having just LICENSE="BSD (3-clause)" in the recipe is not definitely wrong, unless we decide to grant ourselves the right to ignore the terms of the licenses.

Hence this proposal:

Define myLicensesDir=$dataDir/licenses/packages/x/xyz where xyz is the basename of the recipe.
Then create that directory and copy every license file used by the project, with their original names, in that directory.
In some cases, e.g. with the Apache v2 license, which contains no placeholders, using a symlink is, imho, a nice alternative to copying the license.

/boot/system/data/packages/ would have at most 26 subdirectories (one for each letter of the alphabet), and this would allow distribute every myLicensesDir in one of these 26 subdirectories, instead of having them all in a single directory.

Examples of recent commits which have anticipated this debate:

• a7ce9805ffbb4372483b83379f3770d41d49e276 pytz: define myLicensesDir.
• 9c48b0bebae2418ca6a47ca4b548d7fd07f97c67 dev-python/cryptography: simplify COPYRIGHT, define myLicensesDir.
• 8be81aaf0d43776eb48b7c9612aadf1f6400c5b3 dev-python/cryptography-vectors: define myLicensesDir.
• 38aa385d8efd3b5836e223ff8361e8323008828f pyOpenSSL: new recipe.

The way we are handling special cases by renaming a custom license and putting it in our repo is not optimal because:

• we will have a growing number of files in /boot/system/data/licenses/, with names that provide no information on what the license is.
• we add noise to our repo instead of using the files that are in the tarballs.
• when the license changes we need to update our repo.

Important:

I've created this issue in order to discuss this topic. I don't plan to update every recipe. This can be used for new recipes or for recipes which have licenses which have placeholders in the copies provided by Haiku. Such a "migration" can be done progressively, when the recipes have version bumps.

[scottmc]

I thought that if we find the license isn't already in our repo that we just put it into a subdir of the recipe called "license" and then it just gets picked up from there instead. No need to create all the myLicenseDir nonsense. Your commit said that you simplified the license. What's simpler than a single line of code to point to the license? your method added several lines and more clutter.

[fbrosson]

I thought that if we find the license isn't already in our repo that we just put it into a subdir of the recipe called "license" and then it just gets picked up from there instead.

Where exactly would you create the "license" subdir? in $prefix ?
If we did so, we would have to teach haikuporter how to handle this. The way I'm installing the licenses is easy to understand and does not require any changes in haikuporter.

Your commit said that you simplified the license.

I guess you are referring to this commit:
9c48b0bebae2418ca6a47ca4b548d7fd07f97c67 dev-python/cryptography: simplify COPYRIGHT, define myLicensesDir.
So what it simplifies is COPYRIGHT, not LICENSE.

What's simpler than a single line of code to point to the license?

As said earlier, we cannot just add a pointer to a license because in some cases the licenses have specific data like the name of the author of that of an organisation. Discarding this data and, instead, providing a pointer to a license which has placeholders is not correct.

your method added several lines and more clutter.

IMHO it's not clutter. We have a problem here because we are not respecting the licenses. My recent commits fixes this problem, and I think it does this nicely.

[alaviss]

See https://github.com/haikuports/haikuporter/issues/156

[waddlesplash]

As said earlier, we cannot just add a pointer to a license because in some cases the licenses have specific data like the name of the author of that of an organisation. Discarding this data and, instead, providing a pointer to a license which has placeholders is not correct.

Do you have a citation for this?

[fbrosson]

No. This is just common sense.

[fbrosson]

@pulkomandy, here's the answer to the message you wrote here: https://github.com/haikuports/haikuports/commit/a7ce9805ffbb4372483b83379f3770d41d49e276#commitcomment-31135697

Although we keep some metadata in our recipes (in COPYRIGHT & LICENSE), it is not identical to what the authors put in their licenses, so we are not respecting the licenses.

Nothing mandates that the copyright header and the licence are kept together in the same file.

I disagree. Take the BSD (2 clause) license:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

My understanding is that _"must retain"_ and _"must reproduce"_ do have a strong meaning, so we should not split that information in different places. Having one piece of the information in the metadata of the package, and the rest in a separate text file is not compatible with e.g. the BSD licenses.

Regarding the placeholders we have in some of the licenses that are shipped with Haiku, not shipping in a package the exact copies of each of its licenses is wrong.

We should honestly make it easy for any user to find all the licenses a package uses, and IMHO the best way to do that is to do something similar to what Debian does. That's what I did.

Regarding the symlink topic, I believe it is fair to replace a license by a symlink to a file provided by Haiku as long as the files are identical (or if they are identical if we ignore the line breaks.) That's what I did with Apache v2 license in pytz, cryptography, cryptography-vectors and pyOpenSSL.

[scottmc]

We meet #1, all of the source including their original license info is in the source packages isn't it? We also meet #2, as we include the copyright info, and the rest is still contained in the license file we point to.

[fbrosson]

The problem is that _including_ some pieces of information is not the same as _reproducing_ a text.

Moreover, the copyright info we provide is not accurate and does not include the "Copyright (c)" string.
With all my respect I still think we're not OK with the way we create our binary packages.

Again, I'm not saying we should fix everything. I'm just willing to be granted permission to start improving things a little with a smooth transition.

[alaviss]

https://github.com/haikuports/haikuporter/issues/156#issuecomment-352761234

MIT license

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

IANAL, but IMO, for the MIT license, we have a few problems:

• The copyright notice is not included, haikuporter policy requires us to remove "Copyright", "(C)", and email address from COPYRIGHT variable

• The permission notice is nowhere to be found in the package. Depending on a package that include the said license is not enough, the license requires itself to be included in all copies

• Also, the use of this license requires modifying the first line, which make each one of them a custom one, which in turn, requires us to include them. Distributions like Arch ship a version in all package using it

[alaviss]

I'm just willing to be granted permission to start improving things a little with a smooth transition.

I'm not a fan of further recipe extension that needs to be copied around... Although that might be remedied if #2541 were ever to be implemented.

[waddlesplash]

Indeed, we should just implement HaikuPorter#2541, that will solve most problems here.

And the copyright string has "copyright" implicitly, yes? In the PackageInfo it will be copyright "200X...", so the (C) is redundant anyway.

[fbrosson]

All major distros are dealing with the license topic by adding explicit instructions to copy the licenses to their binary packages. So these distros all have a few extra lines in their packaging.

[scottmc]

If you look at how these appear in HaikuDepot you will notice that the (c) copyright part is automatically inserted for us, this is how it was designed to work. This is why we remove that from the recipe, otherwise it'd print it twice.

[alaviss]

Some projects put email addresses into the copyright clause, which means we'd have to preserve it as well, but our policy ban such entries (it's enforced with haikuporter).

[scottmc]

Perhaps @weinhold can chime in on this one?

[pulkomandy]

On Thu, Nov 01, 2018 at 04:08:29PM +0000, fbrosson wrote:

@pulkomandy, here's the answer to the message you wrote here: https://github.com/haikuports/haikuports/commit/a7ce9805ffbb4372483b83379f3770d41d49e276#commitcomment-31135697

Although we keep some metadata in our recipes (in COPYRIGHT & LICENSE), it is not identical to what the authors put in their licenses, so we are not respecting the licenses.

Nothing mandates that the copyright header and the licence are kept together in the same file.

I disagree. Take the BSD (2 clause) license:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

My understanding is that _"must retain"_ and _"must reproduce"_ do have a strong meaning, so we should not split that information in different places. Having one piece of the information in the metadata of the package, and the rest in a separate text file is not compatible with e.g. the BSD licenses.

Your understanding is going further than what's written.

Redistribution in binary form must reproduce:

• The copyright notice
• The list of conditions
• The disclaimer

It even does not need to be in the hpkg file, but "in the documentation
and/or other materials provided with the distribution". So, having the
licence file in the haiku package (which is provided in the same place
as other hpkg) is fine.

And having the copyright in the hpkg metadata is also fine.

(redistribution in source form does not worries us because it would
already include the licence file anyways).

Regarding the placeholders we have in some of the licenses that are shipped with Haiku, not shipping in a package the exact copies of each of its licenses is wrong.
We should honestly make it easy for any user to find all the licenses a package uses, and IMHO the best way to do that is to do something similar to what Debian does. That's what I did.

Copying the licence text everywhere just makes it harder to identify the
licence. Just telling people "this piece of code uses licence X and here
are the copyright holders" is easier for everyone. You are overdoing
this.

Regarding the symlink topic, I believe it is fair to replace a license by a symlink to a file provided by Haiku as long as the files are identical (or if they are identical if we ignore the line breaks.) That's what I did with Apache v2 license in pytz, cryptography, cryptography-vectors and pyOpenSSL.

Just use the LICENSE field in the package header, that's what it was designed
for. If that makes you happy we can make pkgman generate the exact text
from the licence file (found using LICENSE), and the COPYRIGHT entry (we
just need to print the COPYRIGHT, then the text from the LICENSE file
basically). We can have the license files use %copyright% and replace
that on the fly then. I find that useless, but if it makes you happy...

Cluttering the filesystem with files and symlinks is useless. Nothing in
any of the licenses says they should be available as files. Nothing even
says they must be part of the package itself.

--
Adrien.

[fbrosson]

If that makes you happy...
We can have the license files use %copyright% and replace that on the fly then. I find that useless, but if it makes you happy...

I hope this is a joke. How can you think this would make me happy?
Why can't we keep things simple?
Can't we just ship the licenses like all other major distros do?
Claiming this information is available on HaikuDepot does not change anything because one can use pkgman and never launch HaikuDepot. So we cannot say that displaying information on HaikuDepot is enough. The licenses need to be available on the filesystem. Refusing to do so is not correct.

[pulkomandy]

On Thu, Nov 01, 2018 at 02:48:56PM -0700, fbrosson wrote:

Claiming this information is available on HaikuDepot does not change anything because one can use pkgman and never launch HaikuDepot. So we cannot say that displaying information on HaikuDepot is enough. The licenses need to be available on the filesystem. Refusing to do so is not correct.

You are inventing licence terms. Nothing, anywhere, says the licence
needs to be on the filesystem. What's next? arguing that compressing the
package is not allowed because people can't see the licence using an hex
editor?

This is stupid. Let's stick to what the licence file actually requires.
And please don't add license files everywhere just for fun. If we really
need one custom license per package, let's make the whole license text
part of the package metadata. The point of having them as files was to
share them, but if that's not allowed, let's give up on this and then
there is no need to use files for licenses.

[fbrosson]

What's next? arguing that compressing the package is not allowed because people can't see the licence using an hex editor?

:-1:

[waddlesplash]

I am in full agreement with @pulkomandy here -- The HaikuPorter issue should probably be implemented, but otherwise, leave the license text as a template and then include the Copyright only in the PackageInfo.

[alaviss]

@pulkomandy

Please note that while the BSD license only requires you to reproduce the notice, license like the MIT license go further and requires you to actually keep a copy in your distribution:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

[waddlesplash]

It says nothing about them being together though.

[alaviss]

IANAL, but since the .hpkg contains the software, doesn't also mean the license text must also be included in there?

[alaviss]

Anyway, since this is pretty much a legal issue, wouldn't it be nice for us to have an actual lawyer chime in?

[waddlesplash]

Yes, we need to include the license text. But that just means duplicating the "MIT License" file inside the package. That's all.

[scottmc]

See resolution on https://github.com/haikuports/haikuporter/issues/156