From: Vladimir Sitnikov <[email protected]> > However I still want to get basic machine-processing. For instance, machine > can tell me like: "Hey, Vlad, it looks like you are using GPL dependency in a > MIT project, and that is not typically allowed". > Ok?
But that is false. An MIT project can use a GPL dependency without any legal issue at all. An MIT project may choose to not have such a dependency, and if they’re linked together then there are additional requirements, but there is no *legal* impediment to adding a GPL dependency to an MIT project. Wheeler>So SPDX shouldn’t be trying to determine “these licenses are compatible” – it should just be recording “here are the licenses in use in this product”. > What is the purpose of having SPDX then? > It looks like you say that "license.txt is enough". I don't agree then. No, license.txt isn’t enough. For example, in many cases the license.txt file doesn’t tell you if “or later” is fine. When there are multiple licenses, there’s no obvious way from just some files to determine if you can choose between them (OR) or must comply with all (AND). Wheeler>Versions are compared using “natural sort order”, an ordering of strings in alphabetical order, except that multi-digit numbers are ordered as a single number and compared as numbers. E.g., the following is sorted using natural sort: “2.1, 2.2, 2.3, 2.20, 3.0”. > How about Artistic-1.0 vs Artistic-1.0-cl8 vs Artistic-1.0-Perl vs > Artistic-2.0? > How about LPPL-1.0 vs LPPL-1.2 vs LPPL-1.3a vs LPPL-1.3c? Those are not SPDX license identifiers. If they were, then I would say the first set are not SPDX license identifiers because the do not follow the naming conventions (the version number needs to be last, with only “-only” or “-or-later-than” postpending them). The second set is easily ordered by natural sort, and is ordered in exactly the order shown. > Once I thought declaring "license version" in SPDX standard might be a good > idea, however I don't think so anymore. I'm inclined that "later versions" > should better be manually curated. At the end of the day, the number of > licenses is very low, and we can just list all the relevant relations and > that is it. There better not be any manual curations. The “or later” is something that is stated in the license of the software being released, and since that is important license information, SDPX needs to capture it. It’s also not normally captured in the license.txt file, which is why you need something like SPDX to capture it. > 1) Version numbers sometimes include letters (e.g. 1.0-cl8), and I don't > think a general rule can be invented around that. Unfortunately, SPDX can't > influence license authors, so SPDX could easily face a license with insane > "version". I don’t think we need to borrow trouble. In normal cases, people use normal licenses with obvious version numbers. If it’s really bizarre, a special version or new name could be used. > 2) Certain licenses (e.g. CC-BY-SA 2.0) explicitly allow use of later > versions. In other words, even if software is declared as 2.0, later versions > of the license can still be used. At the present time it would include 2.0, > 2.5, 3.0, and 4.0. "Natural comparison" won't be able to express that. On the > other hand, hard-coding that equivalence is trivial. It’s more complex than that, because if some software is a released with a rider that says “only this version may be used” then I think most people would interpret that as *overriding* the text of the license. In any case, I think SPDX should simply record the license of the software being released. Determining what is allowed is a separate operation, greatly aided by having standard names for common cases. --- David A. Wheeler -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3729): https://lists.spdx.org/g/Spdx-tech/message/3729 Mute This Topic: https://lists.spdx.org/mt/32049933/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
