Topics

Is there any "tacit non-compete agreement" with manufacturers?


Bob M.
 

All, especially Bob J.,

Dick Bronson made a comment in a post
(https://groups.io/g/jmriusers/message/179131) to the JMRIUsers list saying
"I think that JMRI has a tacit agreement with manufacturers to not compete
by adding that code."

Is that true? In general? Or with any specific manufacturer?

I would think that such an agreement would _need_ to be known by developers
and would be cleanly documented somewhere in the Developer's documentation.
But I have never noticed any such information. And I don't recall ever
hearing of any such thing in my many years as a member of the JMRI
developers email list.

I can think of one significant JMRI feature, WiThrottleServer, which could
be considered to directly go again the "non-compete" concept.

And I _know_ that I have implemented LocoNet code in JMRI that "would be in
competition" with equivalent functionality provided by Digitrax. That code
has been in place for years, and, so far as I know, noone from Digitrax has
complained.

Regards,
Bob M.


Bob Jacobsen
 

Well, it’s a bit complicated.

As far as a I know there is no general agreement to not add anything that could be done via public information. This extends to all manufacturers and features I know about.

But that sentence isn’t as broad as you might think:

- Some manufacturers have shared non-public information with specific JMRI developers. Sometimes there are formal agreements, sometimes it’s getting an email with “please don’t share further”, sometimes a Q&A conversation with some specific person with limitations expressed. That sharing sometimes comes with limitations: “This will help you implement X, but please don’t use it for Y as we expect to change that”. ADAIK, those have always been honored; they certainly should be. I see no reason to require those JMRI developers to say anything in public about that, though of course they might want to.

- Sometimes manufacturers have been concerned that the resulting JMRI code would disclose something. We’ve had a couple cases where a manufacturer is OK with JMRI doing something, but is concerned about what other manufacturers will do. Here, we can (and have) utilized the detailed structure of the LGPL2 to place a limitation; see the last paragraph of the head comment in java/src/jmri/jmrix/loconet/AbstractAlmImplementation.java

I don’t know of any limitations based around _JMRI_ competing. But perhaps others do. And perhaps they can or can’t say anything.

Bob

On Aug 27, 2020, at 9:08 AM, Bob M. <jawhugrps@...> wrote:

All, especially Bob J.,

Dick Bronson made a comment in a post
(https://groups.io/g/jmriusers/message/179131) to the JMRIUsers list saying
"I think that JMRI has a tacit agreement with manufacturers to not compete
by adding that code."

Is that true? In general? Or with any specific manufacturer?

I would think that such an agreement would _need_ to be known by developers
and would be cleanly documented somewhere in the Developer's documentation.
But I have never noticed any such information. And I don't recall ever
hearing of any such thing in my many years as a member of the JMRI
developers email list.

I can think of one significant JMRI feature, WiThrottleServer, which could
be considered to directly go again the "non-compete" concept.

And I _know_ that I have implemented LocoNet code in JMRI that "would be in
competition" with equivalent functionality provided by Digitrax. That code
has been in place for years, and, so far as I know, noone from Digitrax has
complained.

Regards,
Bob M.





Bob Jacobsen
@BobJacobsen


Chuck Bade
 

I think it could be very limiting if there was a general "non-compete" agreement that JMRI developers were bound by.  Take the case of MQTT support, which was recently enhanced (thanks Bob).  By supporting MQTT and allowing guys like me to use simple inexpensive IoT nodes to control blocks and turnouts, some manufacturer may claim that doing so competes with their proprietary protocol and hardware they sell to achieve the same thing.
Regards,
Chuck


Balazs Racz
 

I think this question is only meaningful to ask about specific circumstances. A "general con-compete agreement with the industry" would likely not even be valid by any plausible interpretation of the law, and it is also not clear who would have signed as the other party of such an agreement...

The specific thread was about LocoNet features. LocoNet is known to be protected by certain patents in the US, and I'm not familiar with the details. The questions to raise then are:
- Does JMRI need a license from the patent owner for what JMRI is doing now? (For example if the patents cover the physical / electrical setup, then the answer is no, but if the patents cover the software and the protocol, then the answer might be yes.)
- Does JMRI have such a license? Is this license revocable and/or does it have any restrictions applied to it?
- Would JMRI need a license for feature X that we might be considering to add?

thanks
Balazs


On Fri, Aug 28, 2020 at 7:46 PM Chuck Bade via groups.io <chuck.bade=icloud.com@groups.io> wrote:
I think it could be very limiting if there was a general "non-compete" agreement that JMRI developers were bound by.  Take the case of MQTT support, which was recently enhanced (thanks Bob).  By supporting MQTT and allowing guys like me to use simple inexpensive IoT nodes to control blocks and turnouts, some manufacturer may claim that doing so competes with their proprietary protocol and hardware they sell to achieve the same thing.
Regards,
Chuck


dick bronson
 

Chuck,

Look up the word 'Tacit'.

I'm just saying that a manufacturer (e.g. Digitrax) would probably not be very happy if using JMRI suddenly eliminated all need for their command stations. What do you think that would do to their willingness to provide further assistance to JMRI developers in understanding their protocols? Be careful of what you are asking for. As long as manufacturers consider that supporting JMRI helps their bottom line, then they will support us. If they decide that JMRI is a competitor, then expect any cooperation to fade into FUD.

If you want open source throttle protocols to use, then the NMRA LCC and OpenLCB are very happy for you to support them and use their protocol.

Dick :)

On 8/28/2020 1:45 PM, Chuck Bade via groups.io wrote:
I think it could be very limiting if there was a general "non-compete" agreement that JMRI developers were bound by.  Take the case of MQTT support, which was recently enhanced (thanks Bob).  By supporting MQTT and allowing guys like me to use simple inexpensive IoT nodes to control blocks and turnouts, some manufacturer may claim that doing so competes with their proprietary protocol and hardware they sell to achieve the same thing.
Regards,
Chuck