Package Management is now almost ubiquitous in modern software development circles due to the layers upon layers of dependencies between software components which are pulled together to achieve an end result.
For a simple overview of the topic, start with this Wikipedia entry.
This is especially true in the open source world where the very nature of community and crowd source development encourages re-use of code at every opportunity.
From a licensing standpoint, this code combination and inheritance phenomenon has the potential to introduce wrinkles when investigating the provenance and or applicable licensing for a particular component.
Two of the most common package repositories for open source components are:
I was recently researching the licensing for a component automatically included in a project when a developer using the Microsoft Visual Studio IDE was working on a web based application. In effect, this "package" was pulled into the developer's work without their direct knowledge or choice from the NuGet Gallery repository. Apparently it was necessary for some foundational functionality related to processing java script.
Upon investigation, I discovered the original component was released by the copyright holder under an MIT license, but had apparently been bundled together and re-released by Microsoft under its own NuGet license. Nothing in the MIT license restricts this practice as long as primary attribution is maintained and promulgated, however there are additional terms in the NuGet license a consumer of this component might be more concerned about than when taking the code under the pure MIT license. For example, the NuGet license specifically grants Microsoft the right to collect certain information from a package consumer's computer and or project as a condition of use.
The lesson here is that package management can impact a user's rights to open source code if used indiscriminately. Depending on the use case, it might be worth some investigation to determine if a component is available under more benign terms.
For a simple overview of the topic, start with this Wikipedia entry.
This is especially true in the open source world where the very nature of community and crowd source development encourages re-use of code at every opportunity.
From a licensing standpoint, this code combination and inheritance phenomenon has the potential to introduce wrinkles when investigating the provenance and or applicable licensing for a particular component.
Two of the most common package repositories for open source components are:
- The Maven Repository containing almost 7 million artifacts as of the date of this post
- The NuGet Gallery currently hosting about 1 million artifacts concentrated on the Microsoft development platform.
I was recently researching the licensing for a component automatically included in a project when a developer using the Microsoft Visual Studio IDE was working on a web based application. In effect, this "package" was pulled into the developer's work without their direct knowledge or choice from the NuGet Gallery repository. Apparently it was necessary for some foundational functionality related to processing java script.
Upon investigation, I discovered the original component was released by the copyright holder under an MIT license, but had apparently been bundled together and re-released by Microsoft under its own NuGet license. Nothing in the MIT license restricts this practice as long as primary attribution is maintained and promulgated, however there are additional terms in the NuGet license a consumer of this component might be more concerned about than when taking the code under the pure MIT license. For example, the NuGet license specifically grants Microsoft the right to collect certain information from a package consumer's computer and or project as a condition of use.
The lesson here is that package management can impact a user's rights to open source code if used indiscriminately. Depending on the use case, it might be worth some investigation to determine if a component is available under more benign terms.
No comments:
Post a Comment