Data type regulation policy and membership fees

[pavel.kirienko]

@scottdixon

The difference here is that we no longer endorse public unregulated types. If you want to have your own types you have to keep them to yourself or you have to regulate them.

I think this issue has many parallels with the rejected alternatives of fixed port-ID management policies discussed in the thread On standards and regulation. Vendors will want their own types because other industries show that even a well-regulated and expertful consortium is unlikely to foresee all sensible use cases. I expect that such conservative policies may stifle the development of new products and applications based on UAVCAN, so I suggest keeping the current approach where public unregulated types are permitted but discouraged.

@scottdixon

I am strongly opposed to a fourth option of publishing public, regulated types in the core specification beyond the highly generic types we currently propose for v1. I think doing so was a decided weakness with v0 that we have properly cleaned up in v1.

I agree.