Requisitos mínimos para el desarrollo del TPM

fundamentally the same rules apply whether you incorporate proprietary or open source software into your program. Fundamentally, you may only include software developed by

someone else into your software if you have a license that permits you to do so, and you must follow the requirements of that license. For most proprietary programs, this can only be done by paying per-unit royalty fees and/or limiting your use (such as only using it for educational purposes). If you fail to obey those rules, you can be taken to court for damages, regardless of whether it’s proprietary or OSS/FS.

Many proprietary programs include open source software, so it’s obviously possible to do this legally. Microsoft Windows includes OSS/FS components (such as components from the University of California, Berkeley and its contributors which implement Internet-related

capabilities), as does Microsoft Office (it uses zlib).

However, just as with proprietary software, you must examine the license first before you reuse someone else’s software. Some OSS/FS programs have use licenses such as BSD, MIT, and similar that explicitly permit you to reuse software in your system without any royalty fees as long as you follow some simple rules. However, you still have to follow rules, for example, some require some sort of credit in the documentation or code itself. These are very low-cost requirements, and

meeting them is far cheaper than writing the software yourself!

The most common OSS/FS license is the GPL, which allows you to use the software in arbitrary ways. However, the GPL strictly limits how you’re allowed to combine the software with

proprietary software (it does prohibit certain actions). The GPL also requires release of the source code to the recipients of the binary. We’ll discuss the GPL more in the next point.

Karen Faulds Copenhaver of Black Duck Software’s “Reviewing Use of OSS in the Enterprise” discusses various myths, including the once-common myth that “You cannot use open source software in a proprietary environment”. Instead, she notes that from a developer’s perspective, OSS/FS and proprietary code have essentially the same issues: you must understand and fulfill your license obligations, Indeed, she believes that OSS/FS compliance will generally be must easier, and that the risk of enforcement is far higher from proprietary code though the same

remedies apply (see slide 18). Thus, by slide 19 she notes that organizations developing software of any kind (whether or not the software uses OSS/FS components) must know what code is in the code base, must know the obligations of all licensed materials used (so they can fulfill them), and must know whether or not the license obligations of the various components are compatible. They note that organizations who are developing software should embrace OSS/FS (slide 36), but when they do, they should meet the obligations of them.

Sometimes these licenses will be a deciding factor. For example, there are two common GUI toolkits on Linux-based systems: Gtk+ and Qt. Gtk+ is released under the LGPL license, and thus can be used by both OSS/FS and proprietary programs without any royalty payments. Qt is

available freely under a GPL license, and for a royalty fee under a proprietary license. If you didn’t want to make a royalty payment to Qt’s developers (and/or are concerned about potential future payments and/or how that might empower one company in the future), you could choose to use the Gtk+ library.

On the other hand, if you’re determined to illegally violate the licenses, then do not make the unwise presumption that you won’t get caught. Since OSS/FS source code is widely available, it turns out that it’s often easy to determine if a product has stolen code, and people do actually do such analysis. One developer quickly found and proved that “CherryOS” had blatantly stolen PearPC Code. Netfilter developers have had many successes in enforcing their licenses against people who sell black-box routers and wireless access points with stolen code. The site GPL- violations.org has the goal to resolve GPL violations, amicably where possible, and the Free Software Foundation (FSF)’s Compliance lab handles investigation of alleged violations of the GPL and LGPL and subsequent enforcement when violations are confirmed. Besides being sued by an original developer (for stealing their work), you also won’t be able to sue others if they steal your work, due to legal doctrine called “unclean hands”; If someone has stolen something from you, but you stole to acquire it in the first place, courts will tend to throw you out.

The bottom line: if you intend to reuse someone else’s software in your own, you must always examine the license first before incorporating it into your system (to make sure its requirements are compatible with yours). This is true whether the code is proprietary or OSS/FS. Development

organizations normally have a process for evaluating licenses, so the task of evaluating an OSS/FS license is just more of the same work they already have to do. If you’re developing proprietary code, just make sure that your developers are legally obligated to go through a vetting process before reusing external code (this is standard practice in the industry). OSS/FS licenses generally require that the license accompany the code it covers, so it’s quite easy to get and review any license (it comes with the code you want to use!). If there’s any doubt, there are search engines you can use to check. But this licensing decision is the same sort of decision that must already be made in any software development shop: before reusing code, you must ensure that its licensing

requirements are compatible with your requirements, and that you comply with its requirements. 7. Will unintentionally including GPL code in proprietary code force the rest of the product to

be GPL’ed? No, though you can choose to do so. The GPL, like most licenses for proprietary

software libraries, grants you the right to use code only under certain conditions. Many proprietary libraries require that you pay a fee for each copy, or a large fee for unlimited use. The GPL requires no fee, and indeed doesn’t include many of the restrictions a typical proprietary software license includes. But the GPL does require that, if you include the GPL code as part of your code, you need to release the rest of the code under the GPL.

So what happens if you are developing a proprietary product, and one of your developers includes GPL code directly into the product without your knowledge? Once that happens, you typically have three options: (1) release the rest under the GPL, (2) remove the GPL’ed code, or (3) arrange for the GPL’ed code to be released to you under a compatible license (this typically involves a fee, and some projects will not be willing to do this). This is not a good situation to be in; make sure that your developers know that they must not steal code from any source, but must instead ensure that the licenses of any software they include in your program (either open source software or

proprietary software) is compatible with your licenses. Note that exactly the same thing happens if you incorporate someone else’s proprietary code in your software, with typically even worse results, because proprietary vendors are more likely to sue without working with you and they can often show larger direct monetary losses.

There are many ways of proprietary and GPL programs can work together, but it must be carefully done to obey the licenses. The Linux kernel is GPL’ed, but proprietary applications can run on top of it (outside the kernel) without any limitations at all. The gcc compiler is GPL’ed, but proprietary applications can be compiled using it. A GPL program can be invoked by a proprietary program, as long as they are clearly separable.

Indeed, there are a large number of misconceptions about the GPL, more than can be covered here. For more information about the GPL, a useful source is the Frequently Asked Questions about the GNU GPL from the Free Software Foundation (the authors of the GPL).

8. Is OSS/FS economically viable? Yes. There are companies that are making money on OSS/FS, or