Trim a paragraph from the software license policy.

[jhb]

Summary

This bullet point seeks to make a broader point about the need for
compelling reasons for importing newer versions of 3rd party software
beyond just a version bump.

However, the license policy for source is not an ideal place to make
this point and it can be read as requiring core to validate updates to
any GPLv3 software in ports due to the surrounding context.

Reported by: pauamma

[jhb]

This is the only mention of "ports" in a policy that is otherwise solely about software licenses in the source tree. If we want to have a separate policy with some guidelines on how to deal with licensing in the ports tree (e.g. the risks of moving a GPLv2 library to GPLv3 if it has downstream ports that are GPLv2 only), then I think that belongs in a separate policy doc from this one.

If we want to say as a general rule that we want to discourage updating the version of 3rd party software in both base and ports merely for a version bump, then that is also something I think is orthogonal to this license policy and is better documented elsewhere. In practice though I think ports generally strive to stay with the latest versions of 3rd party software, so I'm not quite sure that such a rule would make much sense in ports. I'm also not entirely sure it even makes much sense in source. It behooves us to stay up to date with LLVM for example even if we are no longer getting big features (like support for new architectures) with new LLVM releases. Staying current with such a fast-moving upstream is itself useful and I think a counterexample of sorts to this rule.

[emaste]

e.g. the risks of moving a GPLv2 library to GPLv3 if it has downstream ports that are GPLv2 only

This seems like a very specific corner case, but perhaps the general rule could be to exercise caution when a software update includes a license change. A library in ports that changed from MIT to GPL (say) should also receive additional scrutiny.

[pauamma_gundo.com]

This answers my concern inasmuch as regards this document. I agree with the need to document how to deal with this wrt ports elsewhere. Would the Porter's Handbook be a good place?

[grog]

As it stands, the clause represents a layering violation, so it should go. But is that enough? It seems that the entire document requires reworking. We have similar wording for Apache licenses, for example. Can we get input (read: work) from the doc team?

[imp]

This likely belongs in something more specific for the ports tree.

[jhb]

In D38131#866188, @pauamma wrote:

This answers my concern inasmuch as regards this document. I agree with the need to document how to deal with this wrt ports elsewhere. Would the Porter's Handbook be a good place?

I suspect the porters handbook would be the right place, yes, and portmgr probably needs to review specific commits to add license guidelines.

[jhb]

In D38131#866201, @grog wrote:

As it stands, the clause represents a layering violation, so it should go. But is that enough? It seems that the entire document requires reworking. We have similar wording for Apache licenses, for example. Can we get input (read: work) from the doc team?

I don't think we need to rework the entire document to trim this point. I think that we might need new language in a different place to describe a suitable policy for ports, but that would be its own review and discussion.

[rene]

I know tabthorpe@ (he has retired since a few years) set up the license framework within the tree, and that eadler@ and perhaps adamw@ (iirc) also did some work there.