Hey Steve, I think you've managed to make my points on why we should. :)
To your first point, with how both BUSL and MPL work, it absolutely requires some way to represent that one license is being substituted for another while indicating that it isn't the base license. Especially if the target license documentation files do not exist in the repository. One of the things that SPDX promotes is the idea of "accurate" identification of licensing, including no "fuzzy" license matching. If that *wasn't* the case, I don't know why we have so many BSD and MIT flavors being categorized with separate identifiers. To your second point, that's not really the case. It is only GPL because the BUSL says so. Therefore, the base license needs to be represented. The complexity of the BUSL makes this uglier because the change representation should also probably be represented somehow as mixtures could come into existence and it would matter what the conversion targets and when they happen are... which makes me think I've talked myself into it being more complex by adding an "after" operator (e.g. "BUSL-1.1 as GPL-3.0-or-later after 2024-08-01" in the example I gave in my original post). This data is important and needs to be represented somehow, because BUSL is still the "real" license, even after the automatic conversion. The philosophy of SPDX and the reality of BUSL means that we do not have an adequate way of presenting the license. On Wed, Jul 17, 2024 at 11:31 AM Steve Winslow via lists.spdx.org <[email protected]> wrote: > > Hi Neal, thanks for reaching out on this. > > My initial quick reaction is that I would _not_ be in favor of modifying the > license expression syntax for this use case. I have two primary reasons for > this: > > 1. Adding a new operator means that everyone interacting with (or at least, > parsing / processing) SPDX license expressions has to deal with it, interpret > it, etc., and update their code to handle the possible new expressions. I > view it as requiring an _exceptionally_ high bar to modify the license > expression syntax. I wouldn’t view BUSL-1.1’s choices as triggering this. > > 2. From an SPDX license expression syntax perspective, if the applicable > license is no longer BUSL-1.1 and is now GPL-2.0-or-later for a specific > package of code, then I would expect its SPDX license expression would now > be: GPL-2.0-or-later. The question of “what does BUSL-1.1 require in terms of > e.g. modifications to other license notices,” etc., seems to me to be > unrelated to “what license expression should be used for what is now licensed > under GPL.” > > Based on those points, I don’t think adding an “AS” operator would be > advisable here. > > And in any case, someone who doesn’t agree with #2 above and feels that they > really need to handle BUSL-1.1’s “change license” mechanism in a different > way can always use a LicenseRef- to represent their custom identifier. > > I appreciate your broader point that BUSL-1.1 introduces problems and > complexities when it comes to compliance. I wish I could fix those. ;-) But > I wouldn’t be in favor of adding an “AS” operator as a piece of solving that. > > Open as always to hearing others’ thoughts. > > Steve > > > On Jul 17, 2024, at 11:09 AM, Neal Gompa via lists.spdx.org > > <[email protected]> wrote: > > > > Hey all, > > > > In Fedora, we've got a curious case that has come up: a packager wants > > to ship software that has changed licenses based on time[1]. > > Specifically, MariaDB's MaxScale has a version of it that has reached > > its change date from BUSL-1.1 to GPL-2.0-or-later. The problem is, of > > course, that we don't have a way of presenting that information and > > BUSL-1.1 itself is not permitted. With the interesting exception of > > MPL-2.0 (which has a license conversion clause), it's fairly rare for > > something like this to exist in FOSS licenses. > > > > However, the BUSL has been around for a few years now, and things that > > people want are starting to become available under FOSS licenses that > > the BUSL copyright owner set them to. While if the copyright holder is > > still active, they may be able to update the sources to switch the > > license, if they aren't around, then we still need a way to represent > > it. I theorized that it might make sense to add the "as" operand for > > this purpose[2]. > > > > For example, if a package foo by company baz has BUSL-1.1 and sets the > > change date to 2024-08-01 to convert to GPL-3.0-or-later, but the > > company goes under on 2024-07-31, we don't really have a way to > > represent this when it becomes fine to ship regardless. > > > > I would propose that we add the following stanza mechanism: "BUSL-1.1 > > as <target-license>", where "<target-license>" is the SPDX identifier > > for the license terms we are actually using. This would also allow us > > to represent when someone has opted to use MPL-2.0 as one of the GNU > > licenses, as is permitted under section 3.3 of the license. > > > > For the MaxScale case, it would be "BUSL-1.1 as GPL-2.0-or-later". > > > > What do you folks think? > > > > [1]: > > https://lists.fedoraproject.org/archives/list/[email protected]/thread/3O4GMABVWVRMAHNKALKPJJ53PMVYSNQS/ > > [2]: > > https://lists.fedoraproject.org/archives/list/[email protected]/message/Y4Y2NCCVHELSSHS2M663VLUJENWWSEGL/ > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > > > > > > > > > > > > > > > -- 真実はいつも一つ！/ Always, there's only one truth! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1887): https://lists.spdx.org/g/spdx/message/1887 Mute This Topic: https://lists.spdx.org/mt/107317043/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
