Painful. Stopped reading after first few paragraphs.
1,409 karma · joined June 12, 2011
User content may include personal data but may also not...so in some senses, better to include totality of use cases in a non-data protection related document.
The AI services section seems pretty clear in terms of limiting the use cases of user content:
"iv. Use of Your Content. As part of providing the AI services, Microsoft will process and store your inputs to the service as well as output from the service, for purposes of monitoring for and preventing abusive or harmful uses or outputs of the service."
Admittedly, I haven't read other parts to understand the full picture though.
IP addresses are slightly different because that address can be used to identify the subscriber in certain cases (who in turn may or may not be an individual).
Even if you're not dealing with any personal data, if you're placing a cookie (or doing anything analogous device fingerprinting etc) you are in scope of the Directive and need consent, irrespective of GDPR.
The new E-Privacy Regulation is looking to implement an exception to consent for analytics but that would have providers like Google Analytics out of scope. Anyway, it's stuck in the mud at present...
In reality an IP address is generally not PII, but it may be personal data - the case is Breyer which was decided on pre-GDPR law but still relevant. If you could use reasonable means to identify someone from the IP address then it will be personal data. I don't really agree with the outcome of the case because it implied it was easy to contact an ISP to get them to disclose details of the subscriber information associated with the IP address. In the UK at least it would require cause, and a court order.
Now with the UK's departure, employers may struggle to fill vacancies (and indeed it appears they have been - see link below), so the poster was sarcastically suggesting that they can't wait to see pro-leavers performing these tasks because it seems like in many cases UK nationals aren't willing to perform these types of roles.
The nature of the role is irrelevant and the poster wasn't suggesting that pro-leavers should be subject to degradation!
https://www.theguardian.com/business/2019/oct/11/tonnes-of-c...
Built with Gatsby, MDX and Theme UI. Yes, overkill!
With Grindr, they only need to process data to provide the service by making it available to you and to other users. What they definitely don't need to do in order to provide the core service is to share your data with third parties who can then use it for their own purposes.
Any argument that the processing is necessary because it's an ad-funded service would not be acceptable under data protection law.
On that basis, performance of a contract would not be a relevant ground. You're also looking at e-Privacy Directive considerations in the EU where either a cookie or similar is essential to provide the service, or you need consent. Similar for location data, you will generally need consent.
So you not only have GDPR issues but also e-Privacy Directive issues where your processing grounds are actually incredibly limited anyway.
Having said that, you could mitigate through an arms length license agreement but it would have to be water-tight and obviously there's a tension between protecting your friend's patent and protecting the company's rights in that patent. The more it protects the company, the less confidence your friend would have (perpetual grant of rights vs time-limited, termination triggers etc).
You could also always start off with a license to give the company confidence, but if you are subsequently looking to fundraise and see investors are being put off, look to assign the patent to the company. The license could even incorporate an option to purchase to give the company further certainty that for the right price it could acquire the rights.
Hopefully some food for thought!
a) at what point is content uploaded to Grammarly. Is it uploaded automatically as you input (if you have the Chrome extension), or is it uploaded only where a user activates the extension. Clearly if the latter, then no one is going to be using Grammarly to check their code so no issue. Even if the former, it's still debatable whether or not the terms of use would even grant rights. It's still limited to content 'in connection with the use of the services or software' - content uploaded passively without any user action (aside from the initial act of installing the extension) doesn't fall neatly into that bracket.
b) The likelihood of Grammarly taking a decision to incorporate third party code into their service or to improve their service on the basis of the license granted in the terms of use is extremely slim. The reputational hit if it were to come out, and the lack of legal certainty over the status of the third party code would both act as a strong disincentive to do this.
"in connection with the provision of the Software and the Services and to improve the algorithms underlying the Software and the Services."
This on the face of it wouldn't extend to selling your content. Obviously terms of use can change, but a material change like granting Grammarly the right to sell content would usually oblige Grammarly to notify users and at that point users could take a decision to stop using the service.
Also, realistically any proposal to sell data would make use of the service for great swathes of enterprise users a complete non-starter.
IP rights: All rights are assigned. Most projects will be more nuanced than this in terms of IP split, both in terms of pre-existing IP and third party/open source IP. Both these are ignored. I would expect there to be more nuance around this. This may give more comfort both to the client and the contractor in terms of knowing what they are getting, and what they are handing over respectively. Also, no mention of moral rights, which you would usually expect to see waived, or at reference to copyleft restrictions.
End dates: This provides an absolute commitment to deliver work by a certain date. I don't think this is advisable from a contractor's perspective. At the very least it should be made subject to timely receipt of client inputs.
Non-solicit: Plain English seems broader than a standard non-solicit. Usually a standard non-solicit would link to employment by the solicited person by the soliciting entity or solicitation being for the benefit of the soliciting party. This just states any action to encourage someone to leave is a breach. Also, it's more normal for this to be reversed so that the client is restricted from soliciting employees of the contractor (obviously not as relevant in a single freelancer scenario though).
Term and termination: Sure, flexibility over termination is a good thing (because if it's not working, it's not working), but giving the contractor the right to terminate on 7 days' notice is likely going to lead to objections from the client, when in most cases the contractor should be willing to commit to a job or at least a longer notice period. On the flip-side, giving a client a termination right on 7 days is more understandable but certainly from a contractor's perspective I think more certainty over contract duration is preferable.
Indemnity: Client -> Contractor indemnity is obviously preferable from a contractor perspective, but any client is going to want to have a reciprocal indemnity, or at least an indemnity in respect of third party IP. Generally considering the client will have leverage, it's important to acknowledge that. Presenting a document with a client only indemnity risks that in my view! In some ways it's probably better not to put the word indemnity in a contract sent to a client, because it'll just make them start thinking about what indemnities they should take from you, and whether or not they should send this to their lawyer/legal department (if they have one).
Jurisdiction: In most jurisdictions, you would get away with these kinds of general legal provisions. However I would usually expect some thought to have been given to local law.
Payment: Giving the contractor the right to add interest to overdue sums is often a powerful tool to ensure you get paid. In the UK at least we have legislation to that effect so it doesn't necessarily need to be stated (but often good to bring to the attention of the client anyway).
Personally, Tachyons still provides me tremendous value even though I sometimes have to write custom classes. I'm also often surprised to find that something that I thought would need a custom class, could be done with Tachyons when I dug a bit deeper.
The new e-Privacy Regulation coming into force next year will however, as presently drafted, provide an exception from consent for analytics programmes that only use gathered data on a per-site basis (so excluding Google Analytics for example).
Obviously each case should be dealt with on its own facts to assess the application of GDPR. In the example you give, GDPR may well apply. Some companies may be worried, others may see it as an opportunity.
I know lots of US SaaS companies are embracing GDPR rather than being worried about it. Clearly if you are looking to get business from EU customers but want to argue GDPR doesn’t apply due to the fact you are not strictly speaking targeting EU users then that might present an issue for certain potential EU customers (or maybe they could offer a cost discount because they haven't had to go through a GDPR compliance exercise). On that basis lots of companies outside the EU are pro-actively looking to comply with GDPR.
Arguments over the appropriateness of extra-territoriality applicability are a separate matter of course!
As to your point, legitimate interests requires a balancing act between your interests and others' interests and so is by its nature going to be uncertain.
If you are looking to rely on legitimate interests, you should look to document your interests that you think are being served through the processing, and also check to see if any other processing bases may be more suitable to achieve your objective. The aim is to at least have a defensible position behind your use of legitimate interests.
Here an example of Facebook listing out their legitimate interests in making use of data:
If I make a purchase from a bespoke banjo shop in Guatemala whose site is in Spanish and prices in Cuetzals that I've stumbled across on the internet then they don't go into scope of GDPR.
Or are you saying that if I went to an ISP with the reduced IP address, they could disclose details of the person, if they only had 1 account within the range of IP addresses that the restricted IP address covered? This doesn't seem particularly likely to me? I thought ISPs hold a block of IPs and dole them out on that basis, and so resulting in only a loose connection between IP address and location?
On large companies, that would be out of scope, because whilst the reduced ISP may be linked to 1 large company, the assumption would be that the large company had multiple employees. On that basis although the account may be linked to a particular employee, no one employee could be singled out because multiple people would be relying on the same base IP potentially I would have thought?
The above link contains a sample Excel template with details of the various information a record of processing should contain. If you are only processing employee data this should be straightforward. It's a link to the ICO, the UK's data protection authority, but it should be useful regardless of where you are (assuming GDPR applies to you of course!).