On 1/16/23 22:09, Neal Gompa wrote: > On Mon, Jan 16, 2023 at 2:04 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: >> >> On Mon, Jan 16, 2023 at 2:47 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> >>> It's fine that SPDX doesn't offer this guidance, but Fedora as a >>> distributor *needs* it. Fedora provided very valuable guidance with >>> its "will-it-blend" chart and offering explicit interpretation. It was >>> useful for both packagers and upstreams to figure out what they can >>> and cannot do. Eliminating that guidance is creating problems now >>> because with the transition to SPDX, you're effectively requiring >>> everyone to re-evaluate all packages for their licensing and document >>> it without any real ability to figure out if it makes any sense >>> anymore. >> >> In my opinion, the default assumption (and I think we should say this >> in documentation) should be that if the licenses are all >> Fedora-allowed, a particular combination of licenses embodied in a >> particular package is okay. If there are specific concerns about some >> combination of Fedora-allowed licenses that package maintainers or >> others want to raise, they can do so and this will be investigated. >> Over the past nearly 15 years, most of them under the previous >> documentation/guidance/process regime, my impression has been that >> such concerns were raised only in very rare cases, typically involving >> a well known upstream issue. >> > > I suspect part of the reason is because Tom Callaway proactively > documented compatibility as part of incorporating licenses. That > eliminated a large portion of the need to ask. Now that the > information is gone, people are asking. :) > >> The migration to SPDX has been under way now for ~five months and >> Benson's issue is the first time I'm aware of that anyone has brought >> up a license compatibility issue in a Fedora package during that time >> period, FWIW. Some developers are aware of this, especially for packages made by people backed by large corporations. However, for many small projects, this is more difficult. When good practice has been followed and license information of included software is available, producing a warning of possible license incompatibility and asking reviewers to check it is helpful. The aim should be a best efforts check when license incompatibilities are known. >> >> I think you've raised an interesting philosophical question, which is >> whether FOSS licensing is supposed to "make sense" beyond the mere >> juxtaposition of the various licenses that apply to some set of >> binaries or source files. I have some preliminary thoughts on this but >> will have to think about it some more. :) >> > > I'd argue that it's supposed to make sense, or otherwise people can't > reasonably use it. Part of the value of a distribution is sorting this > mess out for people. :) > > Which licenses with SPDX identifiers can be combined is certainly an open research area. It does not make sense to combine all open licenses. This should be clearly stated in the packaging guidelines so that reviewers and packagers know to check this. For commonly used licenses, license compatibilities have likely been determined and suggestions can be made by software without an offer of support for legal representation in the case of a law suit should be made. A clause similar to MIT license: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. on the output of the compatibility check could be added. If one is using software commercially and wants to ensure they are legally compliant, enterprise support is a reasonable way to get legal advice. _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
