Update license SPDX expression for Zlib code in src/combine.rs

[musicinmybrain]

The Problem

The file src/combine.rs contains some code that is Zlib-licensed,

crc-fast-rust/src/combine.rs

Lines 10 to 34 in 3a853cc

	/* crccomb.c -- generalized combination of CRCs
	* Copyright (C) 2015 Mark Adler
	* Version 1.1 29 Apr 2015 Mark Adler
	*/
	/*
	This software is provided 'as-is', without any express or implied
	warranty. In no event will the author be held liable for any damages
	arising from the use of this software.
	Permission is granted to anyone to use this software for any purpose,
	including commercial applications, and to alter it and redistribute it
	freely, subject to the following restrictions:
	1. The origin of this software must not be misrepresented; you must not
	claim that you wrote the original software. If you use this software
	in a product, an acknowledgment in the product documentation would be
	appreciated but is not required.
	2. Altered source versions must be plainly marked as such, and must not be
	misrepresented as being the original software.
	3. This notice may not be removed or altered from any source distribution.
	Mark Adler
	madler@alumni.caltech.edu
	*/

but the license metadata implies the entire library is MIT OR Apache-2.0.

crc-fast-rust/Cargo.toml

Line 6 in 3a853cc

license = "MIT OR Apache-2.0"

The Solution

Change the project license SPDX expression from MIT OR Apache-2.0 to (MIT OR Apache-2.0) AND Zlib to more accurately reflect the applicable licenses.

Changes

One could also choose to add a separate license file for the Zlib terms from the comment in src/combine.rs. In general, this practice is useful, particularly for licenses (like MIT and Apache-2.0) that impose a requirement to include the license text with binary distributions. It’s very difficult for users and redistributors to do that when the license text is only in the source code. In this case, I haven’t bothered, largely because the Zlib license only appears to require the license text to be preserved in source distributions.

Planned version bump

I don’t think this is really my choice, is it?

• Which: [ MAJOR, MINOR, PATCH ]
• Why: [ non-breaking bug fix, doc change, test coverage, formatting, debugging, profiling, security fix, internal change, experimental change, non-breaking new functionality, breaking change, etc ]

Links

N/A

Notes

N/A

[ @mentions for anyone who should be alerted to this PR ]

[ Please assign reviewers if you want someone specific to review this ]

[ Please do not forget to add labels specific to this PR ]