|
Re: Deprecate Entessa in favour of Apache-1.1?
Karsten Klein
How do we deal with the slightly different obligation?
I would argue that this is not the same. - Regards, Karsten metaeffekt GmbH Firmensitz: Renettenweg 6/1, 69124 Heidelberg Registergericht: Amtsgericht Mannheim, HRB 725313 Geschäftsführer: Karsten Klein USt.-IdNr.: DE307084554 Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht gestattet. Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle Selbstbestimmung und übermittelt Informationen ausschließlich auf der Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH <http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf>. On 12.03.20, 13:00, "Matija Šuklje" <Spdx-legal@... on behalf of matija@...> wrote: On sreda, 11. marec 2020 22:47:40 CET, J Lovejoy wrote: > And SPDX License List endeavored to add any and all licenses > ever approved by OSI in the early days, so… here we are. We > didn’t have the matching guidelines established back then, I > don’t think, but in any case, it has been on the OSI approved > list for a very long time (as in before SPDX License List birth, > I believe). OSI considers it a “vanity” license, in so many > words - which is probably why we don’t have any markup on the > acknowledgment statement. I suspected as such, yes. I did check the OSI list when I stumbled upon it. > Would a Note explaining this suffice? Ideally I would like to have it deprecated (also on OSI), but note would work as well. Thanks for looking into this. I didn’t want to open an issue right away, as I suspected it was some legacy thing. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: SPDX License List license inclusion guidelines
J Lovejoy
Philippe,
toggle quoted messageShow quoted text
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 <iamwillbar@...> wrote:
|
|
|
|
Re: SPDX License List license inclusion guidelines
William Bartholomew
Philippe,
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: SPDX License List license inclusion guidelines
Philippe Ombredanne
Hi Jilayne:
On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote: I’m sending this to both the legal and general mailing lists to ensureOn 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
|
|
|
|
SPDX License List license inclusion guidelines
J Lovejoy
Hi all,
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 We are looking to provide another two weeks for review and comment and then finalize and publish this. Please do comment either on the PR, the issue below or the legal team mailing list. (including +1 if you think it’s all good!) The issue where some of the discussion has taken place is here: https://github.com/spdx/license-list-XML/issues/925 Thanks! Jilayne SPDX legal team co-lead
|
|
|
|
Re: Deprecate Entessa in favour of Apache-1.1?
On sreda, 11. marec 2020 22:47:40 CET, J Lovejoy wrote:
And SPDX License List endeavored to add any and all licenses ever approved by OSI in the early days, so… here we are. We didn’t have the matching guidelines established back then, I don’t think, but in any case, it has been on the OSI approved list for a very long time (as in before SPDX License List birth, I believe). OSI considers it a “vanity” license, in so many words - which is probably why we don’t have any markup on the acknowledgment statement.I suspected as such, yes. I did check the OSI list when I stumbled upon it. Would a Note explaining this suffice?Ideally I would like to have it deprecated (also on OSI), but note would work as well. Thanks for looking into this. I didn’t want to open an issue right away, as I suspected it was some legacy thing. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: Deprecate Entessa in favour of Apache-1.1?
J Lovejoy
Hi Matija,
toggle quoted messageShow quoted text
Hmm… I thought we had put a Note in Entessa explaining this, but apparently not. Perhaps there is another case like this that I am thinking of: The reason we have Entessa on the SPDX License List is because OSI approved it as a separate license. See https://opensource.org/licenses/Entessa And SPDX License List endeavored to add any and all licenses ever approved by OSI in the early days, so… here we are. We didn’t have the matching guidelines established back then, I don’t think, but in any case, it has been on the OSI approved list for a very long time (as in before SPDX License List birth, I believe). OSI considers it a “vanity” license, in so many words - which is probably why we don’t have any markup on the acknowledgment statement. Would a Note explaining this suffice? Jilayne
|
|
|
|
Deprecate Entessa in favour of Apache-1.1?
Hi,
I just stumbled upon Entessa for the first time in real life, and upon checking it with both FOSSology/Monk and SPDX License Diff, I can’t see how it qualifies as a separate license, instead of a variation of Apache-1.1. Is it possible to deprecate it in favour of the Apache-1.1 template? The only difference that seems to be outside of the current Apache-1.1 template is the wording: “This product includes open source software”(Entessa) instead of only: “This product includes software” (Apache-1.1) relevant old issue: https://github.com/spdx/license-list-XML/issues/840 cheers, Matija Šuklje -- gsm: +386 41 849 552 www: http://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: Meeting tomorrow, Mar. 12
Steve Winslow
Sounds great, thank you Jilayne! Looking forward to discussing on the call.
On Wed, Mar 11, 2020 at 12:31 PM J Lovejoy <opensource@...> wrote:
|
|
|
|
Re: Meeting tomorrow, Mar. 12
J Lovejoy
Hi all,
toggle quoted messageShow quoted text
I just merged that PR - we had a bunch of comments and figured it’d be easier to have a clean iteration to look at for the meeting. Please see: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md README and some aspects of CONTRIBUTING have also seen updates, so please have a look and provide comments or suggestions in the repo. Thanks, Jilayne
|
|
|
|
Meeting tomorrow, Mar. 12
Steve Winslow
Hello all, the next regularly-scheduled SPDX legal team meeting will be tomorrow, Thursday, Mar. 12 at 9AM PDT / noon EDT. The primary agenda item will be to discuss, and ideally finalize for now, the license inclusion principles update at https://github.com/spdx/license-list-XML/pull/985. We will also discuss whether to push out the 3.9 release deadline to incorporate this and some of the relevant related license requests. = = = = = Join Zoom Meeting https://zoom.us/j/611416785 Meeting ID: 611 416 785 One tap mobile +16465588656,,611416785# US (New York) +16699006833,,611416785# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 6833 US (San Jose) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 647 558 0588 Canada 855 703 8985 Canada Toll-free Meeting ID: 611 416 785 Find your local number: https://zoom.us/u/aceZFvRyln -- Steve Winslow Director of Strategic Programs The Linux Foundation
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
On sreda, 11. marec 2020 09:42:15 CET, michael.kaelbling@... wrote:
I would say that CCM would be the best way to go right now, as David Wheeler already explained in detail before. Unless someone knows of a better commonly used/tested suggestion for a public domain mark. I also agree with David that it would make sense to include CCM into the SPDX License List and finally deprecate CC-PDDC. https://creativecommons.org/share-your-work/public-domain/pdm/ Until then you can still create a SPDX-compliant name for it – e.g. `LicenseRef-CCM` and use that. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
michael.kaelbling@...
yes to your clarification, Matija -- I was talking about my/our own works.
However ... What about cases that have been adjudged by the court as uncopyrightable or public domain contrary to a claim within the source? What would one expect to see in the License-Identifier, LicenseConcluded, and LicenseComment fields? Would one expect an Annotation?
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
Richard Fontana
On Tue, Mar 10, 2020 at 9:58 AM Carmen Bianca Bakker
<carmenbianca@...> wrote: Except, apparently, if you're a conservative lawyer at certain U.S. federal government agencies! Richard
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
Karsten Klein
Hi there,
just our two cents... When looking at a linux distribution we recently ran into the following package text: "The contents of this package are ineligible for copyright protection." We decided to identify this explicitly as license 'none'. It would be great to have an SPDX-ID for such a case. A tool that matches this text can identify the non-existent license with such id. One would also be able to mark the own files (i.e. config files) with such an identifier. Connecting such a case to the public domain appears inappropriate to us. It's not quite what the author intended to say. Regards, Karsten
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
Mark D Baushke <mdb@...>
Hi Matija,
Wouldn't that have been lapsus digiti rather than lapsus calami? I will admit that my latin is mostly self-taught. But a slip of the finger might be a miskeying rather than the pen, unless you were scribing with a digital pen or something... Curious, -- Mark
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
On torek, 10. marec 2020 14:55:17 CET, Carmen Bianca Bakker wrote:
You’re correct. Lapsus calami due to writing before finishing my morning tea. CC0-1.0 marks it that whatever that thing is, its author either waives all their rights, or if they can’t do that (e.g. in most of EU) gives you a very permissive right and promisses not to enforce any of the rights that they could not waive. Which is as close to something being in public domain as possible.1) if it is not copyrightable, you have clearly marked it as such, and the SPDX-FileCopyright tag is merely used as a contact for anyone requiring extra infoI would counter that marking something as CC0-1.0 does not clearly As such, ad 1) I meant that if you mark something as CC0-1.0 and that thing is not copyrightable, you have clearly communicated to the public that they should act as if it is in public domain – regardless whether a) it trully is (i.e. uncopyrigtable from the start) rendering the CC0 moot, you b) hereby waived your rights, or c) you hereby gave a very permissive license. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
Carmen Bianca Bakker
Je mar, 2020-03-10 je 10:04 +0100, Matija Šuklje skribis:
If so, I would still suggest marking it with CC0-1.0 as explained in REUSE:I would counter that marking something as CC0-1.0 does not clearly communicate something as uncopyrightable. Even so, slapping a license on an uncopyrightable thing doesn't get you in any legal trouble, so it's fine. Kindly, Carmen
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
Just to clarify … your question is solely about marking your own works – i.e. stuff that if it were copyrightable, you would hold copyright it?
If so, I would still suggest marking it with CC0-1.0 as explained in REUSE: 1) if it is not copyrightable, you have clearly marked it as such, and the SPDX-FileCopyright tag is merely used as a contact for anyone requiring extra info 2) even if it can be deemed copyrightable, you have released it as CC0-1.0, and the SPDX-FileCopyright tag fulfils all its roles. If you planning to mark files that other people (would) hold copyright in (if they were copyrightable), than that is different and more touchy question. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@...
|
|
|
|
Re: Tagging of UNCOPYRIGHTABLE material
michael.kaelbling@...
I worry that I did not describe my use-case well. Let me try again.
Rule: in my organization, all our OSS must have have explicit clearance based on SPDX-License-Identifier and SPDX-FileCopyrightText tags. Our OSS should pass REUSE.software scans without complaints of missing copyright information, etc. If this automatic scan fails, then humans have to get involved, which is annoying and time-consuming for each release. Therefore, I was looking for the way to add "copyright" and licensing information for uncopyrightable materials that is both correct and passes automatic scans. I definitely want to avoid very dangerous propositions! I perhaps naively thought that claiming an unenforceable copyright was even more dangerous than claiming that something is uncopyrightable. I have no legal training and got a bit worried after browsing https://en.wikipedia.org/wiki/Copyfraud which talks of fines for "false claims of copyright". The chances of losing such a suit would be negligible, but a new avenue for a nuisance lawsuit would be opened -- that was my thinking. My "proposal" of an UNCOPYRIGHTABLE keyword, which I abandon, aimed to cover the special case of licensing material that could not be copyrighted. I have learned that the CC Public Domain Mark can be used for the FileCopyrightText and that something like CC-PDDC can be used for the License-Identifier, with a corresponding text file in LICENSES/...
|
|
|