I thought this topic (which started in a different thread) should have its own topic:
Dear Colleague,
Following on from NHS England’s Open Source / Code 4 Health initiative Kanteron Systems have now made available, license free to the NHS, their PACS, digital pathology, genomics, pharmacogenomics, biosensor and analytics platform.
Currently the repository contains code only; I would appreciate any feedback you may have around how useful this is.
Access to the repository is via registration using an NHS e-mail address (either nhs.net or a hospital address): www.kanteron.com/NHS2
Regards, Shawn
Shawn Larson DCR(R) MSc
Senior Project Manager, Provider Support & Integration
Health & Social Care Information Centre
07920 785 915 shawn.larson@nhs.net / shawn.larson@hscic.gov.uk
From Shawn Larson (NHS Digital), to clarify the Kanteron and NHS Open Source issue -
The agreement with Kanteron is an NHS code fork via an NHS wide license, so it’s open source within the NHS and UK universities, hence the requirement for validated ID.
All derivatives and plug-ins made with this code, or under association with this OpenPACS initiative, will also be license free within the NHS, with the option via UKTI to export NHS IP to recover revenue.
Laura Sato
NHS Digital
Interesting! I hope some of the OHH community will be able to try out the platform and see what it can do.
The agreement with Kanteron is an NHS code fork via an NHS wide license, so it’s open source within the NHS and UK universities, hence the requirement for validated ID.
If the license terms of the open source version state that it can only be used within the NHS and UK Universities, then that should be sufficient, shouldn’t it? The code could be on a public repo in GitHub, ie ‘properly open source’, it doesn’t need to have restricted access, because the allowed uses are covered in the license?
I’m the CEO of Kanteron Systems. Sorry for the late reply, I only saw this today.
While you’re “technically right” and like you said, it could be a public repo, we offer both access to the code, and professional services associated with that code. As a company, we are bound by restrictions and regulations (ISO, CE, Insurance, etc) beyond code license. Therefore we prefer to be able to identify every access and modification with proper user management (no “alias” or “unidentified” users).
Having said that, so far we have not (nor we will ever as long as the agreement is in place) rejected access to anyone requesting access from the NHS. So in practical terms, it makes absolutely no difference. As a matter of fact, a completely public repo is on the horizon (hopefully 2017). But like I mentioned, there are some issues around code structure, documentation, regulation, license, T&C, etc that need to be sorted out first.
We have opened a User Forum for all NHS users to be able to discuss their needs and concerns directly with us.
Thanks for your interest and support of OpenSource Software!
Cheers,
Jorge
Open Source means something more than ‘access to the source code’ - there’s a specific definition https://opensource.org/osd which is established and agreed by the community. In essence, open source software is software with source code that anyone can inspect, modify, and enhance. The definition supports the ‘power’ of open source, with things like the ability for software to be checked and audited, for useful components to be reused and improved, and for long term sustainability from multiple developers and service providers.
In this case it seems the Kanteron software is not open source. Open to a certain group - in this case, the NHS - is not open source (because it discriminates against persons or groups). Open source software would also allow redistribution, such that someone with access to the source code could share it with others (such as folks outside the NHS).
When there’s a public repository, which anyone can access, and the software in it has an appropriate open source licence attached, then it’s open source It sounds like that is on the roadmap which is great - in the meantime, this is software which is not open source, although the company producing it aspires to make it open source in the future.
Jorge, there are many companies releasing open source software which are also concerned with regulations such as ISO and CE, and insurance, and this does not limit their ability to release the software in a fully open source way. Code structure and documentation should not be a limitation, although of course software is more usable if these are good You may have work to do to provide assurances for your company management or board around this, and the wider community of companies working in open source will have resources and advice to help you. This might include processes which allow you to have fully open source code, whilst only supporting or certifying certain modifications as “Kanteron approved,” for instance.
The simplest definition of ‘open source’ is: ‘can I fork this and use it?’ If the answer is yes, company B (or university B or person B …) can make a copy of the code originally written by company A and try to commercialise services around it. However, company B might also decide that working on company A’s original code is more useful to their goals.
If however, the original code-base managed by company A needs certain characteristics to remain legally and commercially viable for company A, but which don’t fit the goals of newer participants on that code base (maybe they are researchers who want to remove some safety aspects to do interesting experiments), company A can always fork that code base to a version that only it manages, to ensure its purposes are satisfied, or convince the others to fork into a research version.
One of the key questions therefore with respect to any code-base is: what specific goals does this code-base need to fulfill? If those goals include things necessary to continued provision of a commercially supported solution by several companies, then people who want to do incompatible things … will need to fork.
‘open source’ doesn’t mean ‘anything goes’. Just ask the developers of Postgres or the Linux kernel.
For these and other reasons, the process of ‘open sourcing’ an existing major code base isn’t an instant thing, and it is not a binary situation.
Thanks for your interest, Laura.
Just to clarify: the code is literally open source. And more, it is Free Libre Open Source (FLOSS). Licensed under GPLv3. Read the GPL license to see how both our strategy and the license can be achieved by US releasing the code only to the users. What they do with it is up to them. That’s why it is FLOSS.
I appreciate we’re discussing semantics here! But you are using an open source licence, without the project overall being open source today. Just using the licence does not make a project ‘open source,’ although it is a necessary condition. To be open source according to the open source definition I linked above, there would need to be no discrimination by person or field of endeavour. I do not work for the NHS. It seems to me that I am discriminated against - I cannot read the code or reuse it in any way. (If I’m wrong and I can in fact access the code please let me know!)
As such it’s not open source work, despite the code licence. I respect the intent to open source it in the future and appreciate that there are steps your business wishes to take first, around documentation etc, which is fine. It will be open source once I, and others, can access the code and reuse it
Some pertinent points about OSS licensing I feel would be helpful here.
OSS licenses apply only to distribution of the software
In the case of GPL, either source must be distributed with the software, or an offer of source must be made to recipients of the software
They do not equate to an obligation to distribute the software or it’s source code publicly, although many entities fulfil their obligation to offer source by publishing it online
In the case of GPL, the license extends the same rights and obligations to every recipient of the software
So if anyone in possession of the software and the source wishes to distribute them elsewhere, that is their prerogative
If current recipients agree not to do this through goodwill, that is their choice
If they have made a legally binding agreement to refrain from this, that is not compatible with GPL (and they should probably have not made that agreement, knowing the source license)
OSS licenses are not the same as an open development process. I developed software at HSCIC that was, because it was a derivative work of GPL software, under a GPL license, but HSCIC were under no obligation to distribute any of it to the public.
I applaud any commercial entity developing GPL software, when the safe choice in the commercial space is seen as “permissive” BSD-style licenses. I’ve been a critic of the default choice of government programs, particularly HSCIC, to favour BSD-style licenses like Open Government License and Apache 2, because I believe that if public money is being spent on software, then you should use a license that means that the public can continue to benefit from it and change it. From a purely practical POV, for integration projects it makes no sense at all to use a BSD-style license, because any commercial entity can take the code, make a proprietary extension, establish a new de-facto standard and encourage everyone to pay up to use it.
So, in summary :
Kanteron must provide recipients of their software with source code if it’s GPL
Kanteron are under NO obligation to distribute their software and source to anyone just because it’s GPL software
But they have chosen to distribute it to selected collaborators
Kanteron may ask them nicely not to distribute it BUT
Recipients ARE are granted the right to distribute the software and source code further by the GPL license - and if they have made a legal agreement not to do so, that is incompatible with the license
But in the interests of good relations they may choose to refrain from doing so
Note : I am assuming it’s permissible that Kanteron’s software is GPL. To license it as GPL
They must hold the copyright on all parts of the software
It must have no non-GPL-compatible dependencies
Typically this means that all it’s dependencies must either
Be available under a GPL-compatible OSS license or
Be a component distributed with the operating system you’re installing on
Seen this “CE mark” approach before in other open source medical imaging systems. Being “open source” makes the CE mark easier to obtain, because the CE marking regime believes that open source software is inherently safer than closed source software. However, I can’t see how the software can be put in the same “low risk” class as public GPL software, if code access is restricted to users only, who may be bound by contractual obligations not to distribute the software.
Hi Malcolm, can you point me at any such software? I know you know this, but the implication of your comment is that the CE marking regime don’t have an understanding of what industry standard definitions of Open Source are if they think that letting customers see the source code meets the criteria.
Further to the general gist of this thread, I genuinely can’t understand why Kanteron licence their software using GPL then depend on the recipients not distributing it. Adrian’s post above seems to provide a good summary of what GPL means (Although I would amend the first line to ‘Kanteron must provide recipients of their software with source code if it’s GPL if they ask for it’ .
Dear Laura,
It’s not “just semantics”, you are missing a very important point: the license does not cover YOU, since you are not a user. The license covers users. Users are those to whom we provide the software to. So, therefore, the license does NOT discriminate against you or anyone to whom the license applies to. If you want the license to apply to you, you have to become a user. [Disclaimer: I was a lecturer on Intellectual Property and Free Software for 4 years]
In any case, just to be clear:
Hi Malcom,
Thank you for the pointers. Note O3 is only “open”, not FLOSS.
Plus, Clear Canvas and O3 functionality is way below what Kanteron (and other solutions for that matter, like Horos, of which we are also the main partner) offer.
Cheers,
Jorge
So why don’t your users and, come to think of it, your Code4Health “super-users”, exploit their GPL right to redistribute Kanteron code? Surely the code has been released to at least one UK user at this point in time?
It sounds like that is on the roadmap which is great - in the meantime, this is software which is not open source, although the company producing it aspires to make it open source in the future.