Can we legally publish code implementing ISO-11783?


#1

For implementing a reader/writer of ISOBus data you need the ISO 11783-10 specification. You need to buy this specification, and I remember clicking some TLDR agreement in the process. The bought specification-document is watermarked with my name.

Code implementing an ISObus reader/writer discloses many details about the ISO 11783-10 specification. I’ve once been told someone wasn’t allowed to publish their ISOBus code as Open Source, because of “infringement problems”. I don’t know the the exact reasoning. There is only little open source code on this subject, therefore I wrote this answer on stackoverflow: https://stackoverflow.com/a/48632418/193886

So my question is, can we legally publish code implementing ISO-11783?


#2

That’s a great and important question.

@aultac thinks it should be fine citing e.g. http://www.isoaglib.com/en/download as an initiative that is already doing it.

While Googling a bit I found an academic paper on this topic: https://www.igi-global.com/article/on-implementation-of-open-standards-in-software/148742 (PDF). A quick scan of the conclusion reveals: it depends on the standard… I still have to read the whole thing, though.


#3

I don’t think I’m the definitive source on ISO’s view of publishing open source :). I have reached out this week to see if we can get a clear answer from them on the topic of open source and ISO11783.

For ISO11783 part 10 (ISOXML) specifically, I did see this: https://github.com/pvvovan/IsoXml
and the industry-wide initiative ADAPT with Ag Gateway has published this: https://github.com/ADAPT/ISOv4Plugin.

I’d say that pretty well covers anything you’d like to do with part 10 and those are in the public domain.


#4

Thanks for the response @aultac.

I’ve only discovered the Adapt source code last week. A pleasant surprise, although it seems quite a big effort to connect it to another standard. In my experience, the hardest part of working with isobus data is that each producer treats the semantics a little bit different. This way you’ll end up with a lot of vehicle/implement/manufacturer-specific code, transforming it into a more uniform data format.

@Simeon the article you mention seems spot-on! Didn’t buy it yet to read it though :slight_smile:


#5

Click on the PDF link to open the PDF Google Scholar dug up. :wink:


#6

Great! Looking forward to their answer.


TrekkerHack 2018
#7

Hooray @auke and @Roel managed to hook up the ISOBLUE to the tractor and log some data!

The next step is to parse the log and extract some useful data/information.

As expected, we’re in the well-known ISOBUS proprietary parameter decoding part. @wang701 then writes that (emphasis mine):

I’m wondering why the sheet can only be use within your group? Is it because you are reluctant to share which - first and foremost - I completely understand and respect, or is the ISOBUS standard license preventing you from sharing it with others.

In case the latter reason (ISOBUS license) is the culprit: how do the open source projects mentioned earlier share this information if they share it at all? Or do they “limit” their scope to only reading the data but not transforming it?

I’m interested in the reason as it dictates the required future work in the context of our ambition to create an open parameter transformation sheet.


The First Dutch ISOBlue!
#8

Hello Simeon,

You raised some really good questions. I will answer them one by one.

The sheet was purchased by a faculty member and it is copyrighted so I cannot share it here.

Our assumption is that the manufacturers will most likely keep their proprietary information for their benefits for quite a long time. Both ISOBlue and ISOBlue 2.0 are created so that the machine data can be freed without using manufacturer provided yield monitors and you can access them and create visualizations in near real time (although we are still lacking on these parts) . In addition, ISOBlue 2.0 is designed to fit into a much broader ag IoT data streaming architecture. Simply put, we want ISOBlue 2.0 to stream to Cloud endpoints that are accessible for universities, individual researchers, and even ag machine manufacturers. Then these entities can first get the raw data from these endpoints and parse them out using their proprietary information. The parsed and human readable data like machine status, sensor readings, etc. will be then pushed to another (or the same) Cloud endpoints for the public to access and share. In this process, different entities will not necessarily disclose their proprietary information. This is a vision we want to achieve.


#9

@Simeon I have received a tentative answer regarding publishing of open source code that implements ISO-11783 from Jaap Van Bergeijk of AGCO who has worked closely for a long time with ISO’s committee overseeing 11783. He graciously gave me an overview of what open source work has been done in the past and the general sentiment within this part of ISO around the topic. I will summarize here with his permission:

1: You can publish open source code that implements ISO11783 as long as it references the ISO11783 documents, but you cannot publish the actual ISO11783 documents themselves.

2: Industry organizations that interact most with ISO11783 such as AEF and Ag Gateway encourage open source and common source development.

This is not an official statement from the ISO SC19/TC23 committee, but seems to be a summary of how they have viewed such activity in the past. I am awaiting further conversations on whether ISO SC19/TC23 would be willing to issue an official statement or position on open source development for clarification.

Aaron


#10

Thanks for the update! I’d say that’s good news!


#11

I’m also interested in an official statement from them.
In the meantime, what can we do to work with ISOXML files?
I see that ADAPT framework provides a ISOXML plugin but this is written in C#.NET and I’m creating something in Java.