In some cases, this is fine. But it makes it difficult for the project should they decide they want to relicense or dual-license the project as they have to get permission from every copyright holder. Or if there is need to enforce the copyright, the project would need every affected copyright holder to be involved.
What many projects do is require that contributors assign copyright to a single legal entity or person which then has the power to enforce the copyright without requiring everybody get involved. Keep in mind that although this person or entity then owns the copyright, the code has been released under a license that allows free distribution. Thus the fact that the copyright has been assigned to an individual entity does not make the code any less open. For example, suppose Perpetual Motion decides they want to exercise their copyright and make a proprietary version of DotNetNuke.
They certainly have the right to do so, but they cannot stop others from freely viewing and distributing the code under the pre-existing license up to the point at which they close the source. At that point, contributors would be free to fork the project and continue development under the original license as if nothing had occurred.
Is sufficient. Some organizations such as the Free Software Foundation, on the other hand, apply a very formal process requiring users to sign and mail in paperwork.
In any case, some open source projects do not have such a copyright assignment policy in place, but it makes sense to do so. As Fogel points out, should the terms of the copyright need to be defended, it is much easier for a single entity to do so rather than relying on the cooperation of the entire group of contributors, who may or may not be available.
Having the copyright assigned to a corporation also protects individual developers from exposure to liability in the case of a copyright infringement suit. Another possibility that I did not originally cover is to have nobody own the copyright by dedicating a work to the public domain. This effectively surrenders any rights to the code and gives the code to the public to do with it as they wish. In some regards, dedicating a work to the public domain is unusual.
Typically, works in the public domain have had their copyright expired or were inapplicable such as government works. As Wikipedia points out:. Few if any legal systems have a process for reliably donating works to the public domain. They may even prohibit any attempt by copyright owners to surrender rights automatically conferred by law, particularly moral rights. The CC0 license from Creative Commons is another such effort. One thing that we learned on the DotNetNuke project, is that having a single copyright holder goes beyond just its effect on the code developers.
When working with Web Hosting companies they expressed concerns with having multiple copyright holders for the project as it could lead to problems if some of the copyright holders choose to change their licensing terms.
Ultimately there would not have been a single entity involved in the licensing of the product which could have potentially created problems for the users. When using licensed components, it is easier for a project to insulate itself from the negative impacts of changing licenses, however, when code is threaded throughout a project, it is not so easy to rip-and-replace if the copyright holder changes to an incompatible license.
Open source project leaders need to deliver on their promises and prioritize the community to succeed. Open source investment activity has remained high since it became a mainstream conversation with Red Hat back in In fact, venture capital investments continue to be strong in companies like Confluent, Cockroach Labs, and Neo4J to name a few. As new projects come to market, the growth and influence of these open source communities will continue to attract the attention of investors.
The VC community has long been linked to the open source community and will continue to fund the companies pushing new open source projects forward. The open source model has evolved through the years, but investors no longer question how open source companies will make money. As organizations adopt and scale open source technologies, their demands for professional services and enterprise-grade offerings often grow exponentially.
We wanted to create a solution that would benefit and influence the larger industry, and finally, we recognized the benefit of having a more diverse group of people and companies involved.
When the creators of Presto left Facebook, the community followed us and we continued the project under a new name, Trino. It was yet another proof point in the critical importance and power of the community. We were able to continue the vision of a truly community-driven and openly governed open source project. In an ideal scenario, the creators will foresee potential challenges, pivot, and avoid forklifting altogether.
I share this story to help showcase the further evolution of open source software and highlight the underlying importance of the community and true ownership in any open source project. While in practice most contributors will willingly agree to license their material under the same licence as the original work, meaning that the process of uptake and improvement can continue, still it can be complex to ascertain who should make a legal complaint if someone decides to use the program in a way that violates its licence.
To avoid this issue, some open source projects ask that contributors explicitly assign the copyright in their contributions to a body that administers the project, thus keeping ownership centralised and making enforcement of the licence easier. It is often observed that licences such as those within the OSD are problematic because there is no overt act of acceptance by licensees who take them up.
End-user licence agreements that are distributed with proprietary software often require a user to click a button to accept the conditions, and this fact leads many to believe that open source licences should require something similar to be binding. This is incorrect. Proprietary end-user licence agreements are contracts to govern many aspects of the relationship between company and user.
If the user breaks the agreement, they have breached their contract, and the software company may choose to use the law of contract to punish them.
But this can be difficult, particularly as the law of contract varies from country to country. Although they are not considered to be contracts, properly drafted open source licences are legally binding and enforcement action can be taken against those who breach them. This may be under contract or copyright law, depending on how the licence is framed.
No-one is forced to explicitly accept the licence, but implicit acceptance of the licence conditions is the only route to legitimate use under copyright law. The Open Source Initiative website currently lists over 50 licences that meet the conditions described in section 3. It is not within the scope of this document to examine them all. It is notable, however, that the most widely used open source licence in terms of the number of projects that use it — the GNU General Public License GPL version 2 — imposes a major further condition upon those who copy, adapt or distribute software under it.
All software created by modifying the original software must also be licensed under the GPL if it is distributed. The aim of this condition is to produce a body of open source software that grows as users contribute, and that cannot be shrunk by users adding their own effort to a piece of software and then relicensing the result under terms that are more restrictive than those of the GPL.
Because this condition can be seen as an attempt to subvert the proprietary use of copyright, it is sometimes known as copyleft. It is worth noting that there is no compulsion to release changes that you make, either under the GPL or any other open source licence; you may keep internal versions of GPL software that you have modified without necessarily licensing them to anyone else.
This applies equally to individuals and legal entities like companies and institutions. It is tempting to believe that all the source code that is available under an open source licence can be adapted and combined without restriction in order to produce new open source software. Unfortunately this is not the case. Two licences that each meet the requirements of the Open Source Definition individually may nevertheless contain terms that make them incompatible with each other.
It also mandates that no additional restrictions on the rights it grants can be imposed on GPL-licensed code.
These two conditions combine to mean that GPL-licensed code can only be merged easily with other GPL-licensed code, or with code whose licence imposes only conditions present in the GPL. Clearly it is not an easy task to establish whether a condition in one licence is the exact equivalent of a differently worded condition in another licence.
The Free Software Foundation, which administers the GPL, makes available a list of licences that they consider to be compatible with it. The issue of licence compatibility is a complex one, and determining whether two licences are compatible will require the help of a lawyer in all but the most simple of cases.
Programmers working on a piece of software that is to be distributed under a licence whether open source or otherwise need to be aware of the potential difficulties in this area before attempting to merge in open source code.
However, this approach is only really practical where the number of owners is small. The issues of licence compatibility and of complex multiple ownership of intellectual property mean that it is desirable, if not essential, for programmers and their managers to keep detailed records.
Version control systems provide some of this record-keeping automatically, recording who made changes to the code and what they did.
0コメント