2 companies, some shared source code, 1 company gets sold - who owns what? We have two software companies. Company A was formed 15 years ago. Company B was formed a year ago. These two companies do not compete, but they both access certain external APIs and massage similar data. 99.8% of the source code between these 2 companies is separate and different (even different languages/tech stack), but we did share some code to import in some data files to a DB, and access some public APIs. Both company A and B have upgraded these shared files over the last year, although company A originally created them (of course). We are now selling company A (talks completed, preliminary agreements signed, just waiting for official paperwork to be prepared and to meet in a few days to sign). The group that is buying our company A is aware of company B, and we have a non-compete, even though we don't have competing products. As we were preparing to package up all the source code for company A, we realized there were these little utility/import files that were also in company B's repository, and company B is dependent on them. These "utility" source files are not by any means the "core" of either app. However, company B does not have time to clean-room rewrite these files, plus we have to go through re-certification with the API owners if we change our source code (which takes time). We don't want to stall or risk the sale of company A, but we want to stay within the US law. So in a situation like this, are these little utility files shared IP? Is there something we can do before the sale ends to protect us, such as company A selling a branch of these files to company B? We want to be honest but we don't want to open up a can of worms right before the close of sale, because we are worried that it might cause panic where there is not cause for any. Any precedents or thoughts here? Thank you.
Tell whatever lawyer is drafting the "official paperwork" about the problem and ask if it is covered or if you need to change the text or add a rider. If neither company competes, a mutual release/license of existing shared code should be perfectly manageable for an experienced attorney.
You would have to look at your contract with the company or the company's rules. Some companies have clauses that say they own things you develop while working for them and some don't. Without knowing your specific company's policy, it is impossible to say.
First off: Legally, everything is copyrighted anyway. Licensing is not at all necessary. Hence, even if a court would disagree with # SPDX-License-Identifier: Apache-2.0, that would just make it closed source. Having said that, the law generally doesn't bother with trivialities such as &quot;file headers&quot;. Any commonly accepted way to state the copyright and license terms is OK. Your LICENSE is such a common convention. If you want to avoid all doubt what is covered under that license, put a reference to that LICENSE in each header. If you have just five files in one directory that are all licensed the same, I wouldn't even bother with that. Again, the default position is that everything is closed source.
we would like to know whether we have sufficient legal grounds to sever/terminate/exit this contract with Superior Management Co.*, if the company does not mutually agree to do so. No. In that event the HOA is stuck with the contract at least for the remaining part of the current period. The HOA's concern that the provider could breach the contract by significantly underperforming seems speculative and does not entitle the HOA to breach it first. Changes in the name and/or ownership of a party does not alter the parties' rights and obligations pursuant to the contract. This implies that neither party is entitled to disavow his obligations by terminating the contract altogether. For early &amp; unilateral termination to be an option, it would have to be provided in the terms of the contract itself.
It would be terribly risky for you to simply link another company's terms of service. What if they take their server down? What if they change their terms? You would not even know when exactly the changes were made. Copying their terms means you might run into copyright issues on the text. Either pay a lawyer to write your ToS for you, or see if you can find something in the public domain.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
You say the permission was "public", therefore I am going to assume that it cannot be argued that there was no agreement. There are two possibilities: If Company B has given consideration for the promise then there is a binding contract and Company A may be able to end it but could not seek redress for when it was in place. If there is no contract then the principle of promissory estoppel should have essentially the same effect. An agreement, including an IP licence, does not have to be in writing nor does it have to have any particular form.
You could establish your own server which calls the API and maintains a counter, and have al your applications call that server, the server call the API, and the server can also return a count to the application, or even return a failure code if the count is too high. As for when the count turns over, a few days experiment should establish that, but given that the API is based in the EU, I would guess it turns over at midnight UTC (aka Greenwich mean time), but of course that is only a guess. Has the API management declined even to tell when the count rolls over? That seems odd. As to the legal obligations of the API management, it would be good practice for them to have the API return a count, but I don't see that they can be required to do that. I don't know of (and could not find) any law which mandates such a count. I do think that they should inform you of the time of day at which they roll the count over. I have not yet found a law which specifically requires this.