If you go for a microservices architecture in your organization, they can share configuration via zookeeper or its equivalent. However, how should the vario
From my project experience
Share a WSDL when using SOAP (not the service model code, since they should be generated from the WSDL). When using REST, have distinct models (copy yes but not share) for client and server. As soon as the second or third consumer comes into play, you'll get into trouble. Keep them decoupled. The operating and usage of a service changed in my past more often than the data structures. Another client wants to use your service or a second version has to be operated at the same time.
Some additional thoughts
Sharing is partial contradictive to scalability. Share-nothing and share-some/share-all have both pros and cons. Sharing nothing gives you full flexibility at any time. Microservices are independent components providing particular domain services.
Sharing business domain data models is a common pattern (http://www.ivarjacobson.com/resources/resources/books/#object%20oriented%20software) which prevents duplications of the same. Since microservices divide and conquer the business parts it might get hard to share something of the business domain data model.
Microservices communicate with each other so I understand the need of sharing these communication data models (mostly HTTP based). Sharing these data models might be OK in case you have a one to one mapping between service provider and consumer. As soon as you have multiple consumers for one service needing different models/fields within the model it gets tough.