What is the status of Microsoft &quot;ribbon&quot; licensing as of 2017? In 2007, the "fluent UI" or ribbon had IP rights asserted and required a license from Microsoft. That license is now no longer available, the page only stating 'retired'. What is the status of using a ribbon UI on Windows or any other platform? Is Microsoft still asserting IP rights, and is a license required? Note that there are many questions online about this, but no answer, much less a sourced one stating Microsoft's official position. This leaves many developers in a state of uncertainty. As of 2017: No documentation on MSDN anywhere mentions a license. Consider, for example, the MFC ribbon overview. The VC++ 2017 MFC CMFCRibbonBar class, the only ribbon installed with VS2017, links to the retired license in its header. This header has not changed for many years. Its documentation does not mention a license. The Visual Studio 2017 license does not mention the ribbon. The Windows 10 SDK license does not mention the ribbon (checked against 10.0.15603.137, downloaded 2017-04-11.) Some believe this means no-one who did not sign a license before it was retired are able to legally use a ribbon. A 2009 comment in a forum (not a good basis) states there are "no unusual licensing requirements". There has been no statement by Microsoft of a change in its attitude the the ribbon, arguably meaning that now a license is no longer available, no developers can use a ribbon. Microsoft uses a ribbon in its macOS Office applications, but has not indicated if other developers may use a ribbon on non-Windows platforms There is significant doubt if the ribbon is valid IP. This leaves all developers who did not sign a license prior to it being retired in limbo and uncertainty, not knowing: If they can use the inbuilt WinAPI ribbon control on Windows 10 without a license If they can use a third party ribbon control on Windows without a license If they can use a third party ribbon control on macOS or Linux If they can use a ribbon for an application that competes with a Microsoft application (either Office, or other.) Please cite sources, and prefer the kind of sources you could quote if it became legally important, above sources that are a comment on a forum. I'm seeking a definitive answer, and won't mark a "it's probably ok, you'll get away with it" answer as correct.
The available evidence (sparse!) suggests that it cannot be done (or can be in a restricted way, see technobabble below). A non-authoritative report (from a developer who had to drop it) is here. A snapshot of a MS support page from 2013 on Office UI licensing for developers (also preserved on the Wayback Machine) says: The Office UI licensing program, originally launched in November 2006, has been retired. When the program was introduced in 2006, developer frameworks for the Office Ribbon did not exist. Microsoft tools and technologies now provide developers a variety of options, code, and developer frameworks for implementing the Office Ribbon UI in Windows applications. If you are a developer that already signed up for the Office UI licensing program and accepted the licensing terms, then you will continue to have rights under that license to implement the Office UI per the terms of that license. There are no changes at all for existing Office UI program licensees. If you are not already licensed to use the Office UI under the retired program, you can use any of the Microsoft tools and frameworks to implement the Ribbon UI in your current or future Windows applications. The license terms associated with the Microsoft developer framework will apply. For example, current developer frameworks that are licensed for creating a Ribbon UI include: Microsoft Ribbon for Windows Presentation Foundation (WPF) Windows Ribbon Framework Microsoft Windows SDK for Windows 7 and the .NET Framework 4 Ribbon Extensibility Overview Microsoft Foundation Class Ribbon Component (The MFC ribbon may now be used under the same license as the Microsoft Windows SDK). If you are not already licensed under the Office UI licensing program, and you do not want to use any of the Microsoft tools and technologies, Microsoft no longer has a separate Office Ribbon UI licensing program. If you have any questions about the retired licensing program, please email the officeui@microsoft.com email alias. So apparently you can do it using MS tools, but not totally on your own.
They certainly can make that a license term and revoke the license if you do not comply. However, revoking the license is all they can do to &quot;forbid&quot;. Or they could sue you for damages without revoking the license. That said, you are free to consult how to use their software so long as you do not hold a license so that you are not bound by the terms AND you do not break the law e.g. copyright. How to do it is up to you to figure. Maybe you could simply consult users that do have a license — on their premises and devices.
What you are missing is that the original copyright holder can give permission to make derivative works with strings attached. There is no automatic right to derive something from a copyrighted work. Those strings could include constraints on what you create in the process of making the derivative work. Yes it is a string limiting what you can do with something you own, but you would have been warned in the license and had the choice to start from scratch. People do create work-alike software with no copyright strings using two teams and a &quot;clean room&quot; design process. It is a lot harder than modifying something another person has developed. Also, law and someone's understanding of morals need not be aligned at all. And, in patent law, just creating something all by yourself from scratch does not give you ownership. If someone else did it first and got a patent you can't make the item you might think you own. IP law is complex and looking for &quot;fundamentals&quot; may not get you anywhere.
The GPL doesn’t require you to distribute the software to anyone. The only requirement to distribute something is that if you do distribute the software to someone as a binary, you must also distribute the source code to them at no additional charge. The focus of the GPL is ensuring freedom for people who have copies of the software, not ensuring that the software is available to the world at large. Because your final deliverable is source code, you’ve already complied with the requirement to distribute source alongside object code. You have to comply with the requirements in section 5: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. You have to license the software to the company that hired you under the GPL v3 (since parts of it were licensed to you under GPL v3), so you can’t stop them from distributing it to the world. But nothing requires you to distribute it to the world.
The only issue relevant to your age is the (ir)revocability of the license. GPLv3 purports to be an irrevocable license. To be really irrevocable, the license would need to grant certain rights in exchange for something of value, that is, you need a license that passes muster as a contract. Copyright licenses are typically treated as contracts, but it is not clearly established in law that licenses are contracts or are not contracts. Out of the goodness of your heart, you can grant permission to use your property, but you can also withdraw that permission. If you have a contract granting perpetual permission to use your property in exchange for something of value, then you can't later withdraw that permission. In the case of Jacobsen v. Kratzer, the sides advances opposing theories that the license was a "bare license" vs. was a contract. (The matter was ultimately settled out of court). This article puts together the legal factors surrounding the notion of license as contract, see p. 21 ff, and esp. §IV for arguments that licenses should be contracts, to be fully enforceable. A contract for non-essentials formed with a minor is not enforceable, until you are 18. You could therefore revoke the license, until you are 18. Anyone who uses the software does so at their peril. However, if the license is not a contract, no existing legal doctrine (in the US) whereby the permission is irrevocable. In other words, yes you can, at their peril. The whole license-as-contract issue is very complicated, and I'm only focusing on the revocability issue. There is a separate question whether one can sue a user for both copyright infringement and breach of contract. The case of Artifex v. Hancom, see also this analysis, found that (in the particular case), plaintiff can pursue the matter as both infringement and contract breach.
If the code is unrelated to your employment you own the copyright no matter if it is written in Visual Studio, on a piece of paper or tattooed on your butt. In the same way a sculptor owns the copyright in their sculpture even if they use someone else's chisel. Using Visual Studio in this way may, however, violated your contract with your employer and/or their contract with Microsoft. Why go there? Visual Studio Community is free.
You can write anything you want (basic First Amendment protections): the question is whether one would be liable for damage that arises from what you're written, or whether you can distribute what you've written. Distribution may be restricted, thanks to the Commerce Clause (hence FDA regulations, which figure prominently in the analysis). Most software writers are not medical practitioners, and vice versa, and what the software writer does is implement something described by a competent medical practitioner. It is logically possible that a med. practitioner might also try to write software (no problem) and distribute it (possibly a problem); or, a software writer might read up on something on Wikipedia and try to implement it (again, no problem) or distribute it (possible problem). Damages can be sorted into two categories, implementation errors and scientific errors, and having ruled out deliberate sabotage, we are left with negligence. If the software writer failed to use suitable care in writing code that sums a set of numbers, the software writer has been negligent. If the person purporting to have the qualified scientific knowledge mis-states the formula, that person has been negligent. It is possible for many parties to be negligent (the programmer failed to be diligent in understanding the software requirements; the medical professional failed to adequately explain what was required of the program). The FDA does regulate medical devices, and "device" is construed pretty broadly (condoms are non-exempt class 2 medical devices). There is FDA guidance on medical software which makes it clear that the device manufacturer shoulders the regulatory burden. Anytime you manufacture a tangible thing (which is within the scope of FDA regulation for medical devices), you have to have the thing approved. Many (most?) medical devices implement software, and are thus within the scope of FDA scrutiny. It is not illegal to write software that ends up being implemented in an unapproved medical device, but the unapproved medical device itself is illegal. It is reasonably likely that purported medical software (not a gadget with software build in) would be held to be a non-exempt device. To know if something is exempt, you would look at the exemptions list, and determine that your program (or thing) is not on or implied by anything on that list. The visual acuity eye chart is a class 1 exempt item, as is the manual toothbrush. There is no way to specifically look for things that are only software, or that contain software, so the search through the list would have to be guided by knowledge of the subject area. Canada is helpful in explaining when software is a regulated medical device. This is non-probative w.r.t. US law but gives you an idea what is likely to be considered a "device". Under Canadian law, the software would be clearly a regulated medical device. The FDA has a power-point that attempts to say something about the matter which warns you that you are on your own and "You will need to go back to study and use the source regulatory documents" to make the determination. Eventually, slide 13, they hint that if you intend the software to be used in diagnosis, prevention, or treatment, then it is a device (so, yes, the aforementioned software would be a device, and probably not exempt from regulations). General purpose software (word processors, web browsers, communications software, etc.) are not indented to be used for a regulated purpose, although they can be so used, and thus they are probably not subject to FDA regulation. There is a murky relationship between regulatory approval and liability. Being approved by the government does not convey immunity to negligence suits (see Wyeth v. Levine), but being approved can have weight in determining whether a party was negligent, since regulatory scrutiny ostensibly filters out errors that could have been caught. Federal approval does not preempt state tort law, as the court ruled. Regulations pertaining to medical devices hold for anything that qualifies as a device, and is not defined (negatively) in terms of disclaimers. If you sell a medical device but label it saying "this is not a medical device, it is not created by a competent medical practitioner", that doesn't make it not a medical device. Unfortunately, what counts as a regulated device is based on intended use, and there is an obvious connection between disclaimers and intentions. Taking MS Word as an example, MS does not as far as I know say that "Word is not intended to be used as a medical device". It can certainly be used to diagnose, teat, and prevent medical conditions, but so too can a screw driver or pretty much anything else. The number of non-medical uses vastly outweigh the medical uses, so it would be deemed not to be a regulated device. A program which prescribed a set of prayers to be uttered in case of illness would be subject to First Amendment override of any FDA regulations. Quack medical devices are prohibited (that's why there is regulation of devices in the first place), but discerning the fine line between permitted actions based on nutty beliefs and forbidden actions is not easy. The FDA also has guidance on the distinction between "Complementary and Alternative Medicine", which does not clearly state that, for example, a software reading of your cakra-energies based on a computer program's questions is not a medical device. They do say of mind-body medicine (mentioning yoga, biofeedback and tai chi as examples) that "CAM practices in this domain would not be subject to our jurisdiction under the Act or the PHS Act", but then say "any equipment or other products used as part of the practice of mind-body medicine may be subject to FDA regulation, depending on the nature of the product and its intended use" (hence a yoga-enabling program may be subject to regulation).
Affirmative authority that this particular use (incorporation of the format of another program's textual data files into your own program) is protected is somewhat elusive in the US system; however there's a lot of observable evidence that reverse engineering data file formats without a license is widespread. My sense is that this would be analyzed under the same rubric as other kinds of reverse engineering and/or fair use. I'm sure there are others here who are better able to clearly and concisely explain that law than I am. However there may be limits — it seems Microsoft was able to prevent VirtualDub's use of the ASF format by patenting it. That said, it's hard to see how an unencrypted, unencoded ASCII data file file could be patentable (i.e. where the ASCII strings are the data, generated in response to user input, and the format is just their order and separators, etc). For the European arena, there is recent authority in SAS Institute Inc v World Programming Limited that the format of a program's data files are not protected by copyright when reverse engineered without the source code. The following is from the digest and application of the CJEUs decision by the English court that referred it, in its subsequent judgment: The judgment of the CJEU On 29 November 2011 Advocate General Bot delivered his Opinion on the questions referred... Questions 1-5 The Court dealt with these questions together. It interpreted this court as asking "in essence, whether Article 1(2) of [the Software Directive] must be interpreted as meaning that the functionality of a computer program and the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and may, as such, be protected by copyright in computer programs for the purposes of that directive": see [29]. Having referred to recital (14), Article 1(1) and 1(2) of the Software Directive, Article 2 of the WIPO Copyright Treaty and Articles 9(2) and 10(1) of TRIPS, the Court went on: ... 39. [...] it must be stated that, with regard to the elements of a computer program which are the subject of Questions 1–5, neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program for the purposes of Article 1(2) of Directive 91/250. 40. As the Advocate General states in point 57 of his Opinion, to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development. 41. Moreover, point 3.7 of the explanatory memorandum to the Proposal for Directive 91/250 [COM(88) 816] states that the main advantage of protecting computer programs by copyright is that such protection covers only the individual expression of the work and thus leaves other authors the desired latitude to create similar or even identical programs provided that they refrain from copying. 42. With respect to the programming language and the format of data files used in a computer program to interpret and execute application programs written by users and to read and write data in a specific format of data files, these are elements of that program by means of which users exploit certain functions of that program. 43. In that context, it should be made clear that, if a third party were to procure the part of the source code or the object code relating to the programming language or to the format of data files used in a computer program, and if that party were to create, with the aid of that code, similar elements in its own computer program, that conduct would be liable to constitute partial reproduction within the meaning of Article 4(a) of Directive 91/250. 44. As is, however, apparent from the order for reference, WPL did not have access to the source code of SAS Institute's program and did not carry out any decompilation of the object code of that program. By means of observing, studying and testing the behaviour of SAS Institute's program, WPL reproduced the functionality of that program by using the same programming language and the same format of data files. 45. The Court also points out that the finding made in paragraph 39 of the present judgment cannot affect the possibility that the SAS language and the format of SAS Institute's data files might be protected, as works, by copyright under Directive 2001/29 if they are their author's own intellectual creation (see Bezpecnostní softwarová asociace, paragraphs 44 to 46). 46. Consequently, the answer to Questions 1–5 is that Article 1(2) of Directive 91/250 must be interpreted as meaning that neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive." Regarding the idea that the user has rights to access their output of a program held in a proprietary data file format there is some additional discussion in the that might be helpful in paragraphs 48 - 62 (of the CJEU opinion), discussing the right of a licensee to 'study and observe' the 'underlying' 'ideas and principles' of a program to accomplish 'acts of loading and running necessary for the use of the computer program.'