In negotiating a corp-to-corp contract to rebase and upstream some of the changes around a fork of a BSD-licensed open-source software, the company I might be doing the work for wanted to get an MSA set up — Master Service Agreement.

Are there any good MSA templates that OSS contributors might want to use for working on proprietary forks of BSD-licensed OSS, that would facilitate and authorise upstreaming?

The idea here is that the fork itself may be private software (which is totally fine, since none of this is GPL), but at the same time, the whole purpose of the contract would be to rebase, re-merge, reduce, refactor, re-write and/or upstream at least some parts of their in-house changes for the ease of continued maintenance; at the same time, the company is still a for-profit business, their own codebase as a whole (some parts of it might not be related to this project at all) are not OSS and are not meant to be released to the public as-is (software stack has many components, and not all components would necessarily be eligible for OSS release); so, the MSA should be reasonable enough to not trigger their legal into thinking that their company secrets are getting leaked.

P.S. TBH, I've never really heard of an MSA, but the term seems to be very common in the consulting world. It's basically the contract that you get as an employee from the employer and are presumed to sign as-is (senior engineers, however, may always tell you that it's still open for negotiation, and things can be crossed-out or inserted). As a business, you can provide this contract on your own to the client, or have one provided by the customer for you to review. If the customer is open for you to provide your own, it may be beneficial to have the one that is more geared towards OSS and eventual release and/or upstream of some software, especially components that are non-core-subject-matter-expertise parts of their software stack. E.g., think the FreeBSD kernel improvements of Netflix, which are hardly part of their core business, hence, Netflix OpenConnect (just to make it clear, this question is not about Netflix); whereas some other components of their stack are still proprietary and are not meant for OSS release.

P.P.S. Just to make it clear — the question is not about an MSA for creating a new proprietary fork (being an OSS contributor/committer, I'm obviously looking for an MSA that would tilt into being OSS-friendly). The question is about an MSA to come and reduce the maintenance overhead of an existing proprietary fork. The main instrument of such reduction, naturally, is upstreaming and reducing the number, size, and amount of proprietary changes, in infrastructure components that are not part of core business strategy.

closed as off-topic by MadHatter, Mureinik, Bart van Ingen Schenau, amon, curiousdannii Jan 8 at 3:17

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions that ask for off-site resources, or for a recommendation of an open source service or product are off-topic because they don't directly concern an issue related to open source development. See: What's wrong with external resources questions? for more information." – Mureinik, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I'm voting to close this question as off-topic because it's about proprietary software development. – MadHatter Jan 5 at 20:30
  • @MadHatter OK, I think I wasn't clear in my question. This project I'm asking about is about upstreaming existing changes of a proprietary fork, NOT about creating a proprietary fork itself. – cnst Jan 6 at 20:46
  • You're right, that wasn't clear, and it still isn't crystal (at least, to me). Whose changes are you talking about upstreaming? Are you making paid-for changes to a client's mixed BSD/proprietary codebase, and you want a master agreement to allow you to upstream such of those changes as the client is happy to have upstreamed? Be specific about the workflow, the licensing, and about what you want. – MadHatter Jan 7 at 9:45
  • The client has issues doing maintenance of their proprietary fork of software that's not their core business; they need someone to figure out / re-merge / reduce / refactor / upstream (only if it makes sense, as not all changes would necessarily make sense for upstreaming) their proprietary changes to be more current with the latest developments upstream and to reduce the burden of having to maintain a proprietary fork. – cnst Jan 7 at 16:28
  • I've made clarifying edits to the question, and nominated for reopen. – cnst Jan 8 at 17:10