This piece of computer science was patented - I thought you can&#39;t patent software? See this document This document described storing a tree data structure as xml for querying and processing. This is trivial computer science. How did this patent get approved?
It's not software; it's a "method," which is a type of process. Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof may obtain a patent therefor, subject to the conditions and requirements of this title. 35 USC §101 (Software would be a particular program employing this process, written in a particular programming language and run on a particular hardware platform.) To be protected by patent, an invention must be novel and non-obvious. The patent office doesn't get too deeply into questions of obviousness, however; these will come up when a patent's validity is challenged, for example in court, generally in response to an accusation of patent infringement. If you believe the invention is obvious, and that you could prove that in a court of law, you can use the invention secure in the knowledge that you will prevail when IBM comes after you for patent infringement. If you don't have very deep pockets, however, you might want to think twice about pursuing that strategy.
There is something called the exhaustion doctrine that says that once the holder of a patent sells a patented device, they have relinquished control over that particular instance of the patent implementation. Anyone who legally purchases this hardware has the right to run whatever software they want on it, as long the software is otherwise legal (software designed to defeat DRM would be an example of software that is is not legal).
What you're talking about is called black-box reverse engineering. It can be done, and as long as you are meticulous in your record keeping the fact that it has been done should be an appropriate defence against copyright infringement. But that doesn't help against patent claims - while in copyright cases the fact that code has or has not been directly copied is critical, in patent cases it its irrelevant: if you use a patented method, it's a violation. You therefore will need to be careful about any patents that may have been issued to the original author, as well as avoiding copying.
As far as I can tell, whenever GitHub redistributes code, it adheres to all of the requirements of the GPL/BSD etc. For example, it never gives away code without including the license text, and it doesn't claim to add unpermitted restrictions to the code. The section you're concerned about is this: That means you're giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video). That section isn't worded very precisely, but I understand this to mean they want to reproduce your content in full, not just the code without the license text attached. They want to display your content in full, as you provided it. They want to modify it internally (i.e. they are not redistributing this modified form) in order to allow searching. To the extent that they display code-snippets as search results, that is likely defensible as fair use (search engines are frequently cited as examples of successful fair use defenses). GitHub appears to be acting consistently with the GPL when it reproduces, displays, modifies, and distributes code that you upload. If I'm correct about these facts then nothing that GitHub does with the code goes beyond what the many contributors to a GPL project have explicitly permitted, or what is otherwise permitted by fair use law. If you had some code with a more restrictive license, you might not be able to simultaneously comply with that restrictive license and GitHub's License Grant. Consider the scenario where you have some code that is licensed exclusively to you, and you are not given permission to reproduce or distribute it. In that scenario, the code's license prevents you from agreeing to GitHub's request for a license grant.
In theory "legalese" is English: you will find every word in the dictionary, and the rules of grammar are exactly the same. However in practice it is true that legal documents are often written in a very specific style. There are a number of possible reasons for this: The document must say what it intends very precisely. Most regular language is quite sloppy and ambiguous, but lawyers share with computer programmers the need to ensure that what is said is precisely what is meant. A legal document exists within a legal system in which certain words or phrases carry very specific meanings. For instance in the UK the words "in trust" when talking about money or property will automatically import a huge body of law (and its also possible to have that law apply even if you don't use the magic words). Lawyers know about these things, and will write a document to either invoke or avoid those bodies of law as they see fit. Related to (2) above, laws and legal precedents give lists of things that must be done or proved. Legal documents will often follow these lists using the same terms in order to avoid future challenges. For instance US patent law specifies what must go into a patent application, so you had better follow the format and use the same subject headings. Within patents in particular, the patent office manual allows a patent to be rejected because of informal language that leaves the patent unclear. Patent lawyers and examiners have evolved an informal set of conventions about how things are said. If you use these conventions the examiner will have a much easier time understanding what you mean. Its not "cargo cult", more a specialised language. (Note: the following is about the US patent system, but similar considerations apply everywhere.) Lets take a look at an example patent picked at random: The abstract lists the key elements of the invention in very abstract terms, such as "vibrating mechanism" and "power source". If you were writing this in "informal" language you might mention a specific power source such as a battery. But doing so limits your invention: what if something other than a battery (such as a super-capacitor or spring-driven generator) is used? That would be a separate invention not covered by your patent. So patent lawyers take time to think and ask about generalisations. The next interesting part is the Claims. These set out precisely what is and is not covered by the invention. If the Claims don't cover it then its not in the patent. The format of each Claim is defined in 35 US 112, so if you don't do it like that it won't count. Finally we get to the Description. This is intended to explain the invention to "any person skilled in the art". It also needs to explain the prior art and show why the invention is new and useful, because those are statutory requirements. Much of this is in fact written in an ELI5 way, if the 5-year-old had swallowed a dictionary. The reason is that any little thing omitted or assumed can be used by a future challenger claiming that the hypothetical "person skilled in the art" would have failed to understand or know it. So lets take a sample paragraph from this patent (numbers refer to diagrams in the patent): The electrical connection 22 may include a circuit device that transforms a DC power provided by the power source 26 to AC power for the vibrating mechanism 28, which circuit devices are known to those having ordinary skill in the art of circuit design. This anticipates a possible variation on the invention and stops it being patented separately. It asserts that the "circuit devices" are known, so it doesn't need to describe them in detail. If that assertion wasn't there then someone might challenge the patent on that point, but since the assertion has been accepted by the patent examiner it is presumed to be correct. Note the "... ordinary skill in the art ..." phrase: this is explicitly calling out to the language in Title 35. You might imagine that such a variation would be obvious, and therefore not patentable. However it is very difficult for a court to decide in hindsight whether something would really be obvious to a person skilled in the art; you wind up with each side hiring expert witnesses who will give competing testimony as to whether it seems obvious to them. As a result the courts have set a very low bar to a claim that something is "non-obvious". The language used throughout a patent is of vital importance: infringement cases can hinge on the most trivial of linguistic issues. This blog post by a patent lawyer has a list of examples, including this one: For example, in Chef America, Inc. v. Lamb-Weston, Inc., Chef America tried to protect a cooking step for heating a dough at a certain temperature inside an oven. But Chef America drafted the claim to read “heating the . . . dough to a temperature in the range of about 400 degrees F. to 850 degrees F.” The Federal Circuit reasoned that “to” is not “at” and, thus, the claim required the dough (not the oven) to be heated to the specified temperature. The Court then ruled that the claim was not infringed. In fact, under the Court’s claim construction, this claim could not possibly be infringed unless one wanted to make burned dough. See also this case on "partially" not including "totally", and this post on why the word "disclosure" is now used instead of "invention". Patent lawyers call this kind of thing "patent profanity", i.e things you simply do not say. So if you don't use this kind of "legalese" in your patent the following things are much more likely: Your application will be rejected because the examiner cannot understand exactly what your invention consists of. Trivial variations on your invention will turn out not to be covered. Someone will challenge your patent on the grounds that you didn't explain everything that a "person skilled in the art" might need to know.
If the details of your implementation are not disclosed by the previous patent, and more generally, if they are novel and non-obvious in light of the entire body of prior art (including the previous patent), then you could obtain a patent whose claims are limited to implementations that include (some of) those details. That said, your patent would not exclude the coverage of the previous patent—it is possible for something to be covered by the claims of multiple patents, even patents with different owners. If your implementation is a method that includes every step of a claim of the previous patent, then performing your implementation would still infringe that patent (regardless of the existence of your own patent or patent application). Analogously, if it is a device that includes all of the elements of a claim of the previous patent, it would infringe. Of course, the other patent may not be valid, and so you could seek to invalidate it if desired (but this can involve lengthy &amp; expensive legal proceedings).
If you use the reviewer's code, or code derived from it (e.g. if you just changed a variable name) then they own the copyright on that part of the software. If the reviewer describes a solution which you implement, or if you re-implement the code from scratch while taking ideas and methods from the reviewer's code, then you own the copyright on that code. However if there are only a few ways to implement something in code then the code is not creative and hence cannot be copyrighted. For example the regular expression in the question you link to is (as far as I can tell) the only correct solution to the problem: any programmer addressing the problem will have come up with that RE. In this the position is akin to a database of phone numbers: while the collection may be copyright (depending on whether selection or arrangement required creativity), the fact that Alice Jones has the number 012345 is not copyrightable, and neither is the alphabetical arrangement of names. Where it gets messy is the boundary between the two. The requirement to detect 4 or more repeated digits in a credit card number could be implemented in a number of ways, but whether there are enough of these to qualify any particular solution as "creative" would be a matter of fact for a court to decide.
It's really your client that should be asking these questions. Writing the app is perfectly legal. So you can enter a contract with that client to write the app and deliver it to them, ready to be put on the Google Play store or the App Store (entering a contract needs to be done carefully, obviously). I'd make 100 million percent sure that the contract states clearly that you have zero responsibility if the app is rejected or removed for non-technical reasons, and that the legality of actually selling and running the app is also not your responsibility. The reason is that I very much suspect that running the app might be illegal, and that the chances of getting it permanently on one of the stores are rather slim. And solving those problems is outside of what a software developer can competently do.