Missing MPL notice and source redist for publicsuffix data

[pombredanne]

From what I can see an older version of https://publicsuffix.org/list/public_suffix_list.dat is bundled in https://github.com/square/okhttp/tree/2f4b90050e739f2310a1e1a26634124dd3b618e2/okhttp/src/main/resources/okhttp3/internal/publicsuffix ... but there is no indication anywhere that this is using an MPL-license. This is not Apache-licensed for sure (as your code is at https://github.com/square/okhttp/blob/2f4b90050e739f2310a1e1a26634124dd3b618e2/okhttp/src/main/java/okhttp3/internal/publicsuffix/PublicSuffixDatabase.java )

IMHO, somehow, somewhere I think that the original notice from https://publicsuffix.org/list/public_suffix_list.dat should be included in the JARs at the minimum and that the source for the list data should be made available for redistribution since the license is MPL...

// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at https://mozilla.org/MPL/2.0/.

See https://github.com/publicsuffix/list/blob/master/LICENSE#L170 for details.

[swankjesse]

Can fix!

[swankjesse]

@pombredanne thanks for flagging this. Lemme know if I’ve missed anything! #4657

[pombredanne]

@swankjesse that's good enough... though it would be best if this was surfaced in the generated POM too (such that tools can pick this up upfront and this is more easy to grok such as in https://clearlydefined.io/ and https://github.com/nexB/scancode-toolkit )

[JakeWharton]

Is specifying both licenses in the pom misleading? I wouldn't want someone to think the this codebase is entirely dual licensed. Not sure of the precedent for this.

…

On Thu, Apr 4, 2019, 6:40 AM Philippe Ombredanne ***@***.***> wrote: @swankjesse <https://github.com/swankjesse> that's good enough... though it would be best if this was surfaced in the generated POM too (such that tools can pick this up upfront and this is more easy to grok such as in https://clearlydefined.io/ and https://github.com/nexB/scancode-toolkit ) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEESoAnGJYSABGFo7OIrbBSFepHPVWks5vddaQgaJpZM4aLXOa> .

[pombredanne]

@JakeWharton I guess that the license terms to consider for the whole are Apache-2.0 AND MPL-2.0 yet I reckon your concern that the latter is not the same as the former. The POM is reasonably weak to express such things in general (this is just a list of licenses..) and I am not sure Gradle-generated POMs can do much in this area.
One possibly could be to add a in the tag for the Apache license at least.
ATM your POMs seem rather light on the license details side in general 😉 : http://central.maven.org/maven2/com/squareup/okhttp3/okhttp/3.14.0/okhttp-3.14.0.pom

[JakeWharton]

Yeah you have to traverse the hierarchy of parent poms to create the canonical pom (I forgot the real term) for each artifact. The immediate parent has the <licenses> section: http://central.maven.org/maven2/com/squareup/okhttp3/parent/3.14.0/parent-3.14.0.pom .

…

On Thu, Apr 4, 2019 at 11:03 AM Philippe Ombredanne < ***@***.***> wrote: @JakeWharton <https://github.com/JakeWharton> I guess that the license terms to consider for the whole are Apache-2.0 AND MPL-2.0 yet I reckon your concern that the latter is not the same as the former. The POM is reasonably weak to express such things in general (this is just a list of licenses..) and I am not sure Gradle-generated POMs can do much in this area. One possibly could be to add a in the tag for the Apache license at least. ATM your POMs seem rather light on the license details side in general 😉 : http://central.maven.org/maven2/com/squareup/okhttp3/okhttp/3.14.0/okhttp-3.14.0.pom — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEERTBPIbbvo_Bx-x-hcj-8ZJamWtgks5vdhRKgaJpZM4aLXOa> .

[pombredanne]

@JakeWharton re:

traverse the hierarchy of parent poms

This feels like a rather fragmented path to get the information. This also means that at runtime (where only a JAR and no parent POM is around), there is no license information available inside the JAR

[JakeWharton]

I'm just relaying how the Maven pom works. We didn't invent this system. If this is unsuitable for some reason, please open a separate issue.

…

On Fri, Apr 5, 2019 at 5:29 AM Philippe Ombredanne ***@***.***> wrote: @JakeWharton <https://github.com/JakeWharton> re: traverse the hierarchy of parent poms This feels like a rather fragmented path to get the information. This also means that at runtime (where only a JAR and no parent POM is around), there is no license information available inside the JAR — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEbzGK3k_atjXvV9XJhV-v6aNymInks5vdxdjgaJpZM4aLXOa> .