[License-discuss] Intimacy in open source (SSPL and AGPL)

Lawrence Rosen lrosen at rosenlaw.com
Thu Jan 24 05:01:14 UTC 2019

Bruce Perens wrote:

> Unfortunately, a lot of what the companies want to do can't be achieved as Open Source, and it is best that all sides understand that and go on.


Or understand and accept that Open Source Software is more than the GPL and recommend other approved open source licenses instead of the GPL.


This thread on license-discuss started about the license approval process at OSI. Maybe those other licenses are being proposed because the GPL doesn't do what some licensors intend. 


Other open source licenses have previously been approved that limit copyleft to the copyrighted work itself and to its derivative works. This includes OSL 3.0, which was created at the time of AGPL in the mid-2000s. Its copyleft provision applies to direct distribution and to External Deployment over a network.


OSL 3.0 doesn't rely on "Corresponding Source" definitions or meaningless terms like "software intimacy." It applies to an Original Work and to its Derivative Works.


The OSL 3.0 license was rejected by Google many years ago (as that company rejects all network copyleft licenses) and during an OSI popularity contest in which Google's opinion was important, it was taken from OSI's "recommended license" list. Thus, OSL 3.0 ended its possible consideration by the MongoDB community and many others as a possible SSPL-alternative license model. OSL 3.0 is buried on the OSI website. <https://opensource.org/licenses/OSL-3.0>  In any event, MongoDB and its software peers should not give up on creating an open source license, even if it won't be popular with large network companies or with the FSF or with Bruce Perens.


Some people here say "GPL" like it is a licensing religion. But remember, there are many other ways, through OSL-like (or perhaps LGPL-like, or MPL-like, or EPL-like) copyleft licenses, to target companies who use open source software to deliver network services (and who want to create derivative works). Perhaps we should consider the intent of the SSPL licensors and help them create or use an alternative non-GPL license?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190123/0a1187b9/attachment-0001.html>

More information about the License-discuss mailing list