Re: [License-discuss] For Public Comment: The Contribution Public License

I have two concerns about this license: 1. it seems to disallow private modification and compel disclosure. Even if this didn't fail the desert island test, it would be impossible to comply because there's no time frame within which a change must be published. Then again, publication is only neces

Re: [License-discuss] For Discussion: Cryptographic Autonomy License (CAL) Beta 2

Leaving aside the debate about user data, I think the CAL is an extremely well crafted license. But I do have some questions about the patent termination clause. The same paragraph was present in the first beta, but I just noticed it now. The CAL says (emphasis mine): If You initiate litigation *

Re: [License-discuss] For Discussion: Cryptographic Autonomy License (CAL) Beta 2

On Wed, 14 Aug 2019 at 15:33, Henrik Ingo <…> wrote: > What I think is unreasonable but still allowed by this language is to trap > operator users with the following submarine: I develop SOFTWARE and release > it under CAL. SOFTWARE is designed to store user input, but doesn't allow > to download

Re: [License-discuss] Coordinated release of security vulnerability information.

Such a clause is a good idea for copyleft licenses. Yay for license innovation! I don't think it interacts a lot with the OSD or a concept of software freedom, since it at most *delays* compliance with certain license provisions under a limited set of circumstances. However, that 90 day window is

Re: [License-discuss] MIT-Clone: Copyright notice

> > Yet, this cannot be fixed because the license prohibits it. > While the MIT license stipulates that “the above copyright notice” shall be included, I see nothing that prevents the copyright notice from being amended to list additional copyright holders. It seems to be common practice to add an

Re: [License-discuss] How can we as a community help empower authors outside license agreements?

Oh, it seems the Ethical Source definition recently changed. Those changes look good! To disambiguate, I'm referring to the [EOS] linked below, as opposed to the previous [ESD]. (Please consider adding a version number!) As far as I can see, this EOS definition is potentially compatible with the O

Re: [License-discuss] Thoughts on AAL and OSS vs FOSS

On Sun, 29 Mar 2020 at 20:41, Syed Arsalan Hussain Shah wrote: > Regarding ALL > > Josh claims that there is no repository on github > https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-March/021667.html > > But the > https://github.com/search?q=attribution+assurance

Re: [License-discuss] Invariant manifestos as an approach to expressing values / beliefs / missions for open source projects

There already are a number of licenses with a preamble, recital, or introduction, and they can be helpful. For example, the CC0 Statement of Purpose provides important background on how the device is intended to work. The GPL's preamble provides a non-legalese summary of the effect of the license,

[License-discuss] 2018 December Summary

I’ve been asked by the OSI to provide monthly summaries of the license-review and license-discuss mailing lists. Unfortunately, the large number of references is impractical in an email, so please check out the version on the OSI blog for all the links

Re: [License-discuss] Intimacy in open source

The only part of the (A)GPLv3 that mentions “intimate” communication is the definition of Corresponding Source, which clearly must include anything needed to run the software. This is a discussion of *upstream* dependencies! “Intimate data communication” is only used to explain when the GPL-covered

[License-discuss] January 2019 Summary

t only uses the library’s published API.” Weinstock points out that the distinction between internal and external APIs is not clear, for example when a fork could expose previously-internal APIs. *Corresponding Source* Lukas Atkinson notes that the GPL only talks about intimate communication as an e

[License-discuss] February 2019 Summary

In February, the License-Discuss mailing list discussed how to keep the mailing lists civil and to what degree the business model of a license submitter should be relevant. The summary can also be read online at https://opensource.org/LicenseDiscuss022019 The corresponding License-Review summary

[License-discuss] March 2019 Summary

In March, the License-Discuss mailing list discussed: - the Cryptographic Autonomy License - its interactions with the GDPR - how public performance applies to software - the License-Review process - views on tone and conduct on the list - the list’s role in the licen

[License-discuss] April 2019 Summary

In April, the License-Discuss mailing list: - talked about non-commercial licensing - discussed license revocability - answered a question about LGPL/Apache compatibility The summary can also be read online at https://opensource.org/LicenseDiscuss042019 The corresponding License-Review

[License-discuss] May 2019 Summary

Review reports, Lukas Atkinson, will not be available to continue in June and July, and may have limited availability throughout the rest of the year. If you would like to join the OSI as list editor, or know someone who might, please contact OSI General Manager Patrick Masson . The list editor work

Re: [License-discuss] Working Class License

You are clearly not trying to create an open source license because the license discriminates against certain persons: against those who you do not deem “working class”. Compare OSD #5 specifically, and the Free Software Definition more generally. Such discrimination may or may not be ethical, but

Re: [License-discuss] [License-review] Copyright on APIs

I do not think the question of whether API copyright exists is that relevant for review. Clearly, it is not in the interest of the open source community for such a right to exist, as Bruce points out. But where such a right does exist it ought to be fine for an open source license to exercise that

Re: [License-discuss] Copyright on APIs

> 2) That brings us to the second point: Patents. This point is being > largely ignored, because for a long time copyright was seen as the prime > mover As has been argued on this list, there is generally a consensus that > the OSD requires a patent grant. But that means that any "use" of a > paten