Do you have a similar paragraph?

No. Article 16 begins with a definition of “intellectual property”; the string “GNU” doesn't appear in the document.

Just a few notes since I've dealt with this issue at SLAC:

Foreword: The following is general SLAC policy and not necessarily applicable to the SLAC+AURA MoU (or whatever it is), also IANAL IANAL IANAL:

SLAC is fine with modified BSD (as is, obviously LBNL we just took their license wholesale). It's probably fine with Apache. It's generally not okay with GPL though the GPL stuff was negotiated a long time ago so it's fine. So moving to BSD/Apache is fine for us at SLAC. SLAC's contract with the government is actually a bit strict on this, but the reason why GPL generally isn't okay is that any other branch of the US Government (cough, defense, cough) must have ability to modify source code and redistribute without violating the license terms. In some cases, SLAC code might fall under reporting to ESTSC, but that's not a big deal and doesn't really apply to us. In general, SLAC people are able to contribute to GPL projects, but SLAC projects shouldn't be GPL. It's a fuzzy line, we could get our Tech Transfer guy to help out if necessary.

DESC is moving towards modified BSD, after SLAC's lead primarily, since most people are SLAC people.

In general, it's fine to link against GPL code and release your code so long as your code is GPL compatible (Apache V2, MIT, Modified BSD). What you can't do is distribute the LSST Stack as a blob with GPL code underneath and keep your code super secret (generally true, except for cases with GPL+Java+Classpath exceptions, etc...)

https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean

It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program.

I believe the premise is that, Apache V2/MIT/Modified BSD are so permissive that you can actually distribute them under a giant GPL-ish blob (effectively a dual-license). Modifications to any GPL code must be licensed under GPL though. This also means that our official release are, in fact, GPL releases though internally the code may be something else.

Coming back to mysqlclient, for example. SQLAlchemy may use mysqlclient underneath but all SQLAlchemy code is MIT. pandas is BSD and uses sqlalchemy and may use mysqlcient. Distributing a library with both sqlalchemy and mysqlclient would require that library to be licensed under GPL but the code inside it could also be any other license. Distributing that library with a different driver (i.e. not mysqlcient) wouldn't necessitate GPL. Choosing not to distribute any driver would be best, let the user decide. Of course, we have eups so that's not an option (but maybe it is?)

IMO the patent exclusion only really matters if we are going to actually apply for patents in the algorithms, but it might be nice to be Apache V2 just so institution comes a long and tries to assert a patent on some image algorithm. In any case, all it really means is that end users don't have to worry about an institution coming along and bullying them for using the LSST stack with patent 123.

Again, IANAL IANAL IANAL.

This issue is being addressed in the context of the LSST Software Release Management Policy document: ldm-672.lsst.io

From the DM developer guide: "
All source code created by LSST DM is publicly-available open source. As such, LSST DM code must carry an Open Source Initiative (OSI)-approved license."

I believe this covers the original goal of this ticket, to be enable contributions to the LSST code base from the community.

Any future issues/discussion on this topic should reference: LSST Software Release Management Policy document: ldm-672.lsst.io

It doesn't really cover the issue of copyright assignment. If you allow contributions from outside they could still own copyright so you will need their permission if you ever want to change license in the future.