Why reciprocal license restrictions in "Guide for Using Open Source Software"?

[kfogel]

In the Guide for Using Open Source Software, in the section Verify Open Source Software License, it says that applications that are going to be modified can't use a "strong reciprocal" license if they're web apps nor any reciprocal license if they're going to be distributed externally.

This raises several questions/issues:

• In general, one can never predict with certainty whether one will have to make modifications to an open source software application one is deploying. One may start out intending to make no modifications, and discover one year down the road that modifications are necessary (furthermore, one cannot predict whether those modifications would be of the sort that should be submitted upstream, rather than merely published, and whether upstream would accept them if they were submitted).

• Since the Guide for Publishing Open Source Code says that work should happen in the open by default, in principle all modifications are intended for external distribution anyway (except for those which meet one of the rare exception conditions stated, but those do not concern us here).

What this all adds up to is that the Guide for Using Open Source Software effectively prohibits GC from using any reciprocally-licensed (i.e., copyleft / GPL'd) software at all.

Presumably this was not the intent?

What is the purpose of discouraging contact with reciprocal licenses, as specified in points 3 and 4 of the section "Verify Open Source Software Licence", anyway? Or am I just misreading the text somehow?

FWIW, the publication guide (a separate document) does not similarly discourage use of reciprocal licenses -- it just lists them as an option along with other types of licenses. Unless I've misunderstood something, the interaction between those two policies means that GC could easily end up publishing open source software that GC itself cannot re-use.

[smellems]

It's supposed to represent a decision tree. So you only get to points 3 and 4 if you answer Yes to 2. Are there any reasons that would prevent the release of the modified source code?. In most cases you should be able to answer No and use any OSI approved licence or FSF free software licence.

Would the current situation or your department policies prevent publication of source code of modified OSS? If yes, and it's a Web application, don't use strong reciprocal (AGPL). If yes, and your going to be "distributing" the resulting software, use only permissive licences.

[gcharest]

Yes, I think we need to work some kind of graphics... The decision tree is meant to go from 80% scenarios you should be able to use OSS under any open source licence and then break out the remaining 20% scenarios. Le mar. 7 mai 2019 07 h 55, Sébastien Lemay <[email protected]> a écrit :

…

It's supposed to represent a decision tree. So you only get to points 3 and 4 if you answer Yes to 2. Are there any reasons that would prevent the release of the modified source code?. In most cases you should be able to answer No. Would the current situation or your department policies prevent publication of source code of modified OSS? If yes, and it's a Web application, don't use strong reciprocal (AGPL). If yes, and your going to be "distributing" the resulting software, use only permissive licences. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAM4TZPHVH6SS6KWJPODBCLPUFU3JANCNFSM4HLCJCUQ> .

[gcharest]

We probably should add some nuance as well to help teams realize what would constitute a reason that the source code could not be published, linking to the conditions we mentioned in the white paper and publishing OSS.

There's really little reason why we should modify existing OSS and introduce code that shouldn't be released itself.

It may sound overkill, but we may need to add some additional disambiguation around difference of source code and software deployed. I still have to explain the difference to people I should not... (That's not just government by the way - it's a bit scary at times)

[kfogel]

Ah, I see now how it represents a decision tree, but that wasn't clear to me when I first read it through, FWIW. A diagram, or maybe just some more clarifications in the wording, would be great. (For example, what @gcharest said here was immensely clarifying.)

[gcharest]

Absolutely! Yes, definitely need graphics... Also, clearer introduction might help in the meantime!

[ShadeWyrm]

@gcharest / @kfogel / @smellems - hi all! Can I get your feedback on the above, and if you feel it more clearly explains the thought process/flow?

[smellems]

This is nice, but its not about reciprocal vs permissive, I think.

Its about what OSS licences are acceptable for use by the GC. Not releasing or even contributing back. For example but we recommend permissive. We can't recommend in this case because we're not picking the license of OSS projects being used only saying if it can be used.

I think it should start with

When using OSS without modifications, all software licensed under an OSI approved license or a FSF free software licence is considered OSS and can be used.

Same for when you will make modifications and can share them.

If you can't share modifications the follow the questions..

For the yellow boxes I propose the following changes to be less about permissive vs reciprocal (from the top)

1. Source code should be shared if it does not include the things it should not include.
2. Consider contributing back to upstream communities.
3. Strong reciprocal licences consider access through a network (like the Internet) distribution and the modified source code must be made available.
4. When distributing modified versions of OSS using reciprocal licences, the modified source code must be made available.

[gcharest]

Ah yes, the decision tree was more about the software used inbound. A decision tree should probably be done for licences applied to GC projects 🤔

For example, see this graphic from Heather Meeker's book Open (Source) for Business:

[gcharest]

In other words, if you use without modifications (or any derivative work), you shouldn't be worried about from the OSS licence perspective in most cases as long as it is a recognized OSS licence.

However, if you do modify it, you have additional considerations to keep in mind, mainly that:

Inbound rights must not exceed outbound rights.

[ShadeWyrm]

How is this in comparison?