grabeh

Painful. Stopped reading after first few paragraphs.

Interesting! A rather cynical approach. Although preferable to naivety on my part - I'd expect a court to hold the list exhaustive if challenged.

No, that is true. There are multiple interpretations here. I gave the most optimistic one!

Why would they single out those specific uses then, if you consider express prohibitions are necessary?

Key word is "may" be completely irrelevant! Of course, if you're providing an Excel of customer data, it will be relevant if the user is in the EU. But still, consent won't be relevant in that context.

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.

GDPR and indeed any data protection laws may well be completely irrelevant in the context of Microsoft's services. Even if relevant, consent is unlikely to be a relevant as a processing basis under GDPR in the context of usage of MS services. Performance of contract or legitimate interests much more likely to be relevant...

To an extent, think about vested interests here. Mozilla has little to gain by showcasing how clear a rival's new service agreement is!

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.

Reminds me of the quote: "The death of one man is a tragedy, the death of millions is a statistic"

But a unique identifier doesn't necessarily identify a living person, particularly in isolation. It's just that it's frequently associated with a load of additional information that could eventually be used to identify someone (think advertising cookies when associated with a load of browsing data). So you can't escape from scope by saying you're using a unique ID rather than a name.

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).

We do see a few references to cookies in the ePrivacy Directive but absolutely right to drive home the point that it's technology agnostic!

Love the contrast between the title and the text. This isn't even about GDPR, it's about a completely different piece of legislation, the E-Privacy Directive. This is completely agnostic on personal data and so the post is largely flawed.

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...

I wouldn't trust any article that purports to be about GDPR that uses the term 'PII' a term which itself isn't anywhere to be seen in the regulation!

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.

Yes, of course. I was just explaining why I thought you'd misinterpreted the original poster's comment.

No, they're implying that there's been a failure by pro-leavers to acknowledge that many of these roles have been in the recent past been performed by immigrants from Europe.

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...

https://www.mbg.codes/

Built with Gatsby, MDX and Theme UI. Yes, overkill!

The concept of processing necessary for the performance of a contract is interpreted extremely narrowly by data protection law. Rightly so, because otherwise it would give entities far too much latitude to stuff as many different processing activities as possible within that ground, even though certain processing activities aren't at all necessary to provide the service.

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.

I would strongly recommend assignment to the company. As you allude to, any investor will want to see core IP in the ownership of the company, and to not have this, even in the presence of a cast-iron license agreement, will be off putting.

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!

For sure - that was my thinking on the alternative scenario. If that happens then that certainly changes the picture somewhat although my other points remain true around what Grammarly would decide to do with that content I would say!

I think there's a few points:

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.

The rights Grammarly (https://www.grammarly.com/terms) take to use your data is limited as follows:

"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.

Is this being shared with a view to getting more contributors or is it being shared with a view to it actually being used at the moment? If the latter, I would have serious reservations if someone put this in front of me and asked me to sign, whether from a client or contractor perspective. If you're going to ask the client to use their time to read this, it's good to present something which isn't so one-sided in favour of the contractor. They'll probably just send over their standard form and get you to sign. Instead you could present something balanced which a client might actually be inclined to enter into.

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).

I think the point is that Tachyons should be good for 90/95% of the styling you want to apply to the site. I think the creator would be the first to say that if you need something specific which Tachyons can't do you should do that but it doesn't make Tachyons redundant.

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.

Thanks! Although I gotta say that they offer no options in relation to analytics cookies which is technically in breach of the e-Privacy directive as those cookies are not strictly necessary here. There are a few cookie solutions that can be used here - BT.com has a decent user flow.

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).

It may be a good policy, but this is unrelated to the point on cookie consent made in the parent post. In fact the Juro site uses a variety of analytics cookies without even having a cookie banner in place, let alone any granular system for managing cookie consent.

Heh, apologies for not being more insightful! I was simply rebutting your point over the GDPR applying once you’ve made a few sales to customers in the EU which is not the case on those facts alone.

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!

Yes, that's right. Are you implying that our notional Guatemalan banjo seller is monitoring the behaviour of EU based subjects? I confess I was working on the basis that out the two potential options, Art 3(2)(b) would be inapplicable here, but you may know more than me about their activities!

Legitimate interests and consent should be the two processing grounds that you rely on as a last resort here.

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:

https://www.facebook.com/about/privacy/legal_bases

GDPR applicability for those outside the EU still requires at least some active targeting of users (website in EU languages, currencies) in the EU rather than EU users passively coming to your website to purchase.

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.

If your reference to 'you' means someone running a site who only has possession of a reduced IP address, then how would connection work?

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?

https://ico.org.uk/for-organisations/guide-to-the-general-da...

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!).