Almost all open source developers retain the copyright to their work. Therefore by definition, open source licenses are limited in scope and full ownership can never be claimed by others, except in circumstances such as a merger or acquisition of the copyright holder's business, where a legal transfer of ownership rights would be conveyed by contract. The rule limiting ownership rights applies under almost every open source license, no matter how extensively the code is altered by downstream developers.
Licenses attached to open source projects may also be restricted by use. There is an increasing industry trend to restrict the CE (community edition) of an open source product to a small subset of users, perhaps defined by a single domain, single server or for academic use only. The obvious goal of these restrictions is to reserve the CE for a very small user base, while driving most commercial users to the vendor's closed-source offerings.
The best way to avoid licensing problems is to read and understand all licensing terms and restrictions before deploying the product. If licensing terms seem unclear, it may be wise to seek a legal opinion.
2. Understand the business model of open source
Creators of open source software tend to be altruistic types by nature, and may contribute thousands of hours to a project, sometimes earning less than minimum wage (if they are paid at all), just to donate software for the common good. But keep in mind that most of these talented developers aspire, at least eventually, to profit in some way from their work. The "for profit" model can be pursued in a number of ways. The primary road to profits is through the sale of software support and customization, and driving customers steadily toward the commercial, closed-source version of the product.
This explains why the open source version of some products may offer complex installation routines, confusing or incomplete documentation, and technical support so incoherent or indifferent that users quickly realize that if they need actual help they will have to pay for it. One FOSS vendor, instead of supplying useful answers to support questions, shamelessly informs hapless users that he can help them for a starting fee of just $80.
Larger, established open source projects usually have a commercial customer base adequate enough to obviate the need for such gimmicks, but even with an established open source product, when the app or upgrade crashes your web server and you need immediate assistance, without a paid support plan you are still on your own. This means that FOSS adopters must supply their own subject matter experts, sometimes to the tune of hefty salaries or high hourly rates. As a result, some companies have adopted strict policies against using the community version of any software product, opting instead for the safety net and predictable cost provided by the vendor's commercial support plans.
How much customization and at what cost?
Organizations who adopt FOSS products frequently discover the need to customize the software to meet specific needs or to comply with enterprise policies. For well-established content management systems such as Drupal, Joomla or Word Press, adding new pages and changing the overall look of the application can easily be accomplished by a power user having few or no programming skills. However, once customization needs go beyond the built-in interfaces provided by the vendor, advanced programming skills are typically required to make changes. If staff programmers are not up to speed with a particular open source app, the organization finds itself facing the costs of both learning curve and customization, resulting in additional expense and delays.
3. Factor in increased security risks