Do I need to take any legal precautions for my stock prediction app? Suppose that a developer (D) creates an app that lets users enter a ticker and get an estimate for its future price. No other advice on whether to buy or sell will be displayed; only the forecasted price and some sort of error bounds will be shown to the user. D plans on initially releasing the app for free. In the future D may have a free version (with ads) and a paid version (one-time fee) that gives a user extra filters, but the base functionality will remain the same. Does any of this sound like &quot;financial advice&quot; that D needs some sort of license for? Suppose that D is based in the UK. Related question
Here be dragons Financial services regulation is very complicated. Non-compliance can have severe consequences. Professional legal counsel could assist in navigating the complex web of law, regulation, and precedent. It may seem unfair that things are so difficult - that's a result of financial services being inherently complicated topics, ones which are fought over by wealthy people/firms, and where there has been a long history of dodgy dealings of many kinds. As an example of the difficulties involved, the law in general would like to distinguish between Investment advice given to a specific individual, taking all their personal circumstances and wishes into account, and Newspaper reports giving dispassionate information to the general public about the movement of share prices, but not telling them what to do in response; or completely generic advice like &quot;it's good when the wiggly line goes up&quot;. The second is &quot;meant&quot; to be basically OK and not the concern of the regulators; the first one is where all kinds of legal duties and protections come into play, since people might be disadvantaged by advisors who are inept or unscrupulous. Intuitively, D's app is somewhere between these, because it's not as if users are sitting down with a financial advisor and making trades, but they're also not just consuming generic data like a stock ticker. There is an element of prediction, expressing a range of envisaged outcomes, and potentially with &quot;extra filters&quot; that add some more personalization. So what does the law say about this? Just looking at the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001, Part II Chapter 12 and its form after two decades of tweaking tells us that there is a lot of complicated detail just in this regulation. We don't have to read or understand the words to see that there are a lot more of them, taking the apparently simple distinction above and trying to capture or carve out a range of activities not originally envisaged. If we do start looking at the actual words, we can see several concepts that become relevant - &quot;advice on the merits&quot;, &quot;leading or enabling persons to buy or sell&quot;, and so on. These, and their predecessor words in older laws, have been thrashed out in the courts in ways that are not completely obvious. A recent case in the Court of Appeal, Adams v Options Personal Pensions UK LLP [2021] EWCA Civ 474, looks at some of this territory in paragraphs 69-82. We see here some phrases about whether the context of the information presented includes elements of comparison, evaluation, or persuasion; influencing the decision of the recipient as a result of a value judgement; giving purely factual information as opposed to matters such as a characterization of risk; and others. But, as quoted here from another decision, Rubenstein v HSBC Bank plc [2011] EWHC 2304 (QB), &quot;To attempt any greater definition of the giving of advice in an investment context would be unwise and is probably impossible&quot;, which tells us that it's not easy to decide whether developer D's app is in or out. You say &quot;the app won't instruct users whether to buy or not&quot; but courts have found a concept of &quot;implied advice&quot;, where the context of the giving of information means that the customer will take it as advice. In Australia, the Federal Court recently found an implied recommendation, amounting to personal advice, had been given in a certain situation when customers were told supposedly general advice - even though there was an up-front disclaimer (ASIC v Westpac [2019] FCAFC 187). The specific law and facts are not the same as in this question, but the observation holds that disclaimers may not help if the surrounding marketing is communicating something else. Similar remarks apply to the predictive model, where there is also plenty of regulation. In the FCA's Conduct of Business Sourcebook 4.5A.14, for example, there are binding rules about information on future performance. Whether these rules apply to what D is doing, and how they can comply, are hard questions. There is an entire publication, the Perimeter Guidance Manual, about how to know whether someone is covered by the regulator, but even that is full of maybes. Aside from concerns with the regulators themselves, users may be very upset with D from time to time, and their anger might spill over into a legal claim. There is, again, a large body of law to do with such topics as negligence in giving investment advice. All of the above is evidence that the question of compliance for a particular app or business is not completely simple. Professional advice can look at the whole context, as well as relevant law, and assist D in understanding their options.
The simple way is to post a picture of you and the widget to a site like Flickr. A more expensive way (but with rather more weight) is to get a Notary to certify they saw you and the widget on January 9th. Both the above provide evidence you had access to the widget before January 10th, but neither prove you owned it. For that, you would need a dated (possibly even notarized) bill of sale or similar - but if you acquired the widget via a gift, that won't work. A signed witness statement from the giver would probably serve (and the statement could legitimately be created when you are prosecuted). None of the above are unforgeable - but you don't need that. Depending on how the law is written, you will only need to show ownership on the balance of probabilities, or you might only need to show reasonable doubt that you didn't own it on 9th January.
This is not &quot;unfair competition&quot;. You are allowed to ask people for their views and take them into account in designing software, even with the specific intent that it compete successfully with existing software. In the US you have a protected right to do that under the First Amendment. If the chat site where you asked is run by the developer or owners of the app, they can ask you to avoid such question there, and even ban you from the site if they choose, because it is their site. But if you went onto a public site (like Stack Exchange, say, or Quora) the app owners would have no right to insist that you not ask for such opinions. The degree to which the design or interface of an app or other software may be protected against imitation is a complex one, and depends on the country involved. But widely known and used features such as a 'like' button, message threading, or a comment section are almost surely not protectable. Listening to users of existing simile products and getting their ideas on what works well and what is lacking is generally a good idea, and is in no way &quot;unfair&quot;.
Update (12/2/16) - Just received the following confirmation from Apple Export Compliance: The [redacted] app presently uploaded into your account CAN BE legally released to US and Canada only, it will not be necessary to go through Export Regulations. They have also rephrased the question "Does your app qualify for any of the exemptions...?" to the following: Does your app meet any of the following: (a) Qualifies for one or more exemptions provided under category 5 part 2, (b) Use of encryption is limited to encryption within the operating system (iOS or macOS), (c) Only makes call(s) over HTTPS, (d) App is made available only in the U.S. and/or Canada. Update (12/1/16) - In addition to the research below, a list of "Sample Scenarios" are given in iTunes Connect Resources and Help, one of which states: A developer chooses to release his app in the U.S. and Canada only. -- No U.S. CCATS or ERN is required. No France Import Declaration is required. The following statement (mentioned earlier in the same page) should also be taken into consideration regarding exemptions: All liabilities associated with misinterpretation of the export regulations or claiming exemption inaccurately are borne by owners and developers of the apps. So it appears the correct answer is likely not: N.B. to Note 3 (Cryptography Note): You must submit a classification request or self classification report to BIS for mass market encryption commodities and software eligible for the Cryptography Note employing a key length greater than 64 bits for the symmetric algorithm ... in accordance with the requirements of § 740.17(b) of the EAR in order to be released from the “EI” and “NS” controls of ECCN 5A002 or 5D002. Furthermore, under Note 4: Category 5 - Part 2 does not apply to items incorporating or using "cryptography" and meeting all of the following: a. The primary function or set of functions is not any of the following: “Information security”; A computer, including operating systems, parts and components therefor; Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights management or medical records management); or Networking (includes operation, administration, management and provisioning); b. The cryptographic functionality is limited to supporting their primary function or set of functions; and c. When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter's country in order to ascertain compliance with conditions described in paragraphs a. and b. above. I suppose there could be clarification under this note, but if I understand it correctly, an iOS app having the sole purpose of performing symmetric encryption with keys greater than 56 bits would have the primary function of: "Information security" Being "a computer" Barring clarification on these points that would qualify for exemption, NLR, etc. self-classification would likely be [any of the following]: 5D002.a.1.a (software) - Designed or modified to use "cryptography" employing digital techniques performing any cryptographic function other than authentication, digital signature, or execution of copy-protected "software," and having ... A "symmetric algorithm" employing a key length in excess of 56-bits Encryption registration may have also been required prior to September 20, 2016 (see linked reference). "Companies no longer are required to submit an encryption registration to BIS before self-classifying and exporting certain encryption items..." (Wiley Rein LLP) References: Commerce Control List: Category 5 Part 2 (Cryptographic "Information Security") - BIS Export Compliance - f5 License Exception ENC (740.17) - BIS Information Security Updates (September 20, 2016) BIS Publishes New Encryption Rule - Wiley Rein LLP
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.
The line they'll rely on for GDPR compliance is the first part of that sentence - "If you agree to this during the order process", which suggests that there will be a separate request to opt in to marketing communications at some other time in the process. Check any order documents. There's likely to be a tick box or similar on at least one. If that implies opting out rather than opting in there may be grounds to argue with that under GDPR, but there's nothing in the quoted text that suggests a problem.
Probably not. There are potential problems on the levels of copyright, data protection, and the Youtube terms of service. You should assume that comments are typically covered by copyright. You do not have a license to these comments, only YouTube does. Therefore, YouTube can show the comments but you can't copy them – just like YouTube can stream your videos but others can't download them and host them on their own websites. To cover the copyright angle, you'd either need to obtain a license from the commenters, or get a sub-license from YouTube, or identify a suitable copyright exception. The comments are personal data within the meaning of the GDPR, so that your processing of these comments (including mere storage) would be subject to GDPR as well. You need a legal basis for processing personal data. Which legal basis is suitable would depend on the purpose of processing, and on your relationship with the commenters. Potentially applicable legal bases in this context: you have a contract with the commenters that requires you to show the comments on your website. For example, I could see such a contract if there were a “featured comment” perk for a Patreon subscription. But this is not going to fly with random commenters. you have a legitimate interest (LI) that allows the processing. A LI requires that you conduct a balancing test where you weigh this interest against the commenter's rights. This is very specific to the purposes for which you want to show the comments. However, a LI will generally only apply if you have an existing relationship with the commenters, making it possible for them to expect that this processing will occur – unlikely if you'll be scraping comments from YouTube. you have obtained consent from the data subject. Consent must be specific, informed, freely given, and unambiguous – you can't obtain consent by writing “by commenting under this video you consent to XXX” in the video description. Regardless of legal basis, you would have to inform the commenters under Art 14 GDPR when you scrape their comments from the platform. Finally, consider the platform terms of service. I have not read the YouTube ToS recently, so I don't know what their specific conditions are. But in general, such ToS will not allow you to scrape content from their platform in order to host it somewhere else. The ToS might allow certain actions like embedding a link/iframe to such videos on other sites, without allowing other actions such as copying other user's content to your site.
Having done a bit of brief research, I find that "legit" is a synonym for "good". So, no. The header announcing a "principal amount" serves no purpose and could be misinterpreted as indicating that there is a loan. There is no reason to indicate the date twice, which gives rise to two different values of "date". The phrase "For value received" can be interpreted in at least two ways, one being "in exchange for some unspecified value to be received at some future date by Promisor", and "in exchange for a specific value already received by Promisor". Under the later interpretation, Promis(s)ee probably could not breach but under the former, Promis(s)ee could. So it makes a difference. You can just pay to the Promis(s)ee, and not imply that you are creating a pay-to-order instrument such as a check. That still leaves you the option to pay with a check. Or was the intent to say "pay on demand"? The expression "the sum of £500 shall the Promisor fail to meet his target" is not grammatical in US English, and I'll leave it to a UK speaker to judge if this is, over there. I assume that this is supposed to express conditionality, in which case "if" is a useful term. Then the meat of the contract, I guess, is that if the Promisor fails to meet somebody's target of 47.5 work hours per week, then Promisor has to pay Promissee £500 (and not otherwise). It's really not clear how anyone would know whether "meet a target of 47.5 work hours per week" has come to pass. Does that mean "work at least 47.5 hours per week"? Does that mean "for each of the three weeks within the time period" (or did you mean "work 47.5 hours within some one week, within the 3 week period"). Being explicit that the work obligation extends for 3 weeks would be legit (vide supra). Supposing that the second clause means "Promisor will pay £500 by 5:00pm 2 July 2016", you should put it that way. Or if you mean "Promisor will pay £500 by 5:00pm 3 July 2016", say that. Deadlines for performance should be stated very directly and clearly, and require no calculation and interpretation. And I'd suggest including a clause stating that "Promissor" and "Promisor" are used interchangeably in this contract. Or else be consistent in spelling. Note that almost any contract can be given some interpretation. From the perspective of creating a contract, the first concern should be over clearly expressing the intentions of the two parties in written form. After all, you don't have a contract if there is no meeting of the minds.