Skip to content

Latest commit

 

History

History
83 lines (45 loc) · 4.82 KB

software-libraries.md

File metadata and controls

83 lines (45 loc) · 4.82 KB
Raw

Software Libraries

The following describes the approach we adopt when referencing or including other code libraries in our applications.

It covers the use of any software code that is not directly owned by the Environment Agency but is included in a deployable application bundle.

Examples include JAR files on the classpath, Ruby Gems installed by bundler, NPM packages, JavaScript libraries referenced in web pages and code copied from Stack Overflow.

It is not intended to cover remote or entirely external services that an application makes use of, such as databases, operating systems, web services, etc.

Centrally capture your application's direct dependencies in code

For Ruby this will primarily be in your Gemfile or equivalent, for Node in your package.json file, for Java in your POM file.

This may seem like stating the obvious, but it is essential to allow the application to be checked for any issues in libraries that it depends on.

Capture your client-side dependencies too

Ensure that any client-side libraries you use are captured in your dependencies.

Again, this sounds obvious. However, not all client-side frameworks and libraries are necessarily included in your application through the likes of bundler or npm.

As an example: The GOV.UK frontend toolkit includes the GPL-licensed Nomensa accessible media player. If you link to the Nomensa player in your own client-side JavaScript then you will have to GPL all your client-side code. The toolkit's MIT licence does not cover this dependency so you will need to be aware of it.

Use a dependency checker

With all your dependencies centrally listed, an automated dependency checker can be used to manage your exposure to

  • security vulnerabilities
  • bugs
  • licensing issues

in your dependencies and all of their dependencies.

For Ruby projects (including Rails) ensure the repo is linked to

  • Hakiri - monitors Ruby apps for dependency and code security vulnerabilities.

For NodeJS projects (including Hapi) ensure the repo is linked to

  • Node Security - continuous security monitoring for your node apps.
  • David - gives an overview of your project dependencies, the version you use and the latest available, so you can quickly see what's drifting.

For Java projects we use [TBC...]

Finally all projects should be linked to

  • DependencyCI - checks for deprecated, unmaintained, unavailable, and unlicensed dependencies. Will also detail the licenses of your dependencies.

Check licences

Before adding any library to your application, check the licence and copyright that applies to it.

Any commercial licensing will need to be handled by the Commercial team. Contact Ben Sagar in the first instance, who will probably know who to start the conversation with in commercial.

Any copyleft licence conditions actually make it difficult for us to make our code as freely available as we would like so these should be avoided. Any use of a library with such a licensing condition would need legal consideration.

The most popular open source licences are listed on the OSI Licences page. Most of these licences do not conflict with the Open Government Licence that we apply to our own code, so long as the appropriate notices are included in the code. Such licences include:

  • Apache
  • BSD
  • LGPL
  • MIT

The copyleft GNU GPL, in contrast, is not compatible and should be avoided.

Check repositories

Before adding any library to your application, check where it is held and how it is maintained.

Libraries held in personal repositories with minimal maintenance histories and long outstanding issues might not be the best choice for inclusion in an application.

Where this is the case, check the licence and copyright that apply to the library, as it may be possible to copy it into our own repository. An increasing number of libraries are using Copyfree licences that facilitate this approach.

If in any doubt, consult with your team's senior developer. If you are your team's senior developer and you are still in any doubt then speak to Ben Sagar, who will probably be able to get some relevant people together to discuss it.

Create organisational GitHub repositories

If your team develops common code that could be reused in a library, or you have an idea for a project that could help in delivering digital services, request a repo under the Defra organisation.

Don't create personal repositories.

See New projects for more details about starting a new project.