Please bundle LICENSE/NOTICE files in the produced jar files

[wrandelshofer]

Please bundle LICENSE/NOTICE files in the produced jar files

[vlsi]

Consider adding Bundle-License manifest to the jar as well.

[vlsi]

Here's 2.15.0:

% unzip -l jackson-core-2.15.0.jar   | grep doubleparser
        0  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/
      595  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/AbstractFloatValueParser.class
     5338  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/AbstractJavaFloatingPointBitsFromByteArray.class
     5704  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/AbstractJavaFloatingPointBitsFromCharArray.class
     5717  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/AbstractJavaFloatingPointBitsFromCharSequence.class
     1769  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/AbstractNumberParser.class
     2306  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/BigSignificand.class
    24575  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastDoubleMath.class
     8217  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class
     3311  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastFloatMath.class
      279  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath$1.class
      907  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath$UInt128.class
     5425  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class
     6637  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FftMultiplier$ComplexVector.class
     3569  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FftMultiplier$MutableComplex.class
    13936  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/FftMultiplier.class
     6587  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigDecimalFromByteArray.class
     6660  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigDecimalFromCharArray.class
     6815  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigDecimalFromCharSequence.class
     2053  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigDecimalParser.class
     4832  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigIntegerFromByteArray.class
     4708  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigIntegerFromCharArray.class
     4856  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigIntegerFromCharSequence.class
     2702  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaBigIntegerParser.class
     1845  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaDoubleBitsFromByteArray.class
     1722  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaDoubleBitsFromCharArray.class
     1889  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaDoubleBitsFromCharSequence.class
     2099  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaDoubleParser.class
     1819  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaFloatBitsFromByteArray.class
     1692  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaFloatBitsFromCharArray.class
     1822  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaFloatBitsFromCharSequence.class
     2089  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/JavaFloatParser.class
     2627  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/ParseDigitsTaskByteArray.class
     2627  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/ParseDigitsTaskCharArray.class
     2793  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/ParseDigitsTaskCharSequence.class
      148  03-04-2023 15:31   com/fasterxml/jackson/core/io/doubleparser/package-info.class
        0  03-04-2023 15:31   META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/
     2626  03-04-2023 15:31   META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/BigSignificand.class
     8159  03-04-2023 15:31   META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class
      599  03-04-2023 15:31   META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath$UInt128.class
     5312  03-04-2023 15:31   META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class
        0  03-04-2023 15:31   META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/
     8240  03-04-2023 15:31   META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class
      599  03-04-2023 15:31   META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath$UInt128.class
     5312  03-04-2023 15:31   META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class
        0  03-04-2023 15:31   META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/
     7793  03-04-2023 15:31   META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class
      599  03-04-2023 15:31   META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath$UInt128.class
     5112  03-04-2023 15:31   META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class

[pjfanning]

MIT and Apache licenses are compatible. It's probably easier and less confusing if jackson uses FastDoubleParser code under standard MIT license and properly notes this in its docs and jar contents.

[wrandelshofer]

I have done the following now:

• the POM files and the MANIFEST.MF file in each jar file contain now links to a MIT license file with concrete year and author (no placeholders)
• the MIT license file is now included in each jar file
• the README explicitly states that this project can also be licensed under Apache 2.0 license.

What do you think?

Fix steps

1. Include the license text into the jars under `META-INF/LICENSE`, `META-INF/NOTICE`, etc. It would enable consumers to get up-to-date licenses when they depend on fastdoubleparser.

2. Fix `pom.xml` to point to the proper license text (e.g. a permalink to GitHub). The current link `http://www.opensource.org/licenses/mit-license.php` is invalid as it points to a **wrong** license text.

3. Add `Bundle-License: Apache-2.0` (or `Bundle-License: MIT; link=...`) manifest entry (where `Apache-2.0` is SPDX identifier, see https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license )

[wrandelshofer]

Noone can guarantee GitHub links will be accessible forever.

We do not need to rely on GitHub. From the contents of the link it is easy to access the file. This still satisfies 'give'.

They have FAQ, and they explicitly mention the license text must be included

This is not enforceable. The FAQ is not part of the license.

We are digressing here. I am closing this issue.

[wrandelshofer]

Last week you said "Guava misses LICENSE file in jar, so including the license is not needed": #38 (comment)
I just proved that was an issue with Guava releases, and the upcoming releases will bundle LICENSE file just like Google Guice.

You haven't proved that. My counter-argument was:
"Of course, it is not forbidden to include the Apache 2 License text. But that is not an obligation from the license."

You keep saying "wanted 'give' for the license". English is not my native language, and I can hardly get all the 1000 meanings of give.

Good. Now please lookup the number of meanings for 'include'.
You will find less meanings for it, because it is more specific than 'give'.

However, I asked that very same question at https://issues.apache.org/jira/browse/LEGAL-642, and both volunteers and lawyers (Roman Shaposhnik is V.P. Legal Affairs at the ASF: https://apache.org/foundation/#who-runs-the-asf ) say that the intention of the license is that everybody should get a readable copy of the license without any extra Internet access.

Here, my argument still is: One can not add claims to a contract using an FAQ or Q&A.

I do not see why you say "I am going in circles".

It is our arguments that are going in circles. I have no new arguments that I can give to the arguments that you are bringing up.

[lemire]

Speaking for myself, I am committed to working with any project that wants to use a library I maintain. I will help work through any issues they have, either due to licenses or other issues.

[pjfanning]

@wrandelshofer this is due to a bug in the Jackson build and jackson team will fix that in the next Jackson release - see FasterXML/jackson-core#999

[vlsi]

I did not notice jackson-core shades fastdoubleparser.
As jackson shades the parser, it is even more important issue. Apparently, jackson-core currently violates fastdouble parser license requirements as jackson-core includes a copy of the parser, and it misses the copyright and permissions provided by fastdoubleparser.

[wrandelshofer]

@pjfanning I have licensed FastDoubleParser to Jackson-Core with Apache 2.0 License here:
FasterXML/jackson-core#577 (comment)

Therefore, Jackson-Core does not need to include an MIT License in their distro.

[wrandelshofer]

@vlsi

I have done now the following changes:

• We include now the LICENSE file in the META-INF folder. Thank you for pointing that out!

• We use now the verbatim MIT License text. Therefore the part of the license body text that refers to the copyright notice is now correct in the literal sense and not just in the semantical sense. I mean, it is clearly obvious that there are placeholders in that file. Only difference now are the quote glyphs. They do not change semantics in any way. I even use the ugly upper case text. Having text in upper case or lower case does not change its semantics.

[wrandelshofer]

@pjfanning Does Jackson-Core really shadow FastDoubleParser? It would be better to pull them into the JacksonCore namespace. Shading of packages from another Java Module is not allowed in Java Modules.

[wrandelshofer]

So, it is not shadowing FastDoubleParser. ☺️

Copying the code this way is a good thing in terms of security. JacksonCore has vetted a specific revision of FastDoubleParser and made it their own. This removes one vector of supply chain attacks. ☺️

[pjfanning]

@cowtowncoder prefers not to have non-Jackson dependencies - that's why we bundle the code in jackson-core. The package names are changed as part of this bundling.

[vlsi]

So, it is not shadowing FastDoubleParser

Frankly speaking, the whole story of custom licensing FastDoubleParser to Jackson-core is really moot to me.

Apparently, the current Jackson-core code does not have files like AbstractFloatValueParser.java.
At the same time, they do have shade configuration for fastdoubleparser: https://github.com/FasterXML/jackson-core/blob/jackson-core-2.15.0/pom.xml#L170-L204

In other words, they just select current code of fastdoubleparser and they ignore the license.

So did you explicitly mention that you license all versions of fastdoubleparser to jackson-core?
What if fastdoubleparser changes its license one day and jackson would not notice it?

What happens to the people who do custom builds of jackson (e.g. if they maintain forks). Does that mean your grant of using fastdoubleparser in jackson-core under Apache-2.0 automatically means everyone who forks jackson could use fastdoubleparser under AL-2.0?

Frankly speaking, it is extremely moot.

[wrandelshofer]

What happens to the people who do custom builds of jackson (e.g. if they maintain forks). Does that mean your grant of using fastdoubleparser in jackson-core under Apache-2.0 automatically means everyone who forks jackson could use fastdoubleparser under AL-2.0?

@vlsi Yes, they automatically use AL-2.0.

@pjfanning Consider replacing the FastDoubleParser file headers with the jackson-core file headers, and generating the References-Javadoc comment, as I had proposed in FasterXML/jackson-core#577 (comment). So that it is clear to everyone that these files are under the same license as jackson-core.

[vlsi]

In a nutshell, the current story of FastDoubleParser-Jackson is really fragile, and it is unclear what are the licensing implications for those who perform custom build of jackson-core.

@pjfanning , I would suggest you follow the general licensing rules. For instance, shade the code based on the MIT license, and include the license text accordingly into jackson-core. An alternative option would be figuring out what are the implications for the users who build jackson-core from source. For instance, if everyone who builds jackson-core from source must include MIT license from fastdoubleparser or ask @wrandelshofer , then it is something that is extremely important in licensing notice of jackson-core.

Taking jackson-core popularity into account, it would be really great to have regular licensing information rather than a custom agreement between fastdoubleparser and jackson developers.

[vlsi]

Consider replacing the FastDoubleParser file headers with the jackson-core file headers, and generating the References-Javadoc comment, as I had proposed in FasterXML/jackson-core#577 (comment). So that it is clear to everyone that these files are under the same license as jackson-core.

@wrandelshofer , jackson-core does not use source-form of fastdoubleparser.
jackson-core uses binary class files. Could you please clarify where did you mention that you grant such use for all fastdoubleparser versions? Could you please clarify where did you mention that you grant such use for everybody who makes custom builds of jackson?

I would suggest avoid such license customizations as it inevitably requires lawyer analysis.

It would be much easier if:
a) jackson-core used the regular procedure and included fastdoubleparser under MIT license terms (==reproduced license in the jackson-core.jar)
b) OR fastdoubleparser relicensed to AL-2.0 for everybody, and then, again jackson-core should use the regular procedure for embedding/redistributing third-party code (==reproduce license text, etc, etc)

[wrandelshofer]

If there is any confusion, then it is only in Jackson-Core. It is not in this project. Right?

I mean, I licensed this project to Jackson-Core under AL-2.0, therefore Jackson-Core clearly has the right to redistribute it and make derivations under term 4 "Redistribution" of AL-2.0. And this is clearly perpetual, see term 2 of AL-2.0.

[vlsi]

I mean, I licensed this project to Jackson-Core under AL-2.0, therefore Jackson-Core clearly has the right to redistribute it and make derivations under term 4 "Redistribution" of AL-2.0.

Can you put the information to FastDoubleParser license ?
In practice, every new version for FDP should be relicensed unless there's an explicit mention that "all FDP versions can be used under AL in Jackson".

And this is clearly perpetual, see term 2 of AL-2.0.

The license applies to each release individually. The perpetual in AL-2.0 means you have a perpetual terms on a specific package.
AL-2.0 has no guarantees and restrictions that would automatically grant the use of future releases.

Basically, if you mean that you grant the use of FDP to Jackson-Core, then it is de-facto a license term in FDP which you'd better put in the license explicitly.

However, such customization for a single project would look really odd as it would produce a new license that will have to be analyzed by the lawyers.

[pjfanning]

MIT license is Category A according to https://www.apache.org/legal/resolved.html - it is ok to include the code from Category A licenses.

We can certainly do better in jackson-core but I think adding something to the NOTICE file acknowledging that the shaded code is MIT licensed and copyrighted is enough.

[vlsi]

@pjfanning we do not include fastdoubleparser directly in JMeter, and we include it through jackson-core that shades FDP at the build time.

The license implications in jackson-core are moot.

[vlsi]

We can certainly do better in jackson-core

Would you please follow regular approach for shading dependencies in jackson-core instead of negotiating jackson-specific license terms for FDP?

As jackson-core user, I would like to see proper licensing info on all the embedded packages.

[pjfanning]

I'm involved in ASF projects and have dealt with ASF legal. I do not know where you are coming from - if you have a suggestion, do a PR and we can consider it. What is the regular approach?

#38 (comment) points are basically directed at @wrandelshofer - I have little control over what Werner puts in his license files.

Plenty of ASF projects shade code from non-Apache licensed sources and I see none of this hullabaloo on those projects.

[vlsi]

I do not know where you are coming from -

I'm from Apache JMeter project, I'm a member of PMC for JMeter, so a part of my duty is to keep licensing for JMeter clear.
I bumped into fastdoubleparser licensing when upgrading jackson in JMeter.

if you have a suggestion, do a PR and we can consider it. What is the regular approach?

Follow the official licensing terms instead of custom agreements written in GitHub comments.
The current license terms for FastDoubleParser are "MIT license". Why don't jackson-core just follow the license, and include license text in jacskon-core.jar?

See FasterXML/jackson-core#1002

At the same time, it would be nice if FDP could be relicensed under Apache-2.0 for everybody. That is not really required, and MIT license works just fine. However, Apache-2.0 is designed better, so there's no real reason to use MIT nowadays.

[wrandelshofer]

I have now added a description to the README file, that states how this project can be licensed under Apache 2.0 License terms.

FastDoubleParser/README.md

Lines 14 to 26 in 23cfaf3

	## License
	Everything except the content of the folder `supplemental_test_files` is MIT License.
	The content of the folder `supplemental_test_files` is Apache 2.0 License.
	Alternatively, you can license this project under the Apache 2.0 License. Please, do the following:
	- copy source files from this project into your project - as needed
	- replace the file headers with the file headers of your project.
	- Insert a comment in the file, that states that the file originates from
	FastDoubleParser, Copyright © Werner Randelshofer, Switzerland, Apache 2.0 License.
	- Include a copy of the Apache 2.0 License in your distribution, as required by its license terms.

If someone uses the FastDoubleParser distro, the license is MIT. If someone needs it under another license, they have the possibility to do this at the source level, and they have to update the copyright notice in the file. So that no confusion can arise.

@vlsi What do you think?

[vlsi]

the POM files and the MANIFEST.MF file in each jar file contain now links to a MIT license file with concrete year and author (no placeholders)
the MIT license file is now included in each jar file

That is great. Extra bonus point goes for using permalink for the license file in pom.xml.

the README explicitly states that this project can also be licensed under Apache 2.0 license.

Is there a specific reason why you require copy-pasting the sources for licensing under Apache 2.0?

I would suggest one of the two:
a) Just license under MIT and avoid mentioning Apache 2.0 as mentioning Apache 2.0 in that context makes things more complicated with unknown gains
b) License under MIT or Apache-2.0 (see https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/ )
c) License under Apache-2.0 (and do not mention MIT)

[wrandelshofer]

Is there a specific reason why you require copy-pasting the sources for licensing under Apache 2.0?

I was just trying to be helpful. You are right - they are free to just copy a few binary files.

Thank you for always providing goal-oriented proposals. This is helpful, really! 🙂

a) I already have to mention Apache 2.0 because there is some Apache 2.0 code in the project repository. That code is not part of the deployed artefacts.
b) Including two licenses does not scale. I am willing to license this project under many different licenses.
c) Apache-2.0 is nedlessly wordy. I prefer conciseness. Everything that is not explicitly stated is regulated in the Swiss Code of Obligations anyway. And statements that contradict that law, are nil.

[vlsi]

a) I already have to mention Apache 2.0 because there is some Apache 2.0 code in the project repository.

That is yet another point for including the license in relevant archive files as each jar file might happen to include files under different licenses.

I am willing to license this project under many different licenses.

Frankly speaking, I would suggest refraining from overcomplicating licensing unless there's a justified demand.

For instance, pom.xml allows specifying multiple licenses in the <license> tag. However, it has absolutely no specification on the meaning of those multiple entries. It does not clarify if multiple licenses should be treated as A or B or A and B.
So I think any attempt to dual-license would trigger custom flows for the consumers: they'll have to figure out the license terms.

In other words, stick with MIT until somebody suggests a good reason for dual-licensing or whatever.
I would say a demand for custom licensing under Apache-2.0 for jackson-core was not justified. They could include MIT-licensed fastdoubleparser just fine.

[wrandelshofer]

That is yet another point for including the license in relevant archive files as each jar file might happen to include files under different licenses.

I agree. We do not deploy FastDoubleParser artefacts with these files.

For instance, pom.xml allows specifying multiple licenses in the tag. However, it has absolutely no specification on the meaning of those multiple entries. It does not clarify if multiple licenses should be treated as A or B or A and B. So I think any attempt to dual-license would trigger custom flows for the consumers: they'll have to figure out the license terms.

I agree. We do not deploy FastDoubleParser multi-license artefacts.

In other words, stick with MIT until somebody suggests a good reason for dual-licensing or whatever.
I would say a demand for custom licensing under Apache-2.0 for jackson-core was not justified. They could include MIT-licensed fastdoubleparser just fine.

The way jackson-core was released, is legally sound. If you look at the artefacts that they published on mvncentral. Then all of that is under Apache 2.0. If they had copied the source from FastDoubleParser and changed the copyright notice in the file headers, as I had proposed, you would not be confused about it.

[wrandelshofer]

The way jackson-core was released, is legally sound. If you look at the artefacts that they published on mvncentral. Then all of that is under Apache 2.0. If they had copied the source from FastDoubleParser and changed the copyright notice in the file headers, as I had proposed, you would not be confused about it.

It appears that it was not legally sound. 🙃

I have now changed the build scripts, so that Jar files contain the additional license files, that are required by the third-party code, that we use in this project.

[wrandelshofer]

I have now added a NOTICE file to this project. The NOTICE file will be included in the META-INF folder of all Jar files, that we deploy.

[wrandelshofer]

LICENSE and NOTICE files are now bundled in Release v0.9.0 of FastDoubleParser.
https://github.com/wrandelshofer/FastDoubleParser/releases/tag/v0.9.0

[vlsi]

Technically speaking, if fastdoubleparser-0.9.0.jar includes bits licensed under Apache 2.0, then you should include license text in fastdoubleparser-0.9.0.jar:

 (a) You must give any other recipients of the Work or
     Derivative Works a copy of this License; and

https://github.com/lemire/fast_double_parser/blob/07d9189a8fb815fe800cb15ca022e7a07093236e/LICENSE#LL94C9-L95C55

[wrandelshofer]

3. With Apache-2.0 you can have a canonical license URL right in pom.xml and MANIFEST.MF

I don't understand. You stated that I can have a canonical license.

(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and

This texts, says 'give' and not 'include'. Therefore, I can 'give' other recipients the license, by providing the link to the canonical license.

[vlsi]

I don't understand. You stated that I can have a canonical license.

The canonical text would mean that you could have, well, a canonical text that is the same for all Apache-2.0 licensed projects.
For instance, if you license under Apahce-2.0, and you bundle a dependency that is AL-2.0 licensed, then you'll have the same texts for both of them. In that regard, MIT licenses are all different, and you have to include several copies of MIT licenses.

I have never said you won't be required to include AL-2.0 text.

This texts, says 'give' and not 'include'.

The text says 'copy'. I doubt a link that might easily die qualifies as a copy.

[wrandelshofer]

You can not claim that the license text is precise and that it is not precise at the same time.

4.(a) says 'give' for the license. So we 'give' the license.
4.(d) says 'include' for the notice. So we 'include' the notice.

If they would have wanted me to include the license, they would have written so.

(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and ...

(d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, ...

The text says 'copy'. I doubt a link that might easily die qualifies as a copy.

We did not give a link that might easily die. We did provide perma-links.

[vlsi]

You can not claim that the license text is precise and that it is not precise at the same time.

They said 'copy', and a link is definitely not a 'copy'.

You can not claim that the license text is precise and that it is not precise at the same time.

If you hate Apache-2.0 license, you always have an option to stop redistributing Apache-2.0-licensed dependencies.

We did not give a link that might easily die. We did provide perma-links

The author could drop the repository (see leftpad in npmjs).
GitHub can ban the repository author for various reasons (e.g. for violating some of the terms).
GitHub can stop operating.

Those are only a few cases when your "perma-link" will stop working.

[wrandelshofer]

They said 'copy', and a link is definitely not a 'copy'.

This is false. If you click at the link, you indeed get a copy of the license.
If I would not have been allowed to choose the means for 'giving' the copy to you, they would have written so.

If this is your argument, you could also argue that including the notice in the META-INF folder of a compresseed Zip file is definitely not a 'readable copy'. It can only be accessed with special tools. A separate text file would be more 'readily' available. But the license does not oblige us to do so. So, we do not do it.

If you hate Apache-2.0 license, you always have an option to stop redistributing Apache-2.0-licensed dependencies.

This does not matter.
There is no point in doing things that we are not obliged to - unless we add value to our users, of course.
There is no added value. The link is sufficient. All obligations are fulfilled.
We provably safe disk space by only including only the link. This is added value.

Those are only a few cases when your "perma-link" will stop working.

This is a federated repository. If the author drops it, there still exist many copies of the repository.
So, the worst that can happen is that the URL has been degraded to an URI.
It is safe to assume that the provided perma-link URIs can be easily accessed in 1,000 years.

[vlsi]

This is false. If you click at the link, you indeed get a copy of the license.

If GitHub bans author or repository, then the link and all copies would easily become unavailable. It has happened many times in the past.

Noone can guarantee GitHub links will be accessible forever.

At the same time, countries might even block access to GitHub. For instance, GitHub is blocked in China.

See the opinion of the Apache Software Foundation: https://infra.apache.org/apply-license.html#copy-per-file , https://www.apache.org/legal/src-headers.html#faq-binaries

They have FAQ, and they explicitly mention the license text must be included

This is a federated repository

The canonical Apache-2.0 text is https://www.apache.org/licenses/LICENSE-2.0

It does not depend on individual users. However, there are no guarantees on page availability, so it would still be better copy just in case.

[vlsi]

From the contents of the link it is easy to access the file. This still satisfies 'give'.

You ignore that a link is not a copy.
You ignore that github shutdown or repository deletion would make both the link and its contents unavailable.

---

The faq is not a part of the license, however, it exists because many people thought the license file can be omitted.

[wrandelshofer]

Please look up the meaning of the word 'give'.

I have stated earlier in this thread, that I believe that it is impossible to construct a claim for this.
Here: "You can not claim that the license text is precise and that it is not precise at the same time."

If they made the FAQ, because many people thought that the license file can be omitted, then it must not have been an issue for them. If it would have been an issue, they would have made a new version of the license. No?
I mean, they did that at least once create a new version (because it says Apache 2.0). So, if there was something about the license terms, that would need amendment, they would have done so.

[wrandelshofer]

I see that fast_float distributes its code in a single header file.

Here:
https://github.com/fastfloat/fast_float/releases/download/v4.0.0/fast_float.h

It only contains these lines from the Apache License:

// Licensed under the Apache License, Version 2.0, or the
// MIT License at your option. This file may not be copied,
// modified, or distributed except according to those terms.
//
...
// Apache License (Version 2.0) Notice
//
//    Copyright 2021 The fast_float authors
//    Licensed under the Apache License, Version 2.0 (the "License");
//    you may not use this file except in compliance with the License.
//    You may obtain a copy of the License at
//    
//    http://www.apache.org/licenses/LICENSE-2.0
//    
//    Unless required by applicable law or agreed to in writing, software
//    distributed under the License is distributed on an "AS IS" BASIS,
//    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//    See the License for the specific language governing permissions and
//

What do you think?
Is this also wicked?
Would it satisfy you, if I did the same?

[wrandelshofer]

I have just downloaded Google Guava, and I looked in the guava-31.1-jre.jar and guava-31.1-jre-sources.jar, and neither contains a copy of the Apache License.

https://mvnrepository.com/artifact/com.google.guava/guava/31.1-jre

I believe, your request about inclusion of the Apache License in the jar file is wishful thinking. 🤔

[vlsi]

@wrandelshofer , I asked Google Guava to bundle LICENSE, and they did that in google/guava@7d41e19

Please look up the meaning of the word 'give'.

Just in case, here's the opinion of the Apache Software Foundation: https://issues.apache.org/jira/browse/LEGAL-642
Apparently, they say the license must be included.

---

I see that fast_float distributes its code in a single header file.

I asked fast_float.h to bundle the license in the releases: fastfloat/fast_float#201.

[lemire]

@vlsi Can be specific as to the problem you are having or trying to solve?

If your legal team has an issue, I am open to a meeting to discuss it.

I fail to see a problem with how we release the code in fast_float...

https://github.com/fastfloat/fast_float/releases

The license is provided in the source package, and there is a nice header in the source header that we provide.

I have also checked Apache projects, and they don't appear to include a copy of the license with every artefact.

[wrandelshofer]

@vlsi We are having a circular discussion now. I brought up all my arguments before, and you are bringing up your arguments again.

@wrandelshofer , I [asked Google Guava to bundle ...

I have now included all license texts of the licenses that explicitly required to 'include' their text.
I carefully read the Apache 2 License and noticed that they wanted 'give' for the license and 'include' for the notice.
I have performed 'give' and 'include' as required.

Of course, it is not forbidden to include the Apache 2 License text. But that is not an obligation from the license.

Just in case, here's the opinion of the Apache Software Foundation: ...

My argument was, that an FAQ can not add new claims to a license.
Consequently, a Q&A can also not add new claims to a license.

[vlsi]

Can be specific as to the problem you are having or trying to solve?

@lemire , please check the very first three sentences in the very first comment (issue description).

I was trying to upgrade jackson version in Apache JMeter, and the build failed because jackson listed fastdoubelparser dependency that missed proper licensing.

If your legal team has an issue, I am open to a meeting to discuss it.

As I clarified, Apache lawyers say every release must bundle the license https://issues.apache.org/jira/browse/LEGAL-642
Of course, every company would have different lawyers and they might have different opinions.
However, I want that all the users of Apache JMeter could easily check that all the dependencies are used properly, and they should be able to check that no dependency adds vendor lock-in.

I have also checked Apache projects, and they don't appear to include a copy of the license with every artefact.

@lemire , It is unfair to say "Apache projects fail to comply with the license, so everybody can ignore it".
Apache release policy says

https://www.apache.org/legal/release-policy.html#licensing
Every ASF release MUST comply with ASF licensing policy. This requirement is of utmost importance and an audit SHOULD be performed before any full release is created. In particular, every artifact distributed MUST contain only appropriately licensed code per Apache Licensing Policy.

So it should be quite easy to convince Apache projects to fix licensing issues.

I am not involved in all the projects, however, if you find licensing issues in Apache JMeter releases, I would be glad to fix them. I doubt you will find issues with JMeter releases though.

---

The license is provided in the source package, and there is a nice header in the source header that we provide.

I'm not much into C/C++ development, so I have little idea what people would consider to be a "release of fast_float".
Do you expect they would copy both source_code.zip and fast_float.h when they depend on fast_float?
I would say that would sound strange.

For instance, Redis integrated fast_float.h as a single file: redis/redis#11884
If you expect everybody who integrates fast_float.h to select the license and include it separately, that is fine with me, however, I would say it sounds like a strange choice to expect people would select fast_float.h and a license from a source zip.

---

I brought up all my arguments before, and you are bringing up your arguments again.

@wrandelshofer , I am afraid you do not follow what I say.

Last week you said "Guava misses LICENSE file in jar, so including the license is not needed": #38 (comment)

I just proved that was an issue with Guava releases, and the upcoming releases will bundle LICENSE file just like Google Guice.

I brought up all my arguments before, and you are bringing up your arguments again.

You keep saying "wanted 'give' for the license".
English is not my native language, and I can hardly get all the 1000 meanings of give.

However, I asked that very same question at https://issues.apache.org/jira/browse/LEGAL-642, and both volunteers and lawyers (Roman Shaposhnik is V.P. Legal Affairs at the ASF: https://apache.org/foundation/#who-runs-the-asf ) say that the intention of the license is that everybody should get a readable copy of the license without any extra Internet access.

I do not see why you say "I am going in circles".
I am not going in circles. I asked Apache lawyers, and I asked Guava. Both agreed the license text should be included. That is exactly the contents of my comment #38 (comment). No way it duplicates something I have ever posited.

[wrandelshofer]

I am using now code from fast_float under the MIT License instead of the Apache 2.0 License.
I believe we agreed here on the usage of the verb 'include'.

hth