Is creating a new GPS trace a derivative work while using GPS-based ADAS? There is a database of precise GPS traces. A trace from this database can be used in an Advanced driver-assistance system to help keep the vehicle in its lane. The vehicle in question is driven by a human driver. Another precise GPS trace of vehicle's trajectory is recorded while using the original trace for ADAS - is the newly created GPS trace a derivative work of the original database or not? The ADAS system is constantly monitoring vehicle's current position against the original GPS trace and may only issue a warning in case the vehicle should leave the path of the original GPS trace. The ADAS system by itself however is not able to intervene via vehicle steering and thus change the vehicle's path. I am specifically interested in two cases - whether the above use case is a: derivative work according to the US copyright law derivative work in terms of the ODC Open Database License (ODbL)
A GPS trace of a car's path, on its own, is unlikely to be covered by copyright in the first place. It is primarily made up of facts (the locations of roads and lanes), and there is no creativity involved in its creation. A database of facts may be protected by copyright as a compilation if there is some amount of creativity in how it is assembled, but this does not extend any protection to the individual contents of the database (cf. Feist v. Rural).
Very few terms have a single "legal" definition or meaning that applies to all laws, and can be looked up as if in a dictionary. Rather, when a specific meaning is needed in connection with a particular law, that law will include a definition. But that definition will often not apply to the use of the same term in other laws or other contexts. Here I suspect that the OP has found the definition section of a US Federal law regulating commercial transport in interstate commerce. Obviously in such a law, those terms would be defined in the context of commercial transport. That does not mean that the same meanings will be applied in other laws. Driver's licenses and other traffic and motor vehicle regulations are largely matters of state law in the US. Definitions from a federal law, or indeed any law but that state's Motor Vehicle Code (or whatever a given state calls such a body of law) will simply not be relevant. The argument sketched in the question simply does not follow.
You don't have to, but you probably want to for a couple of reasons: It's courteous, and in the spirit of open source It's someone else's work, and you're using it. The least you can probably say is &quot;thank you.&quot; It will also probably help you stay in the clear: since you're using software in binary form, where the notice isn't immediately accessible, then by providing a copy of the license, you respect that licensing term in another way. It tells your users what's up with the program Let's admit it, having the license accessible to the users tells them what's in the program and so on. It's another way of providing attribution, like I listed in the first reason above. Many apps, desktop and mobile, have a screen or panel to indicate the projects and licenses that they use. They don't have to be straight in the user's face, they can be a little button in the &quot;About&quot; screen of the program. To answer a little confusion: the binaries are still a derived form from that source code. Analyse the heading: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The software is still there, it's just there in a different form, a compiled form. Therefore, the copyright and permission notice should probably stick around, even if it's just a file somewhere.
Yes, you can use such eye tracking if you obtain consent in a suitable manner. But obtaining consent is going to be very difficult for you. The processing activity in question occurs within the context of an EU establishment of the data controller. Thus, GDPR applies regardless of where the data subjects are located. Under GDPR, any processing activity needs a clear purpose and a legal basis. Typical legal bases are necessity for performing a contract with the data subject, legal obligations, a legitimate interest, or consent. Conditions for consent are listed in Art 7 GDPR. Once your have a purpose that is covered by a legal basis, you can collect the minimum data necessary to achieve the purpose. For example, let's assume that the purpose is a scientific study for which gaze tracking is necessary. The study's subjects can be informed about the context of the study, about how the data will be used, and can then be asked for consent for proceeding. Of course, participation in the study is only possible when consent is given. This is perfectly fine as far as the GDPR is concerned. But things might be more difficult when data is used for a different purpose, for example in order to track user interests in a web shop. You do have a legitimate interest in optimizing the website, but this interest likely doesn't outweigh the user's privacy interests. Legitimate interest always requires a careful balancing test. If the user cannot reasonably expect the data collection to happen, that is an indication that consent would be a better legal basis than legitimate interest. Accessing a camera feed means accessing information stored on the end user's device. Per the ePrivacy directive, this requires consent regardless of whether the information in question is personal data. Cookies, mouse pointer tracking, or eye tracking with a camera are all equivalent in this regard. Consent must be specific, informed, and freely given. It is an unambiguous indication of the data subject's wishes, and must involve some clear statement or affirmative action. Prior to starting the eye tracking, you must provide sufficient information about what is happening, and must make it possible to easily decline consent. You cannot bundle unrelated consent together (e.g. eye tracking consent + cookie consent). You cannot make access to a service conditional on unrelated consent. E.g. a web shop does not need camera access, but an augmented reality does. Still, consent must be specific so consent for AR purposes can probably not be used to authorize eye tracking, which might need separate consent. Browsers do not grant camera access by default, and instead show a permission dialogue where the user can allow access or block further requests. This permission dialogue cannot replace your compliance obligations such as providing the necessary information so that the user can make an informed choice. Since GDPR requires that consent is freely given and can be declined, you might find it difficult to convince anyone to give consent to this fairly invasive tracking procedure. You might be able to incentivize consent e.g. with small discounts on a web shop, but the incentive must remain small enough that there really is a free choice between giving or declining consent. The EDPB has issued guidelines that are relevant to your scenario. These guidelines are not law, but are well-reasoned official interpretations that are frequently cited by courts. Guidelines 05/2020 on consent Guidelines 3/2019 on processing of personal data through video devices Practically speaking, I doubt you will find eye tracking to be useful. First, you can likely achieve your purposes through less invasive means. Recall that the GDPR only allows you to process the minimum data necessary to achieve a purpose. Second, eye tracking is difficult for technical reasons. Bad lighting and weird angles make it difficult to obtain a useful feed. Cameras might be in different positions relative to the browser window, so that the eye tracking would have to be calibrated before acquiring data. Eye tracking typically involves processing the video feed on the user's device, but this is computationally expensive that will make the website unusable on lower-end devices, in particular mobile devices. And of course, many PCs don't have a camera in the first place.
You are creating a derivative work. You are only allowed to do this if the library comes with a license that allows this. If you want to give your derivative work to anyone else, copying it is copyright infringement unless the license allows it. Copying the derivative work and attaching a different license is most likely to be copyright infringement. And if people receive a copy with an open source license that is not justified and rely on it, that’s creating one unholy legal mess for everyone involved and can be massively more expensive than plain copyright infringement. No license means you don’t have permission to do anything with it, not creating derivative work, not distributing it, and certainly not publish it with an open source license.
There are vendors providing software to facilitate this sort of task. Avalara is perhaps the best known, but I don't have any experience with it and couldn't say whether it's actually any good or not. But the bottom line is that in a destination-based sourcing regime, sales taxes must be computed based on the address of the destination, not city or ZIP code associated with that address. As Avalara has noted, this is a giant hassle, but it's nonetheless the current state of the law. Of course, this assumes the seller has sufficient nexus with Louisiana to trigger a duty to collect sales taxes in the first place. From the question, it is not clear whether this is true.
It is reasonable to interpret the statement in their Github repository README.md as a "public domain" license for anything contained there. However, their "usage guidelines" backpedals a bit ("generally are not copyrighted", the misleading implication that content used commercially is subject to restrictions that educational and personal uses are not subject to). Although it is true that works "created by the US government" are not protected by copyright, not everything associated with a government agency is created by the US government. An agency might have a policy that they will not post material that is not copyright-free, there is no practical means of knowing if an item is an actual government work, versus a government-supported or government-hosted work (where copyright is held by someone else). If you trust their implication that all of those items in the repository are indeed government works, then they are free of copyright. I don't know any reason to not believe them, although sometimes the government is wrong and they end up liable big-time for infringement. However... NASA Open Source Agreement Version 1.3 (another copy on a NASA web page) on first glance seems to contradict the "government work" theory. Here, they claim to grant certain rights to users and also impose impose restrictions (including obligatory registration). This does not make any sense for a work that is in the public domain. The license is legally defective in that it fails to fill in relevant blanks (agency name, title of work, URL for obligatory registration). Also notice that the license is only for software. The scope of that license therefore has to be something narrower – it applies only to software, and presumably software that is not "a government work". I have no idea what software NASA could legally give away and is not a government work which is therefore not protected by copyright.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/