Legal review prior to release of v1.0

[John-S4]

A comprehensive review of potential legal problems with the way that FOSSBilling handles personal data, payment information, taxation, etc.

From my provisional discussion with someone who knows a lot more about these things than I do, basically all legal responsibility falls with a service provider and not with the creator of the software that they use. Also the fact that the software does not store any payment card information helps a lot.

Despite that we should conduct a review to ensure that we are not explicitly enabling either deliberate or accidental illegal activity, and if there are countries where FOSSBilling is clearly not capable of providing services that meet legal requirements then those should be documented.

[Anuril]

[...]The text here was formulated in a way that might have been interpreted in a way to mean that the FOSSBilling project might be liable for actions done by users or required to implement functionality. It has since been removed to remove confusion.[...]

To check that we are not explicitly enabling either deliberate or accidential illegal activity, I generally see that we need to review three areas:

• Privacy & Data Protection (GDPR et al)
• Invoicing & Tax Laws (VAT, Sales Tax)
• KYC / Data retention laws.

Privacy & Data Protection (GDPR et al)

There's many webpages with information regarding that. I found this for example.

Thins we definitely need to adress:

• Encrypting users personal data in the database
• GDPR compliant consent forms for cookies
• GDPR compliant mass mailing double opt-in & opt-out capability
• EU Regulations require Order buttons to clearly state that pressing them incurrs charges. I think we need to add that.

Invoicing / Tax Laws (VAT, Sales Tax)

Tax laws are complex AF. There's a really good resource here, where many requirements are detailed.

For my country (Switzerland) I can and will review FOSSBillings functionality. Many of these requirements are the same as in most EU countries as well.

Tasks I already know about (See issue #1703 ):

• Functionality to change Tax rates.
• Ability for invoices to be done with two different VAT rates (Rate 1 until 31.12. and Rate 2. until end of Period"
  • Can also be a function to create two invoices if tax rates are going to switch.
  • I will expand on this at a later stage but this quite complex.
• Reporting functionality for VAT
• Ability to switch between "collected" (tax is due when customer pays) and "agreed" (tax is due when customer orders) tax modes.
• Making sure invoice numbers can't be used again. (Should be fixed by Keep same invoice id #1473 and [Feature Request] Continuous Invoice Number as needed in EU #131 )
• Making sure taxes are stated correctly on the invoices.
• Making sure invoices can't be edited or deleted, only cancelled / countermanded once they have been created / sent.
• A functionality to download all invoices ever created in a ZIP File would be required. (You need to save them along your incoming invoices for bookkeeping)

KYC / Data retention

AFAIK KYC is primarily relevant (regulatory-wise) in banking / finance sectors. There may however be countries where there are far more wide-reaching requirements.
Also, for reselling Hosting, you might want to prohibit your customers to be scam artists that lead to your whole account with your provider to be suspended.

Imho, the best thing would probably be a module "enhanced-kyc" that handles that if necessary. Maybe (at a later stage), we might want to implement some KYC service.

As a start we could implement a "KYC Process completed" flag that can only be set by staff and is required before customers can place orders.

Ragarding Data retention, for example in Switzerland you need to keep all invoices (and legal documents) you send out for 10 Years.

Also, in the EU, there are discussions regarding Data transferrability, so we should also take this into account.

[jaapmarcus]

VAT in the EU is different cans of worm as every country has different vat rate(s) and rules for handling with consumers... or not ...

[Anuril]

I feel the need to clarify regarding my statement above, due to it being misunderstood in internal discussions as well as f. ex here:

I am not suggesting (and I'll edit the text above accordingly) that FOSSBilling, a Project licensed under the Apache License is liable in regards to the code shipped. The License very clearly states that all liability to all extent possible under the law lies with the user of the software.

My point is that it is in the interest of FOSSBilling that certain legal requirements are met to help adoption of the software, and this is what my text describes.

I will now edit the text to make it better reflect that.

Otherwise, I do not think my understanding of the sentence "Despite that we should conduct a review to ensure that we are not explicitly enabling either deliberate or accidental illegal activity, and if there are countries where FOSSBilling is clearly not capable of providing services that meet legal requirements then those should be documented." is amiss in pointing out the issues I did.

[John-S4]

I feel the need to clarify regarding my statement above, due to it being misunderstood in internal discussions as well as f. ex here:

My thoughts in 1698 were not about your comments here directly but just about the whole legal review in general. I really do think that a checkbox on install that says essentially 'It's my fault if I do something illegal with this software' is a very good idea.