# Data type regulation policy and membership fees

**URL:** <https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707>\
**Category:** Development & Maintenance\
**Created:** [December 8, 2019, 6:55am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707 "2019-12-08T06:55:57Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [December 13, 2019, 8:42pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/3 "2019-12-13T20:42:49Z")

</div>

> [@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](https://forum.opencyphal.org/t/on-standards-and-regulation/260)_. 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.

---

_[View the full topic](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707)._