Open-source Contracting

Problem: Many institutions use open-source software but the procurement process generally restricts collaboration and participation. By adding these elements to boiler-plate contracts we hope that we can encourage better practices that support more effective engagement with the community that builds/maintains the code.

Principles

By default all work will be under an open license. Where possible adopt the license of the parent project.
External contractors will work with internal IT staff where possible to exchange knowledge & transfer responsibilities.
Any proprietary software licenses will need to give explicit approval before they can be used.
Code developed should be releasable if it serves the needs of the broader community.
Collaboration is never easy. However, if it is stated as one of the intended outcomes it is more likely to happen.
When evaluating tech solutions contractors will be encouraged to enhance existing modules, rather than build from scratch. Enhancements would be pushed upstream to improve the solutions for everyone.
Patches to existing modules will be contributed in the project's issue queue (ie. https://www.drupal.org/project/issues)
Client must be informed if any customizations to Core or Contributed Modules will cause problems with upgrades.
As with all open-source licenses, the software does not come with a guarantee or no warranty comes with it.
Vendor solution should have developing open-source products as their primary business
Selection processes should favour bids that have developers who can demonstrate that they have contributed back to the open-source community.
The software "what" (ie. Drupal) is often dealt with in procurement, without mentioning the "how" (with open-source approaches). Make sure both are addressed.

Contribution vs Contracting

There are many open-source projects which take on contributions and so therefore need an agreement for the license of those contributions. The Fedora Project of RedHat came up with this Fedora Project Contributor Agreement as a model.

Many contracts however are for larger pieces of work and not discrete code checkins that are tied to an already existing open-source project.

Sample language

All software we develop through this contract will be the copyright of [Company X] and licensed under the GNU Public License (GPL) to ensure that the software may be freely used, modified and distributed. Any documentation provided by [Company X] will be similarly licensed under the Creative Commons Share-alike License.

Client accepts and agrees that all developed software will automatically be licensed under the most permissive open license used by software it is integrated into and can be freely distributable. Client acknowledges that they are receiving a substantial cost savings through Vendors use of open source software and this recriprocal license is in clients best interests overall.

The works authored by the vendor in the context of the present agreement will be licensed under the [license].

marctjones / open-source-contracting Goto Github PK