Do I have to update old jQuery Libraries to prevent my source code from being GPL? I'm trying to reuse some old source code in what is going to be a commercial web application. This old code was made using jQuery 1.2.1, which is dual licensed under the MIT and GPL licenses. I've seen that recently, jQuery has got rid of the GPL licence and now it's only MIT. I rather not use newer versions since I'd have to test the code again to make sure no bugs were added. So, Does this change of licence affect old versions of jQuery? I mean, if jQuery 1.12 is MIT only, does that remove GPL from jQuery 1.2.1? Most importantly, does this put my code under GPL? Do I have to update old jQuery Libraries to prevent my source code from being GPL? Thanks in advance.
Just because newer versions of jQuery are available under one license doesn't indicate what license(s) older versions are available under. With permission of all copyright holders, the license can be modified. However, it does require the permission of all copyright holders. You would have to see the license terms distributed with jQuery 1.2.1 to see what license(s) that particular version is under. However, the GPL doesn't impact you in this case, since the library is dual licensed. As the recipient, get to choose the license that you wish to comply with. In this example, you can choose to comply with either the GPL license or the MIT license. Since the MIT license is easier for you to comply with, you simply need to conform to the terms of that license in your application.
The DMCA prohibits circumvention of technological measures that effectively control access to a copyrighted work. So you can't legally "crack" the software, period -- even if you own a disc containing the software and have a valid license to use it, a license to use the work is not authorization to circumvent access controls. So if the disc is copy-protected, by my understanding of the DMCA, you're kinda screwed. (The company might be willing to provide you a replacement copy, even if only to maintain the illusion that the software is "licensed, not sold". But you can't make one yourself.) Likewise, if you have a copy of the disc but have lost the license key, you're screwed. Even if you could prove beyond any doubt that you are the licensee, there's not any law i'm aware of that would compel the copyright owner to provide you another license key. And courts have held that distribution of license keys without authorization is a violation of the DMCA. So whoever might provide you another key, if they're not the copyright holder, has broken the law. If you managed to copy the disc from a friend (without circumventing any kind of copy protection), and had your own license key, you might be in a better position. Many EULAs allow you to make a backup copy. Even if they didn't, copyright law does, so there's a possible case for fair use.
Broadly speaking, the difference is the "sharealike" clause of CC-BY-SA. Any derivative of a CC-BY-SA work must itself be licensed CC-BY-SA, whereas a derivative of an "MIT with attribution" work can be under any license the author wants. There are a number of other differences in the fine print (eg. CC forbids DRM, where MIT doesn't), but that's the big one.
Being or not being open source makes fairly little difference in trademark law. If a commercial firm (Yoyodyne, say) had used the name &quot;Portable Network Graphics&quot; and the abbreviation &quot;PNG&quot; in trade, and taken such further steps as would be needed to protect it in the relevant countries, that firm would have a protectable trademark. Note that in some countries, a trademark must be registered to have any protection at all (much of the EU follows this rule). In others, use in commerce can offer some protection even without registration (the US follows this rule). Had this happened (in an alternate reality) Yoyodyne could have sent a cease and desist letter when open source developers started using the mark. If the devs did not cease, Yoyodyne might have obtained an injunction, or damages for trademark infringement, or both. They could also have issued a takedown notie to the site hosting the project. But had Yoyodyne failed to defend the mark effectively and allowed it to become generic, Yoyodyne might have lost all rights to it. Also, had Yoyodyne ceased to use it in trade for a significant period, they might have lost rights. This is a place where the different laws in different countries might lead to different results. Note that &quot;Portable Network Graphics&quot; is rather descriptive, and not particularly distinctive. Descriptive marks, like &quot;Tasty Pizza&quot; generally get weaker protection, while more distinctive marks, such as &quot;LuAnn's Tastee Pizza&quot; are more strongly protected, in general. Again this depends on the country, and the specific facts. In general the first to use, or to register a mark, gets the rights. When one entity is the first to use, but a different one is first to register, things can get confusing, and results will be different in different countries. Note that a Cease and Desist letter is not a legal requirement. It is a threat of possible future legal action, and often an offer to avoid such action if the recipient does as the sender requests. The recipient can comply with the letter, wait for court action, or try to make some sort of compromise deal. Open source projects, as other answers suggest, often choose to comply.
It seems that you don’t understand what parody is. If you do understand, please explain how it’s even possible to parody computer code. What you can do with “open source” code depends on the licence the copyright holder(s) release it under. For some very permissive licences you can do what you suggest, for most, you can’t.
You are concerned that your application is somehow a derivative work of MariaDB and therefore subject to the GPL. It's not totally clear to me whether that is the case or not. But it doesn't matter, because you are not distributing MariaDB itself (or any other part of your application). You're running it on a server which users are connecting to remotely. From MariaDB's licensing FAQ: Internal usage is free The GPL license only affects code that you distribute to other parties. Internal usage within an organization is totally free and not subject to any conditions. There is no such thing as 'internal distribution' that would restrict the usage of your code by requiring it to be GPLed. Connecting to a remote service that runs MariaDB (or any other GPL software) in the background is also free. For internal programs for which you own all the copyright(s), there is essentially no risk in using GPL software. The argument you can use in your defense is that if the software became GPL as part of the distribution, you as the copyright holder could immediately revert your part back to its original copyright. No one has the right to require you to reveal or redistribute your code to the outside of your organization even if you would have distributed it internally linked with GPL software! If your lawyers are concerned about distributions of software linked with GPL libraries between different legal entities within your organization, you can solve this by distributing your components and the GPL software separately, and have your other entity combining them. You can also switch to use the new LGPL client libraries. The use you have described in your question clearly falls into this case, and the presence of this FAQ item clearly demonstrates that the MariaDB developers intended to allow you to do this. The Free Software Foundation (the people who wrote the GPL) agree with this position for both unmodified copies and derivative works. Technically, you don't need a license to &quot;use&quot; a piece of software at all, assuming you have lawfully obtained it. But you're concerned about the possibility of creating a derivative work, for which a license is required. Fortunately, the GPL doesn't care about derivative works so long as they are not distributed.
Company B has created a derived work from company A's copyright-protected work, so yes, B has infringed on A's copyright. It might be difficult for A to prove it, however, so B might get away with it, but it's still infringement. On the other hand, if B creates software that behaves like A's through reverse engineering, that is, by examining the program's function without examining its code, then they will not have infringed the copyright in the code.
To use an API over a network connection (as opposed to, e.g., the Windows API), a user communicates a request to the API host, or server, and awaits a response. The host of the remote API can refuse to serve requests from users for probably any reason. Such services often require users to accept a license as a condition of using the service, and they may charge a fee as a condition of the license. A license to use a service is obviously not necessarily bound to a license for the use of its source code, just as the ability to reach the service is not dependent on the ability to see (let alone use) the code in any format, whether it be the source code or some compiled form of the code. In essence, source licenses and service licenses have different primary goals, at least inasmuch as the source license seeks to restrict someone who has actual physical access to compiled code, and possibly source code. Service licenses do not have that concern, though I have seen service licenses that also prohibit decompiling. This is probably the result of a CYA attitude among lawyers: the language is already in the standard software license text, and it doesn't hurt anything to leave it in, and it could help if a service user somehow managed to download the program code.