Does the software we use to write code affect the licenses we must use? I am a junior software developer and found the licensing confusing, partly because senior devs around me have no idea either. Below I explore scenarios where a software developer uses other software. For example, I make up here three cases: Dev uses a Linux Distro, and inside Linux the code editor VSCode, and also runs other programs without ever glancing at the source code - to learn from the output. Dev distributes a program that imports other people's programs Dev only runs software and uses the result of those programs in the code. For the first case, I would assume that my duties are only with the source code, so the first item is fine. For the second one, if you distribute code that uses other people's code, then you should make sure the license is correct, and will depend on which imports you have. For the third one, I am not sure what is the solution, so any clarifications are welcome.
In general, the output of a program is not copyrighted by the author of the program. When you write a novel in Word, Microsoft doesn't own any copyright in your novel. When you prepare financial statements with Excel, Microsoft doesn't own any copyright in those either. There can be exceptions. Some programs (like GNU Bison, a parser generator) actually do output parts of their own source code, and their source code is copyright to the author. To clarify things, GNU made a statement in the license for Bison that officially says they don't have copyright to what it outputs. You should expect programs of this type to have such an exception, and if they don't, maybe ask the author or don't use them.
It does mean that you cannot reuse any parts of the source code, even small simple ones. You would have to rebuild the code from scratch. There is a significant chance that the code would be "substantially similar" to the code that you were hired to build, also that if anybody else were to write a bubble sort or 24-to-am/pm conversion routine, it would look the same, where even variable names (which should describe function) are the same or very similar. In case of an infringement lawsuit, you would have to defend yourself by showing that there are only a few ways to code a given function. Copyright protects only the "expression", not the abstract idea. A linked list is an idea, which can't be protected by copyright; same with recursion, pointers, stacks, object-oriented programming... Anything that involves copy and paste is infringement. If you re-read the copyrighted code and then try to reconstruct it, you probably crossed the infringement line. If you remember the problems and solutions and accidentally write somewhat similar code, that is probably on the safe side. From the perspective of the programmer not wanting to always reinvent the wheel, it would be most useful to make a distinction in the contract between "the essentials of the customer's program" versus "incidental utility work". The difficulty will arise in saying specifically what is essential vs. incidental. For instance, I know that if I were to hire you to develop a speech-recognition system, low-level audio-acquisition and encoding would not be essential to my purpose, whereas DSP parsing routines would be the center of my interest. The programmer would then want to retain recycling rights to all non-essential code.
Your GPL example detracts from the question: see this recent answer. Setting aside GPL-specific conditions, the legal underpinning of software licensing is copyright law, whereby copying source code or an executable is only allowed with the permission of the copyright holder. There are two partial exceptions: "fair use" (generally not relevant to software), and a specific statutory permission to copy software in particular ways (making a backup, plus the act of executing software which requires copying from disk to memory). The latter permission only applies if you have legally acquired a copy of the software. Which explains why nobody sells copies of software, they sell a license to use software (a subtle, legalistic distinction, which is essential to modern software qua business). The terms of the license say what you may and may not do: if you violate the terms, you do not have permission to copy the software, and are liable for copyright infringement. One limit on the terms is that they cannot take away a right that you already have by copyright law (e.g. "fair use" cannot be negated by a license term). Another limit is that the terms have to be consistent with contract law, hence the license cannot include a human centipede obligation – or, "all your stuff belong to us". When a contract is ambiguous, the ambiguity is construed against the writer, and that is also so with software licenses. Also like the situation with contracts, the terms have to be legal, that is, cannot deny some right or requirement encoded in law. There is a legal requirement that disclaimers have to be "prominent", and that holds of license terms. As for "tricking" a person, that's not supposed to happen, with a proper license. If you put stuff out there and say nothing, nobody has been given permission to copy the item. You can make it available to a specific named person, but that is limited to one person, thus a license includes language allowing anyone to copy, but also requiring that the license be retained with any subsequent copies. Hence B copies from A, and sees the license; B may share with C (assuming a decent license) but must include that or substantially equivalent license; and so on. A problem arises if B redistributes without original license, substituting a bogus license. When C copies, that copying is not done with the permission (implied or express) of A, and C could be open to legal consequences. B is also clearly open to consequences, since re-distribution with the self-perpetuating license is a violation of the terms of A's condition grant of permission. Ignorance of the true ownership of copyright is no excuse, and there is no general innocent-infringement exception to copyright law in the US. However, the part of copyright law that talks about remedies for infringement, 17 USC 504(b)(2) lessens the burden on the innocent infringer: In a case where the infringer sustains the burden of proving, and the court finds, that such infringer was not aware and had no reason to believe that his or her acts constituted an infringement of copyright, the court in its discretion may reduce the award of statutory damages to a sum of not less than $200. Still, not zero. I don't see how adding some NOPs would make it impossible to prove that you have a copy of someone else's IP. Perhaps it's not a trivial, but still quite possible.
You can't patent an algorithm, but I'll assume you are talking about the case where you have patented a machine or process that uses an algorithm, but that adds significantly more, and that the software being distributed implements much of this process. Courts might find an implied licence or promissory estoppel when distributing software under an open source licence that doesn't explicitly exclude patent licencing as part of its terms. It would be prudent to state your patent rights and explicitly exclude a patent licence if you intend to enforce your patent rights. As an example, this software implicates a patent , so they allow "permission to use, copy, modify, and distribute this software and its documentation for educational, research, and non-commercial" purposes. Users that want to use the software commercially need to contact the authors who also happen to be the patent owners, and I assume would negotiate a patent licence at that point.
You are free to sell or not to sell to whoever you like (unless it is illegal discrimination, like not selling to white Christians), but it doesn't make a difference, because anyone who buys the software from you can legally sell it on to anyone they want. So you cannot control who ends up owning the software. If I want the software and you don't sell it to me, and I still want it, I'll just ask a friend to buy it and give them the money. Other people would just get a pirated copy if you refuse to sell to them (and would have very little bad conscience since they offered you cash and you refused to take it). You can put terms into a license, and in the USA this is binding. The customer may not agree with the license, and in that case they have the right to get a refund for the software. In the EU, I don't think a license is binding, so you'd have to sign a legally binding contract with the buyer. Apart from all that, you have very little chance to find out if the software is used against your wishes and to do anything about it.
In the EU, software license resale is legal, even if explicitly forbidden by terms of any EULA or other contract imposed upon the parties. To quote the European Court of Justice's press release on its ruling in a case in Germany between Oracle and a German reseller, An author of software cannot oppose the resale of his `used' licences allowing the use of his programs downloaded from the internet. [...] The principle of exhaustion of the distribution right applies not only where the copyright holder markets copies of his software on a material medium (CD-ROM or DVD) but also where he distributes them by means of downloads from his website. Where the copyright holder makes available to his customer a copy – tangible or intangible – and at the same time concludes, in return form payment of a fee, a licence agreement granting the customer the right to use that copy for an unlimited period, that rightholder sells the copy to the customer and thus exhausts his exclusive distribution right. Such a transaction involves a transfer of the right of ownership of the copy. Therefore, even if the license agreement prohibits a further transfer, the rightholder can no longer oppose the resale of that copy. There are many such companies in the EU who resell software legally, including used OEM Windows licenses that are far cheaper than retail copies. This is, in my opinion, a fantastic thing -- but undoubtedly has been behind the trend towards time-limited licenses rather than perpetual ones, which we all arguably suffer from today.
For a large organization, software licensing compliance is a very broad and intractable problem. The licensing environment is very different for the big company than it is for little tiny you. Many large companies are subject to audits by software vendors (i.e. Adobe, Oracle, etc.) in which they have to show licenses purchased for each active seat. There's a whole new INDUSTRY around maintaining license compliance. An employee bringing in their own software and installing it on a company computer complicates this vastly. That is the environment that the question should be considered within. The large company makes the decision somewhere along the way that your individual efficiency in performing your individual tasks is less important than maintaining auditable software licensing compliance. Since they own the computer/laptop/server, it's their decision. Many times it seems that corporate policies as they apply to the individual worker are obstructive and limiting, but there's a bigger picture to the situation.
Yes. This is a frequently asked question on the foundation's homepage, and answered without ambiguity (source): Can I use a Raspberry Pi in a commercial product? This is a very common question, and the answer is yes! Once you have bought a Raspberry Pi, it's yours to do with as you wish. You would be in good company too, as in fact the Raspberry Pi is regularly used and sold for commercial applications third parties. Note that this the default consequence of a contract of sale in all jurisdiction I know of (but I am not a lawyer): The seller does not retain property rights in the particular item, and by the mere selling of the item implies there are no other rights that might prevent the buyer from using it as they wish. Apart from the particular computer now in your property, there are other legal requirements: &quot;Copyleft&quot; softweare: Large parts of the Raspbian software are licensed under &quot;copyleft&quot; licenses (importantly, versions of the General Public License, GPL). These licenses are meant to provide your customers with the means of reproduciing and building upon the &quot;copylefted&quot; software. You will need to provide your customers with the source code to those software items, the tools and documentation needed for building, and a written notice. Your own programs need not be licensed under a &quot;copyleft&quot; license, provided that you don't build on (distribute &quot;derative works&quot; of) &quot;copyleft&quot; software. The open source licenses involved are not meant to exclude commercial use, and there are helpful compliance guides available ( a, b ). Non-free software: Make sure to not include non-free software, like Mathematica or Oracle Java, which are not licensed for commercial redistribution. Trademarks: Your use of the words &quot;Raspberry PI&quot; or the raspberry logo is subject to restrictions, as is usual with trademarks. Speaking of the logos: You can request permission to use their &quot;powered by Raspberry Pi&quot; logo. Market regulations: You need to abide by regulations, for example safety and electromagnetic interference. Repackaging the Pi might mean you'll need to test and recertify your product, I'm not an expert. Video codecs: Some Raspberry Pis (up to 3) include specialised video decoding hardware. If you want to use it with the MPEG2 codec, you'll have to buy an activation key for small one-time fee per device - £2.40 for MPEG2, £1.20 for VC-1; other codecs are already activated. I don't think you'll need a license even for commercial, for-sale devices, but I am not your lawyer. Just to be clear, nothing prevents your buyers from cloning your software. (This is not a consequence of you providing the Raspbian source code - they can just clone the contents of your SD card.) While you can retain copyright in your own code, you'll probably have no effective means of detecting infringement. However, the physical design of the rest of your device will not be affected. Your business model needs to account for this fact.