Legal conformity: what we need to do

International Governance
1

Continuing the discussion from What to implement in terms of users/enterprises removal

This is a very boring topic. But a topic that can just kill Open Food France if we don’t work on it.
There are three major laws/norms that appy to us in France (some at EU level), and that today we don’t comply with.
Especially, a new one concerns the certification of any “point of sale system” (online also), and it’s appicable on 1st January 2018. (the official reason is to fight VAT fraud, I have some doubts about the efficiency of that measure, but anyway…)
We will ask for a derogation to gain some time so that we can align with the norm and get certified. BUT all our users are going to ask us a certificate on our conformity (they legally have to), and if we are not able to give them thise certificate, they won’t be allowed to keep using Open Food France to manage their food hub.

I have told about it to our various users and potential users, so they know we have taken this issue seriously and are working on it. The impact on the OFN code is not trivial, but the good point is that this could be an opportunity to improve a lot some part of the system that a bit “border line” at the moment.

I’m gonna try now to summarize those very boring thing, and for those who want to go further here is a link to an even more boring document with extracts from the law and attempt of understanding if we are compliant or not and what we should do (it is in a “draft” mode sorry about that)

Some of those obligations are EU obligation to come for next May. I precise for every item if it concerns only France or EU and what is the due date.

A- VAT fraud conformity (Fr - 1st Jan. 2018)

1- All the source data for the establishement of a payment must be inalterable. That includes orders, delivery notes, invoices, and of course payments. Any adjustment on an order or any modification on a payment must appear as “-” and “+” and never change the original data.

The big issue on OFN is that today whatever modification we make on an order change the original order. So if I issue an invoice at 1pm, make an adjustment on the order, I can reissue the invoice at 1:30 PM, the invoice will have the same number, but be different. Legally we shouldn’t be able to touch the original order, we should track the modification and all that should appear in the invoice with “+” and “-” for any adjustments we made. If we issue an invoice it should be “locked”. If another adjustment is made afterward if we issue a new invoice the first one should be void and a second one shoud be created with a different number. If a re-issue an invoice already issued it shoud be marked as “duplicate”. We also miss a “delivery document” that sums up all what is been delivered (that can differ from the original order, if a product was missing for instance)
Same for the payement, it is not as bad as if I cancel a payment I still have the trace of the payment. BUT I shouldn’t be able to do that, if a payment have been accepted, I should only be able to void or refund.

2- We need to provide our users with daily / monthly and yearly “closing”. Which means that should be able to extract and archive the various transactions made during the day, the month or the year, line by line + a summary of the total for the period + a summary of the total since the begining of the fiscal year + a perpetual total (since the hub started using the OFN)

I think we could probably deal with that through some new report allowing the hub to extract and save those data. The only thing is that once that is done it should “lock” the given operation, so no modification should possibly happen one a transaction after the closing action have been done. A bit like when you close the account at the end of the fiscal year, after you cannot change anything on the accounts for that period.
If a hub coordinator manages multiple hubs (legal entities) he can extract aggregated data at the coordinator level. That should work with our report logics.

3- A test / dummy transactions must be marked as such.

Today when we make demo or when a hub test the platform they always do fake transactions. But in case of a control, they appear today in the system just as real ones. We need to have a way to mark a transaction (from order to payment) as “test/dummy”. If you print a receipt or an invoice from those dummy transactions the template should show the “dummy” info backward.

B- Data protection (Fr - already applicable)

4- All personnal data relative to commercial activities shouldn’t be kept more than the legal duration.

In France for instance, invoices, receipts, payments, etc. should be kept for 6 years. And we can archive the info before but they need to remain accessibe in case of a tax control.
I would suggest to archive the info after 3 years but let them accessible by the hub manager (through the possibility to download an archive ? Or list archived transactions?) And after 6 years that could simply be delete. I would suggest we notify the hub manager so that he can make sure he downloaded the archive, if he wants to keep them beyond that legal duration.

5- Users data shouldn’t be kept more than 3 years afer the end of the commercial relationship.

So any data relative to the user, email, address, etc. should be delete and the user anonymized at least.

6- User accounts that are inactive should be deleted after a certain period of time.

For instance I would suggest to delete them after 3 years same as precedent point. We can plan a process like send an email to the user saying “You have an account on OFN but have not used it for the ast three years. We are about to delete it and all the personnal information attached to it. If you want to keep your account alive click [here]”.

7- All cookies information should be delete after 13 months. Information relative to analytics trackers and cookies must be communicated to the user, we must have the user agreement or at least write that in the terms and conditions and allow them to refuse to be tracked.

I don’t know how to implement that but I guess some tech person will know;-)

C- Data protection (EU - May 2018)

There are some EU harmonization regarding data protection that will be applicable from next May.
8- Explicit consent for any data we collect

I don’t think we do ask that for cookies for instance for now ?

9- Right to data portability

I think we are pretty ok here, the data belong to the user and they can extract them or ask an extraction at any moment, right ?

10- Privacy by design

We should collect the minimum data necessary. I think we are pretty ok, we just need to make it possible not to collect address and phone when it’s not necessary and we’ll be ok I guess :wink: (see customizable checkout discussion for instance)

11- New compliance tools

we’ll need to implement and maintain a register of treatments (can be done collectively on Discourse? we have started this discussion that could be a base but we will need to clearly state what is done and what remains to do), notify any security branch (this needs to be done at national level I guess), certify the treatment (how? security audit?) and maybe adhere to some “code of conduct” (do you know one relevant?).

12- Declaration within 72 hours in case of data violation

This will have to be done at national level.

If we want OFFrance to stay alive and thrive, we’ll need a plan, especially for the A part… and as we share the code we need your agreement to incude that in the priorities to come. We need to have a plan, I can try my best to get a derogation, but I need to tell that we do have a plan and can fix that for instance for Jan 2019.
To be sure that this diagnosys is all right, we are going to pay for a specialist lawyer, so that we are sure before we start any work that all that is needed, and that it is sufficent for us to get that certificate.

In terms of data protection, that will fuel the discussion on deletions. I guess every local instance will have it’s own rule regarding data protection, but who can do can less, so I would say let’s protect better the user data, and everyone should be happy ?

Looking forward to read your comments… and @Augustin let’s find a lawyer to review all this work I have done and see if what we plan here is tuned, I’m not at all a specialist and it is soooo boring to read those legal texts …

Add up info:
Source text on EU data protection: http://ec.europa.eu/justice/data-protection/index_en.htm
Apparently as soon as one of your users is a EU citizen you need to respect that law, wherever your company is based.

2

Thanks for this detail @MyriamBoure. I understand that these measures have the intent of protecting people’s data and information, and eventhough the are a pain in the butt (and costly) for us, our underlying ethics and values suggest we should honour these requirements. And, eventhough they are not requirements in CAnada at present - I suspect similar requirements will be put in place as the whole world works through privacy and digitization issues in upcoming years. So - I concur that we need to find a way to comply - the only downside of course is finding the money. Are there any funding programs that are specifically there to help organizations comply?

3

Thank you for such a detailed explanation @MyriamBoure .
Norway is not a part of the EU, but the other Nordic countries are, therefore our instance will need to comply with these standards as soon as possible.
The European Commission is releasing Work Programme #8 for Horizon 2020 on October 27th it covers 2018-2020. My understanding is that Stage 1 of the applications are due mid February. I have spent a few days with the National Research Council recently, and have been weeding through the upcoming call drafts.
Will see if we can find something that might allow us to cover this issue.

4

I don’t think it’s only a question of money, we are happy to put money on it in France, the question is more about specifying all the work we need to do and find the people to do it (devs in France can work on it we are happy to fund the deletion work, to which data privacy is highly connected) and also prioritize this work in the whole things instances want to be done, as testing and merging is done only by very few people today. I let people react but then will for sure start working on the spec for the whole orders & invoice stuff, about how ideally we would like that to work.

5

great work @myriamboure - seems to me like this is all pretty sensible and useful stuff to do. Biggest question for me is if a lot of this is happening EU wide then surely the spree / solidus communities are having to deal with it too? which would mean that it again intensifies the pressure on spree upgrade because we may be able to just piggyback on others also working on all this? I would be very hesitant to make major changes to how order info is stored and adjusted pre-spree upgrade? @enricostn @sauloperez @oeoeaio?

6

Yes, agree @Kirsten would be great to know what happens in latests versions of Spree. Also my though is : as all Spree / Solidus users in France and Europe will have to comply with those laws, maybe that makes sense to make those changes not in the OFN parts but in Spree itself, no ? So that the whole Spree community benefit from it. What do you think @sauloperez @enricostn you’ve been in touch with them, should we discuss that with them ? They probaby have discussed a that on their side as well…

7

I don’t think so since the main use of Spree/Solidus is for isolated private shops, in our case we offer it as a platform to others. This is a problem that only exists for platforms that host other people data. In the majority of cases they just have to follow privacy law to store customer data, much easier (1 line of text :joy: ).

8

Increasingly I am feeling like full accounting software is useful for users, offers compliance for much of part A, and is not something we want to implement.

Might it be worth exploring closely integrating with some open source accounting system?

1 Like
9

Yes, sure @lin_d_hop that would be needed, and @enricostn and @sauloperez are planning some Odoo integration. But that won’t prevent us from changing stuff on our side to respect the law (the fact that we can modify an original order for instance make us inelligible for the required certification). I’m looking for a lawyer now to investigate more closely what we really have to do.

1 Like
10

OFFrance has joined two non-profit advocacy groups for free sofwtare, who are among other things, working on the point A mentionned above. There was a risk to kill the free sofwtares… but apparently the legislation is changing a little bit. I’m starting to envision an easier exit point which would be to simply automatically issue an invoice for each transaction (and for instance make it accessibe through “my account”. That way we would exit the perimeter of the law, as it’s excplicitely sated that “the field of application is narrowed to the transactions which don’t imply an invoicing process.” I hope that can work, wil try to check if we can solve it like that… The problem only remains for the user who use OFN to manage his physical point-of-sale… will need a lawyers on that point…