Can we further open up the core specification license?

[pramodkvarma]

Now that the core specification has become fairly abstracted and has seen adoption across multiple domains like retail, logistics, mobility, healthcare, skills and education, I feel we should further open up the license further removing any limitations.

What do you all think?

@core-wg-admin @pkapustin @venkatramanm

[pkapustin]

I agree completely, usually to arrive at a network-level specification that is precise enough to be fully interoperable (so that one BAP/BPP can be easily substituted with another), one would need to add a domain layer and network policy layer to the core spec.
Of course, a permissive license is required for this.

[ravi-prakash-v]

Attaching a sample workflow that usually takes place when adopting the protocol for a network.

• Core WG publishes a version of the core spec
• Domain-specific communities adopt a certain version of core specification by mapping their schema to the core schema.
• Any domain schema that doesn't have a corresponding core schema gets added as a namespaced "non-standard" schema
• Networks may adopt more than one core schema along with other specs like DEPA, ODR etc to create a larger network-specific specification.

A network's participants implement the network-specific spec to become interoperable between themselves BUT,

a) How will we ensure interoperability between networks implementing the same use case?
b) What if there are two networks that have derived two different domain-specific instances of the core spec? Will one spec eventually take over the other?
c) Removing the ND clause of the license may cause a "runaway effect" in the core spec with different domain-specific working groups trying to add more features to the core spec as "non-standard" schema without actually trying to map the domain schema to core schema.

I partially agree with making the protocol evolution less restrictive i.e removing the ND clause of the license. But how will we avoid the interoperability issues arising out of them?

[venkatramanm]

When some community decides to create a derivative, and want to call it beckn derived , it should be ok as long as they can publish the differences with the core spec version they have derived out of. As long as there is a language for people to declare their adaptation, it is ok.

May be to prevent runaway effect due to not understanding the protocol correctly, we can have a beckn certified domain extension or something to that effect.

If massive differences are there, we could may be prevent use of derivative but allow using words like inspired.

But primarily I agree, that the nd nature of the license must go.

[pramodkvarma]

@pkapustin idea is to allow general freedom. But creating custom extensions at network level will reduce inter network innovations. It's like customising http assuming it is restricted to a specific sub network. Eventually amplification will happen when networks expand and get combined to create non linear amplification. So, in general adopters should be encouraged to contribute and maintain a common spec. Otherwise entire idea of interoperability falls apart. But from licence perspective, we should give freedom. Hence this post. Hope you agree.

@venkatramanm agree, should ideally make sure community is actively working with adopters to avoid forks and custom extensions. Let us think about good community processes respond to needs and align adopters through conversations.

We must keep fundamental reason for existence of beckn - interoperability, decentralised empowerment.

[pkapustin]

@core-wg-admin

a) How will we ensure interoperability between networks implementing the same use case?

@pramodkvarma

But creating custom extensions at network level will reduce inter network innovations.
So, in general adopters should be encouraged to contribute and maintain a common spec. Otherwise entire idea of interoperability falls apart.

Agree, this is why I am advocating work on expressive and reasonably precise domain-specific specs that can be used as a basis for multiple network-level specifications. This is also supported by well-established approaches like domain-driven design.

For example, currently both metro and river transport are using the same version of the core spec, but there is very little in common between the JSONs, and they are not interoperable, even though they are in the same domain of public transport.

To improve this, we have started work together with @techframewirk on the domain-specific spec for public transport spec to help us implement various use cases in a similar way. There are a lot of common processes in public transport: there are stops, schedules, departures, tickets, passes, etc., and a lot of this can be represented directly in a domain-specific spec. This will also help when implementation for other means of transportation like buses.

If such domain-specific specs exist, new networks are likely to use them as a basis, and this will lead to a relatively thin network-level layer. This way, if at some point there is a need to allow transactions between these networks, it will be possible to do so with minimal changes. On the contrary, if one attempts to represent all of the use cases using only the core spec layer, one will inevitably end up with completely different representations, and inter-network interoperability is going to be much more difficult to achieve.

[pramodkvarma]

Agree on domain specific schema and network level taxonomies. My key point is to avoid "customisation" of spec that defeats the interoperability and combining criss domain/network transactions (health network transaction connecting to mobility network and fulfilling cab booking to go for a health checkup).

[pkapustin]

Of course, I agree we should be able to support such transactions that combine multiple networks.

Sharing some implementation insights here: this can usually be achieved by composing several interfaces. For example, we currently work on use cases where one BAP platform allows the user to consume services from multiple technical networks (taxi, metro, parking).

If desired, these can also be combined in one transaction (for example, booking a parking slot and renting a bike nearby, or stitching a trip that consists of a taxi, metro and other means of transport). This is why we had several discussions recently, consensus being that BAP needs to collect the payment.
#156

However, this doesn't mean that we need a common interface that supports booking a doctor and booking a taxi to arrive to the doctor's office in one, right? Rather, we can have two clean independent interfaces, and if a participant (typically a BAP) needs to provide two services from different networks and combine them, that participant can consume both interfaces (implement both network-level specifications on the BAP side).

Achieving interoperability is already quite difficult even within one network / domain, so I think it is very important that we avoid dependencies between domains. This way domain- and network-specific specs for different domains can stay expressive and precise, and changes in one don't need to affect another, significantly simplifying implementations and reducing the chance of errors.

I hope this makes sense.

[pramodkvarma]

No, wasn't talking about single schema supporting all. Common set of APIs/architecture, different set of schemas for various use cases, all composable to create larger combinations of transactions and meaningful user journeys. I think we are aligned there.

Btw, don't want to digress from original topic. Opening licensing further! Hope that makes sense.

[pkapustin]

Agree completely!
Definitely, agree it should be opened up.

[ravi-prakash-v]

So what license do we change it to?

[pramodkvarma]

I suggest CC share alike (if I am right ot is CC-BY-SA).

[ravi-prakash-v]

Noted. We will look into this soon as we are focusing on completing some core changes and improving governance processes.

[pramodkvarma]

Absolutely! Let us come back on this in few weeks!