Philippe, Did you actually read the proposed draft? It’s has more clarity as to key and practical aspects we already look for (e.g., stable license text) and relaxes the must-be-free requirement we have been operating under.
And what William said. I’m not sure what your specific concern is. Jilayne Sent from my phone, please excuse brevity and typographical errors. > On Mar 12, 2020, at 3:30 PM, William Bartholomew <iamwill...@github.com> > wrote: > > Philippe, > > I agree with you but I think it is orthogonal, the SPDX license inclusion > guidelines would govern what goes in the official SPDX license namespace, it > does not restrict what could go into other license namespaces (which would be > implemented by the other proposal currently being discussed). > > William > >> On 3/12/20 2:23 PM, Philippe Ombredanne wrote: >> Hi Jilayne: >> >>> On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensou...@jilayne.com> wrote: >>> I’m sending this to both the legal and general mailing lists to ensure >>> greatest visibility. The legal team has come up with a final draft of the >>> license inclusion guidelines based on various conversations and feedback >>> over the past 8 months of intermittent discussion. >>> The pull request representing this draft is located here: >>> https://github.com/spdx/license-list-XML/pull/990 >> On January 31st a compliance tooling meeting and hackathon took place >> in Brussels before FOSDEM [1]. One of the session topics was SPDX. >> Everyone there agreed that SPDX license inclusion criteria should be >> relaxed. >> >> Adding more restrictions and filters is IMHO counterproductive in several >> ways: >> - it requires more work to apply these restrictions and filters >> - more work means fewer licenses are added >> - as a shared "vocabulary" the utility function of the license list is >> directly related to the number of "words" we can use. >> >> Restricting the number of words in the license vocabulary only means >> that these words cannot be used in shared conversation about licenses. >> >> But these licenses still exist, so the restrictions impact mostly the >> usefulness and expressiveness of SPDX, especially in the more common >> cases where license expressions are used without an SPDX document. >> >> This could increasingly make the SPDX License list irrelevant if it is >> missing important license vocabulary. The existing and proposed license >> inclusion criteria seem counterproductive and likely to subtract value from >> SPDX. >> >> The community does not need SPDX to police or enforce OSS license >> "purity" via the license list. Instead there should be fewer barriers >> to adding new licenses to the list in order to optimize the utility of >> the SPDX license list and the number of common licenses SPDX >> expressions can deal with. >> >> Since SPDX does not interpret license conditions, the inclusion >> guidelines should be loosened to include commonly-used and public >> licenses without an OSS litmus test (e.g. free proprietary licenses). >> This will become more important for SPDX as more organizations become >> more focused on compliance and are looking for a way to account for >> all licenses detected from scans or other analysis. >> >> [1] >> https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit# >> -- >> Cordially >> Philippe Ombredanne >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2759): https://lists.spdx.org/g/Spdx-legal/message/2759 Mute This Topic: https://lists.spdx.org/mt/71910791/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
