Allowed use of openEHR specification intellectual property for client SDKs

Implementation
1

Hello,

Could you please give feedback on whether the following idea would be allowed usage of the openEHR intellectual property?

TL;DR: Translate the openEHR specifications into Java API components.

  • Create a new GitHub organization called e.g. “openehr-java-api”, with a notice that it is an experimental, unofficial project.
  • For each openEHR specification:
    • Create a GitHub public repository.
    • Inside the repository, create a new Java project.
    • In the Java project, create packages, abstract classes, enums, and interfaces, according to the contents of the specification. Those classes etc. should not have any constructors or method bodies, they should just translate the specification into the Java programming language. If allowed, the Javadocs should also contain a copy of the original description of the class, attributes, methods, etc.
    • While in the experimental stage, publish the project as Maven Package on GitHub Packages, with the version number of the original specification and a suffix that indicates the compliance status, e.g. com.experimental-software:openehr-rm-support:1.1.0-alpha-42.
  • The API projects are connected with Maven package dependencies, according to the dependencies in the specifications.
  • The custom software can apply the required API projects as dependency and create its custom implementation.

Motivation

  • Implementers might want to use the published packages as the baseline for their application.
  • The maintenance of API-only packages should be doable with reasonable effort, so the packages might cover 99% of the specification and can be close to bug-free.

References

2 Likes
2

Hi Jan,

should be no problem given the openEHR licenses! I just would be curious how this would be different from something like Archie (GitHub - openEHR/archie: OpenEHR library implementing ADL 2, AOM 2, BMM, RM 1.0.4 and many tools) which to my understanding is derived from BMM files.

2 Likes
3

Hello Jan,

I think you won’t have troubles with it - but perhaps you should wait for more feedback from persons into legal stuff.

I have a few questions though:

  • Why would you create an organisation called ‘openehr-java-api’? (that’s clearly not an organisation)
  • Is your question more about Maven aspects, or more about GitHub, or more in general about openEHR IP-rights, trademark, etc?
  • Are you planning to generate these java-api? if yes, what the source-truth for these specs? is it the UMLs in each repository?

If this java implementation of all openEHR spec-components would be open-source, and if you would be ok donating it to openEHR, we can have in theory an evaluation/discussion about creating it under openEHR organisation in Github.

1 Like
4

It is not clear to me within 15 minutes what the scope of the Archie project is. It doesn’t have a “screaming architecture” which tells from the project name and from the directory structure which problem it solves. From my point of view, the README file is lacking an “Overview” section with an UML Component Diagram that puts the project into context. The “Usage” section in its README file covers topics that are way too advanced for my project scope (experimental software). While Archie actually seems to address a part of the problem I am trying to solve (make the openEHR data types accessible with Java), I am feeling uncomfortable with pulling a partial (?) implementation of the openEHR specifications in as dependency.

I want to implement just a tiny slice of openEHR.

5

Why would you create an organisation called ‘openehr-java-api’? (that’s clearly not an organisation)

The idea of a separate GitHub organization is not meant to create a new legal entity but to use the word the word “organization” in the sense of grouping things that belong together. The “Archie” and “java-libs” projects have a monorepo structure whereas I am attracted to the idea of having a separate repository per specification.

The idea is inspired by my recent (ready-only) exposure to java-json-tools. And publishing an open-source project of my employer to Maven Central that uses the git tags for determining the project version number with the help of the Gradle axion-release-plugin.

Is your question more about Maven aspects, or more about GitHub, or more in general about openEHR IP-rights, trademark, etc?

This question is about openEHR IP-rights. I didn’t think through the technical aspects of the idea, yet.

Are you planning to generate these java-api? if yes, what the source-truth for these specs? is it the UMLs in each repository?

Generating these Java APIs would be ideal, maybe even a requirement for production use. For the prototype, it would be hand-crafted. To some degree, the type definitions can be parsed out of the ADOC files. I have a Python script for this which I could share if a few copies of the “ADOC” files as its unit test data are not considered a copyright violation.

If this java implementation of all openEHR spec-components would be open-source, and if you would be ok donating it to openEHR, we can have in theory an evaluation/discussion about creating it under openEHR organisation in Github.

I have only academic interest in openEHR, so yes, it would be open-source, and even if I had commercial interests such a project should be donated to the openEHR organization.

So, if there are no legal doubts about the general idea, I would “decorate” my playground GitHub organization Experimental Software in a way that reflects the original idea. After having done the prototypes, I could write a report here in the forum.

Of cause, if anybody wants to discuss the idea and pros and cons of different solution aspects, that would be more than welcome.

3 Likes
6

Thanks, good answers. Keep in mind that openEHR specifications are organized in components (openEHR - All Components), but I guess not all of them are suitable for Java implementation.

1 Like
7

Hi @jmewes, welcome!

For that scope, I’ve been using the Java Ref Implementation since 2006, which has the reference model implemented, including datatypes: java-libs/openehr-rm-core/src/main/java/org/openehr/rm/datatypes at master · openEHR/java-libs · GitHub

It also has support for archetype parsing, which I use in some projects today.

Check GitHub - openEHR/java-libs: Standard Java libraries for Java implementations of openEHR

Though not Java but Groovy, which is my primary programming language these days, though it compiles to bytecode and can be used from Java, this has an implementation of the reference model and tools like openEHR canonical JSON serialization and parsing, JSON validation, RM validation against OPTs, OPT parsing, and other tools GitHub - ppazos/openEHR-OPT: Java/Groovy Support of openEHR Operational Templates, Reference Model, Data Generators and other tools for www.CaboLabs.com projects

Hope that helps!
Pablo.

1 Like
8

The pom.xml of the project states that “openEHR/java-libs” is “The openEHR Reference Java Implementation”. In contrast, the idea of the “openehr-java-api” project is not to provide any implementation, only the data types.

9

Can you please explain what’s the difference between providing an implementation and providing data types?

In openEHR “data types” is a specification and it’s implemented in the java ref impl, but it seems you are referring to something different.

10

Let’s say openEHR would define a class “FOO” with an attribute “bar”.

“openehr-java-api” would define an interface “Foo” with an abstract method “getBar()”. App1 has a class that implements the interface “Foo” and the method “getBar()”.

“java-libs” would create a class “Foo” with a constructor and a getter “getBar()”. App2 uses data type “Foo” for its business logic.

This is shown in the following UML Component Diagram:

cmp

Mind the difference between the Realization, Generalization, and Dependency symbols.

So, “openehr-java-api” would extend the openEHR whereas “java-libs” implements it. So, “java-libs” is the default implementation while “openehr-java-api” just transpiles the specification to the Java programming language.

1 Like
11

I understand. What you mentioned here :

Would be really “provide the interfaces” not “provide the data types”, that makes more sense.

I guess you could do that for all classes in the openEHR reference model, and handle some strange cases we have of double inheritance. Generally speaking, it’s difficult to have a 1 to 1 mapping between specs and implementation (even if it’s interfaces only), but you can get close.

Best,
Pablo.

1 Like
12

FWIW (not a legal expert, and can’t speak on behalve of openEHR as copyright owner. Mostly a community perspective):

I expect what you’re doing is great to us as a community including the formal bodies (foundation, CIC, partners).
The copyright is in my view mostly there to assure the standard can thrive: technical consistency between systems and lenient enough for diverse commercial models. (Described in the page you referenced).
So the most important thing is not to go create a deviation of the openEHR spec that would be technically incompatible and promote it as “openEHR”. What you’re describing is the opposite, something that could be very useful to the standard. So don’t worry too much about legal and just make sure your work is technically compliant with the current spec.
If you want to be more explicit you could put a link to the original specs in your repo and refer to openEHR as copyright holders.
@thomas.beale agree?

13

Agreed. A contribution to the readme (issue/PR) would be very welcome (a). @pieterbos , the lead engineer, is always happy to help, but is quite busy atm.

15

Thanks for the notice. However, I am not able to do so any time soon.

16

I have added a “Legal notice” section and references to the original specification at the end of the README file, e.g. for the RM component:

1 Like