980 resultados para Foss, Frank (1895-1989)
Resumo:
FOSS has always been particularly welcome in Universities. Its spirit corresponds generally with the academic state of mind, and royalty-free technologies are particularly appreciated where money is usually lacking.But at the opposite side of the spectrum, the universities¿ TTO¿s (Technology Transfer Officers) are supposed to ¿valorize¿ the production of research departments and to enable profit making cooperations with the industry. How should FOSS licensing be tackled in such context?
Resumo:
With nearly 2,000 free and open source software (FLOSS) licenses, software license proliferation¿ can be a major headache for software development organizations trying to speed development through software component reuse, as well as companies redistributing software packages as components of their products. Scope is one problem: from the Free Beer license to the GPL family of licenses to platform-specific licenses such as Apache and Eclipse, the number and variety of licenses make it difficult for companies to ¿do the right thing¿ with respect to the software components in their products and applications. In addition to the sheer number of licenses, each license carries within it the author¿s specific definition of how the software can be used and re-used. Permissive licenses like BSD and MIT make it easy; software can be redistributed and developers can modify code without the requirement of making changes publicly available. Reciprocal licenses, on the other hand, place varying restrictions on re-use and redistribution. Woe to the developer who snags a bit of code after a simple web search without understanding the ramifications of license restrictions.
Resumo:
Open source is typically outside of normal commercial software procurement processes.The Challenges.Increasingly diverse and distributed set of development resources.Little/no visibility into the origins of the software.Supply Chain Comparison: Hardware vs Software.Open source has revolutionized the mobile and device landscape, other industries will follow.Supply chain management techniques from hardware are useful for managing software.SPDX A standard format for communicating a software Bill of Materials across the supply chain.Effective management and control requires training, tools, processes and standards.
Resumo:
The presentation reflects on French and Italian case law that, in recent years, has dealt with free software from two different angles: public procurement and consumer protection against joint sales of hardware and software.
Resumo:
Creating and using FLOSS in R+D projects raises several legal issues, which need to be managed as soon as possible - preferably during the project planning stage. Challenges in the areas of project structure and policy, licenses and licensing, exploitation strategies, community management, and FLOSS-friendliness in general all have their legal aspects, which are commented here. Some recommendations are made for assisting in the use of FLOSS in R+D projects, especially in multiple party consortiums.
Resumo:
From a business standpoint, this paper describes the point of view on the question of warranties of a FOSS editor doing business in a risk-averse market segment. It is based on 15-years experience of AdaCore in the safety-critical embedded industry. However, it is not only the point of view of a provider, as it also aims at demonstrating that the interests of providers and users are aligned in this area. From a legal point of view, the enforceability of these warranties will be partly covered, as well as the articulation between the license and the warranties on one hand, and the articulation between the license and the other contracts that can be created in a business relationship on the other hand.
Resumo:
Today, most software development teams use free and open source software (FOSS) components, because it increases the speed and the quality of the development. Many open source components are the de facto standard of their category. However, FOSS has licensing restrictions, and corporate organizations usually maintain a list of allowed and forbidden licenses. But how do you enforce this policy? How can you make sure that ALL files in your source depot, either belong to you, or fit your licensing policy? A first, preventive approach is to train and increase the awareness of the development team to these licensing issues. Depending on the size of the team, it may be costly but necessary. However, this does not ensure that a single individual will not commit a forbidden icon or library, and jeopardize the legal status of the whole release... if not the company, since software is becoming more and more a critical asset. Another approach is to verify what is included in the source repository, and check whether it belongs to the open-source world. This can be done on-the-fly, whenever a new file is added into the source depot. It can also be part of the release process, as a verification step before publishing the release. In both cases, there are some tools and databases to automate the detection process. We will present the various options regarding FOSS detection, how this process can be integrated in the "software factory", and how the results can be displayed in a usable and efficient way.