Hi there!
This post will explain the main process of onboarding your application/service to Veracity.
When we say something is “on Veracity” we mean two different things:
- The application is available through Veracity Marketplace.
or - The application uses Veracity technology like Veracity Identity login.
Many applications are both available through the marketplace and use Veracity technologies.
The Veracity onboarding team will help you throughout this process, you don’t have to go through this alone.
We are here to guide you!
You can reach us at onboarding@veracity.com
The onboarding process looks something like this:
a. You reach out to us and tell us about your product/service.
b. For existing products we spend some time to adapt the sales model to something that makes sense with digital sales.
c. We help you create a draft marketplace product page, we kickstart the legal process & involve the legal team to create T&C’s and lastly we review your technical solution to ensure it complies with the technical requirements for Veracity.
d. We test all of the above and make sure you are happy with the results - you will have a pretty marketplace page, a good set of T&C’s and a compliant app.
e. Go-live! We hit the button and you will have the option to be followed up by our customer success team to ensure you get the most out of the Veracity marketplace and technology.
- Marketplace requirements
- Technical requirements
- Legal requirements (only for DNV apps)
Marketplace requirements:
There are some strict limits on what you can do on your own Veracity Marketplace page.
See more details here:
In short, you have to fill out a form and send Veracity some images for your page.
We will then construct the draft page for you.
We also have the option for self-service of the marketplace pages after the initial draft has been created. Let us know if you’d like access to the self-service tool.
We’ll iterate together on your marketplace page until you are happy.
Keep in mind that not all existing business models work well with online digital sales.
It does not make sense to cram 47 different product variants on a single marketplace page.
We recommend to keep it to 3-4 product variants maximum, with the option for a “contact us to learn more” approach for more complex variants. It is common for 1 or 2 of your product variants to represent a vast majority of your sales - focus on these variants!
Think about the product variants you see in your daily life online - be it on Netflix, Spotify or any other digital platform. Make it easy for your customers to buy! Limit the amount of choices, and make it super clear to your customer what it is they are purchasing.
Tech requirements are found here:
Short summary of tech requirements:
You have to call the Policy API endpoint. This enforces terms-acceptance for users.
Users who have not accepted the latest terms & conditions should not be allowed into your app if they use their Veracity account for login.
You have to display a logout button.
Your app must support a few different browsers.
And you have to think about what sort of data you are storing. If you are storing personal data, then some additional requirements kick in.
Legal requirements summarized (only relevant for DNV apps):
All DNV-owned apps need their own set of terms & conditions to provide a legal framework which follows DNV contracting principles. It is important with a tailor made set of terms and conditions for each service to capture legal risks unique for your service.
We are interested in two main topics:
Do you have updated agreements for use of intellectual property not owned by DNV? And are you on top of GDPR requirements?
We’ll ask the following questions:
Are you using any 3rd party data?
Are you using any 3rd party components?
Do you have contracts in place regulating your use of this 3rd party stuff?
Are you using open source components, and if so, have you looked at the licenses regulating your use of these components? Licenses like GPL and LGPL can contain clauses which can restrict DNV’s ability to sell the product and use of these licenses must be reviewed together with the Veracity onboarding team.
Have you implemented cookie-consent if it is a webapp?
And if you are storing personal data, we have to inform our users! So you have to tell the lawyers so they can create good service-specific terms & conditions for your service.
We recommend using Veracode to get a good overview of the licenses for your software components (“dependencies”).
Always read the license text. They are often quite short, so not a lot of effort.
It is the product owner’s responsibility to be on top of license compliance.
There are three categories of open sources licenses you should be aware of:
- Permissive licenses, like MIT, Unlicense, Apache 2.0. Permissive licenses are rarely problematic.
- Hybrids/weak copyleft, like MPL 2.0, LGPL. You must read the license text very carefully in the context of your usage of the dependency. These can create problems if you are not careful, but they are often unproblematic.
- Copyleft, like GPL and EUPL. These are often problematic and should be avoided. Do your utmost to use another dependency with a more permissive license. If you cannot remove them you must read the license text carefully. Different copyleft licenses may have mutually exclusive requirements, so having two or more copyleft licenses might make your app impossible to legally distribute.
DNV employees, see official statement from legal department here.
Link - DNV Policy for Open Source Software
Link - DNV Policy Guidance Document ← this one is useful and important to read!
Some public resources concerning licenses:
Link - Overview with description of most common licenses
Link - Table view of common licenses. Rule of thumb: The more blue dots, the more problematic the license.
Link - Another resource with overview of licenses
DNV has good relations with our suppliers of software and components, but some of these contracts are ageing. An example would be a valid contract that allows DNV to use a software in exchange for royalties, however the agreements explicitly lists floppy disks or CD-ROM as the distribution method of the software. That doesn’t support DNV’s preferred delivery model today, and we need to update contracts like these even if both DNV and the software supplier are happy with the status quo.