Software patents implications and ramifications to the end user Software patents affect a small part of the world. As a citizen of a state, where software patents are not a thing, I am personally not concerned with that. However, as a developer I am concerned with my clients, as many of them are citizens in states, where software patents are a thing. The question is about the liability of the end user - are end users potential targets for prosecution on basis of software patents, if they use software that "infringes" on a local software patent? I do understand that if I was a citizen of such a state, I'd have legal problems with releasing such software, but the question is strictly about the end user. Is there any difference between proprietary and open source applications? Lastly, and I don't know if it makes a difference, but I am not talking about stealing source code, but engineering something that has been engineered over and over again, until someone happened to patent it, not necessarily and usually not the first one to think of it. EDIT: Care to explain those anonymous downvotes? No constructive criticism? Or is it just genuinely a bad thing to be concerned with your customers?
At least in theory an end user could be sued for infringing on a patent, especially a method claim. Given the cost of a patent lawsuit, this strikes me as extremely unlikely to happen though, unless the user in question were an extremely large company, or something on that order. Theoretically, the only difference between open-source software and proprietary software would be that availability of the source code makes it easier to prove use of a patent in open-source software. Releasing the software as open-source doesn't confer any immunity from patent law or anything like that though. Realistically, however, the chances of being sued for infringement if you're basically giving away the software in question are fairly remote. It rarely makes sense for a patent holder to spend millions of dollars on a lawsuit where they stand no chance of even recovering their cost (but no, that certainly should not be taken as legal advice that you're free to infringe on patents, or anything similar--in fact, none of this should be taken as legal advice at all). If you can actually prove that a technique was published or publicly known and used (e.g., in a product that was offered for sale) well before the patent was applied for, the patent is probably invalid (and if proven so in court, the case would normally be dismissed with prejudice, which basically means the patent holder wouldn't be able to sue anybody else for infringement of that patent). I'd note, however, that in my experience this is much less common than most people imagine--many look at (for example) the title of a patent, and assume it lacks originality because it refers to some well-known technique, and ignore the claims where it details the precise differences between the previously known technique and what the patent really covers. Just for example, the EFF used to have a web page talking about a (now long-since expired) patent on how to draw a cursor on screen. In an apparent attempt at scaring the unwary, they showed code they claimed infringed in the patent--despite the fact that the patent's "background of the invention" specifically cited the technique they showed as being previously known, and not covered by the patent.
Yep, you are. You still need to keep the LICENSE and NOTICE files in the repository, if there were any in your copy of the project. These files contain the terms and conditions for the project, and provide attribution to the original developers. If you're trying to attribute in the UI of your application, you probably should. It's considered courteous and in the spirit of open source as well. This is also related: Do I need to include the full text of the MIT license in the UI of my app?
My question is, because I am not making any income from the distribution of the game, would the use of the copyrighted music fall under Personal Use? There are some &quot;private use&quot; exemptions in Australian copyright law but they have some fairly narrow conditions. These exemptions are fairly narrow because the point of copyright law is not to prevent you from making money with someone else's intellectual property but to protect the other person's ability to make money with it. If Alice writes a song and Bob distributes it free of charge, Alice loses revenue. Similarly, it is Alice's right to decide whether that song should be included in a freely available open-source software product, and her right to decide whether to allow that use without charge or in exchange for a license fee.
The UK Government released an article last year that explains some of the issues relating to ownership of copyright This article is informative. The headline point: Ownership of literary, dramatic, musical, artistic and film works created by an employee during the course of their employment, automatically vests in their employer by virtue of section 11(2) of the Copyright, Designs and Patents Act 1988. The meaning of during the course of their employment has been interpreted by the courts to mean during the course of normal or specifically assigned duties, and that these duties include the creation of intellectual property for the employer. Patents are similarly affected - if the role does not specify or would not imply the creation of patents and other IP, it may not vest in the company automatically. This is a standard clause and is designed to protect the interests of the company, in the event that you create intellectual property as part of your role. Bear in mind here that there's no real need for this property to be created during work hours. That is, if part of your role is to design new software, ownership of that software vests in the company, whether you spent substantial amounts of work hours making it or not. Conversely, if your role does not include, or would be expected to include, the creation of intellectual property, then if you do so - even if it is during work hours - ownership may not necessarily vest in the company. IP you create in the course of your employment will vest in the company in the course of your employment will probably mean: if you are employed to create IP generally, all any IP resulting from your work, or; if you are employed to create a specific work, that work and possibly related works. This is a fairly standard clause, for most companies - I have had several jobs (though none of them technology-related) and they all include some clause to this effect
Unless you have a legally valid IP right related to the specification that statement is meaningless. When a software license is granted it is based on the copyright of the code. The copyright of the spec. just stops people from copying the spec - it does not protect the information in it. You can restrict copying of the spec. under copyright, you can make up a name for the spec (like USB or Bluetooth) and get a trademark and only allow the trademark use in limited cases(doesn’t stop implementation of the spec), or get a patent that would be necessarily infringed if something complying with the spec was created and used, sold, made, etc. or you can keep it secret and only show it to people who contractually agreed with your terms.
Why do you think Oracle have not been protecting their trade mark? Using a trade mark to describe the product (“Written in JavaScript”, “Seeking JavaScript developer”) is not an infringement and the trade mark owner is under no obligation to, indeed, cannot stop this. Where they are required to defend their trade mark is when it is being used in such a way that there is the risk of confusion that the goods or services could be confused with the trade mark owner’s goods or services. Further, they are not required to defend all breaches, only enough to show that they are actively doing so. Also it is not important that the trade mark be associated with the trade mark’s owner. Do you know who owns the trade mark “Ben &amp; Jerry’s”?
How can you get in trouble? If they see any code you wrote for them show up in your open source project. They own the code you write on company time. Even if your code goes into an open source project owned by the company, you still don't own that code. The only way you can own it is if they directly tell you that you may put it into your open source project. If you make your open source project private so nobody else can see the source code, but they see your side business has the same features you wrote for them. You can try to get around problem #1 by hiding your open source project. But if they see the same features in it that they told you to write for them, they can become suspicious. They might force you to reveal the source to them in court. If you don't want them to see it, they may force you to share it with a third party who is bound by an NDA. The third party can compare your code to theirs and report if you copied any code. Even if your work is not directly related to the company products, your work for them can be a company secret. You reveal that, and you are in trouble. You say your work improves internal procedures, but is not directly related the company products. If a company can reduce its cost, it can lower its prices and still make more money than their competition. That gives them a competitive edge over other businesses. By revealing how your employer does its internal work, you give that competitive edge to their competition. Although you say your open source project does not violate rule #4 - "does not reveal company secrets" - all three explanations mentioned above say it does. What can you do? Quit and start your own company based on your open source project. If you quit, you should do it before you write any code related to your project for your employer. Ask your company to fund your project. Talk to your boss and anybody else there who might be a stakeholder. Tell them what you can do. Make a deal with them that you get to work on your project during work hours. Maybe they could turn it into an additional source of revenue for the company. That changes you from a potential loss into a valuable asset. Their competitors might end up buying products based on your code. Many companies would love for their competition to pay them. Ask your employer to allow you to turn your work into your open source project. Some companies require employees who work on open source projects to give their employers a royalty-free license to use and modify the work as they wish. Ask your employer if they would use a product based on your project. You can start a side business (with your employer's blessing), and turn them into your first customer. They get access to a beta product before their competitors do. Promise them they get it free or at a hefty discount for a year or two before the competition even knows what you have. The first option is win/lose. You win and your employer loses. The other three options are win/win. Good luck!
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.