tag:blogger.com,1999:blog-30382218497378783492024-03-18T23:33:49.205-05:00OSSLawOpen Source Software Legal Issues, Risks and OpportunitiesP. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-3038221849737878349.post-64943877248911007172019-04-12T11:20:00.001-05:002019-04-12T11:20:47.679-05:00Open Source Activism<div dir="ltr" style="text-align: left;" trbidi="on">
Open Source, or the general idea of a software commons, has always had echos of a progressive viewpoint independent of the simple notion of "free code". I have heard it described many different ways, but the the general theme tends to circle around software quickly becoming so integral to even the most basic functions of society that the benefits of public crowd sourcing development efforts fundamentally out weigh a business model approach favoring software as a proprietary investment.<br />
<br />
However, I have never seen such a direct attempt to use the tools and artifacts of the open source community to impact public policy as described by this NPR <a href="https://www.npr.org/2019/04/10/709490855/github-has-become-a-haven-for-chinas-censored-internet-users" target="_blank">article</a>. It is a fascinating account of how technical workers in China's censored society have chosen to leverage a <a href="https://github.com/996icu/996.ICU" target="_blank">GitHub repository</a> to influence corporate behavior regarding working conditions. The name "996.icu" indicates a frustration that despite Chinese labor laws to the contrary, many technical workers are required to work 12 hour days (9 to 9), 6 days a week, in order to keep their position, and the attempt to keep such a grueling schedule can result in a hospital visit to the intensive care unit or "ICU". Apparently GitHub was chosen as the medium of expression as unlike more traditional social media channels, it is very resistant to government censorship given the importance to so many corporate and academic institutions.<br />
<br />
Even more fascinating to me is the development and inclusion of the "<a href="https://github.com/996icu/996.ICU/blob/master/LICENSE" target="_blank">Anti 996 License</a>", which is a derivative of the standard MIT license. In it licensees are required to:<br />
<br />
<blockquote class="tr_bq">
"<i>strictly comply with all applicable laws, regulations, rules and standards of the jurisdiction relating to labor and employment where the individual is physically located or where the individual was born or naturalized; or where the legal entity is registered or is operating (whichever is stricter)</i>"</blockquote>
And it appears that many in the open source community see the value in such an approach because in just a few days many projects have adopted the license. <a href="https://github.com/996icu/996.ICU/tree/master/awesomelist" target="_blank">See here for a current list</a>.<br />
<br />
Of course the enforceability of such a clause probably varies by jurisdiction and to my knowledge has not yet been tested anywhere, but it is an intriguing juxtaposition of the technical world and social activism.<br />
<br />
Would you ever consider such a licensing approach for one of your projects?<br />
<br />
<br /></div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37067, USA35.9046545 -86.77180169999996935.6988725 -87.094525199999964 36.1104365 -86.449078199999974tag:blogger.com,1999:blog-3038221849737878349.post-47773401388768360912018-11-08T05:26:00.000-06:002018-11-08T05:26:24.995-06:006 Reasons for Making the Open Source Argument<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">"Next time you're in a conversation about open source software, you'll know just what to say."</span></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<span style="font-family: Verdana, sans-serif;"> From my <a href="https://opensource.com/article/18/11/reasons-making-open-source-argument" target="_blank">opensource.com article</a> published this morning....</span></div>
<div style="text-align: left;">
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<h2>
</h2>
<span style="font-family: Verdana, sans-serif;">If your organization is struggling to take advantage of the open
source software (OSS) market, here are some proven ways it can help you
achieve truly transformative success particularly if you are
implementing DevOps.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><div id="new-opportunities" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">1. New opportunities</span></div>
<div id="new-opportunities" style="text-align: left;">
<br /></div>
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">Commercial software and OSS both provide common capabilities as a
commodity to all competitors in a market. However, OSS is distinguished
in at least two important ways:</span><br />
<span style="font-family: Verdana, sans-serif;">
</span><ul>
<li><span style="font-family: Verdana, sans-serif;">Having the source code enables an OSS user to create derivative works resulting in market-differentiating, value-added services.</span></li>
<li><span style="font-family: Verdana, sans-serif;">Appropriate governance provides an OSS user the opportunity to
create business-focused features that may influence industry patterns of
practice.</span></li>
</ul>
<div id="new-business-models" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">2. New business models</span></div>
<span style="font-family: Verdana, sans-serif;">
</span><div class="embedded-callout-menu callout-float-right" id="more-devops-resources">
<div class="view view-related-content-callout view-id-related_content_callout view-display-id-article_block view-dom-id-fdce37547092397ad11d584ce906ae55">
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
</div>
<span style="font-family: Verdana, sans-serif;">Use market position to your advantage by deciding which OSS
capabilities should be standard and open to anyone and where you would
like to compete with proprietary offerings. You can continuously alter
the competitive landscape to benefit your customers.
</span><span style="font-family: Verdana, sans-serif;">Effectively, your OSS product strategy can define and maintain the boundary between the "<a href="http://www.corporatestrategy.com/red-ocean-vs-blue-ocean/" target="_blank">red and blue ocean</a>" for your industry's core technology.</span><br />
<span style="font-family: Verdana, sans-serif;">
</span><ul>
<li><span style="font-family: Verdana, sans-serif;"><a href="https://www.nextgen.com/products-and-services/integration-engine" target="_blank">NextGen Connect</a>
offers one example of this business model narrowly focused on
healthcare data interoperability. Its product offerings range from OSS
to proprietary appliance-oriented options, with the latest features
appearing first in the proprietary versions. The line between OSS and
commercial/proprietary is constantly shifting with market demands and
opportunities.</span></li>
<li><span style="font-family: Verdana, sans-serif;">The commercial-to-OS software continuum also supports trends that
focus on the monetization of data and services rather than software
license revenue.</span></li>
</ul>
<div id="self-determination" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">3. Self-determination</span></div>
<div id="self-determination" style="text-align: left;">
<br /></div>
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">Commercial vendors strive to offer products and services that are
attractive to the widest market and deepest pockets. This often results
in overly complicated and resource-intensive software bloated with
unused features. Products developed to offer specific capabilities can
morph into "platforms" trying to serve every need. Vendor lock-in
through customization, vertical integration, and proprietary operational
processes creates a barrier to change that can be cost-prohibitive and
restrict the ability to quickly pivot to new market opportunities.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">In contrast, OSS components and solution stacks allow a much finer
degree of control and ability to abstract underlying technologies from
business processes. Your roadmaps become your own, independent of a
vendor's feature and release schedules.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><div id="responsiveness" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">4. Responsiveness</span></div>
<div id="responsiveness" style="text-align: left;">
<br /></div>
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">Two critical areas where timely reaction and intervention can avert
problems are security issues and bug fixes. Commercial vendors strive to
be responsive when addressing such issues but, by definition, they are
serving multiple customers with varying needs, sensitivity levels, and
sophistication, which can impede their time to deploy a solution.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">OSS communities tend to coalesce around deploying the simplest
solution in the shortest amount of time. Having access to components'
source code allows direct, rapid intervention if needed. The response to
the <a href="https://en.wikipedia.org/wiki/Heartbleed" target="_blank">Heartbleed vulnerability incident of 2013</a>
is a good example. Open source based applications consuming affected
components could be patched quickly because there was no need to wait on
an official vendor supported patch. Users could independently weigh
risk and patch as they determined best.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><div id="time-to-market" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">5. Time to market</span></div>
<div id="time-to-market" style="text-align: left;">
<br /></div>
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">OSS culture emphasizes self-reliance and naturally leads to <a href="https://opensource.com/resources/devops">DevOps</a>
processes and associated organizational alignment. DevOps can be
fostered with public cloud infrastructure where appropriate. Open
frameworks comprised of OSS stacks and public infrastructure increase
your overall velocity and ability to realize value sooner. DevOps and
OSS complement each other by emphasizing the importance of just getting
started to begin seeing results.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">
</span><div id="cost-efficiency" style="text-align: left;">
<span style="font-family: Verdana, sans-serif;">6. Cost-efficiency</span></div>
<div id="cost-efficiency" style="text-align: left;">
<br /></div>
<span style="font-family: Verdana, sans-serif;">
</span><span style="font-family: Verdana, sans-serif;">There are solid opportunities in OSS to drive hard dollars out of
solutions and operational transaction costs if you are willing to pursue
supporting strategies ruthlessly. Unlike OSS, commercially licensed
products often struggle to differentiate by feature or performance.
Bottom-line: with commercial products, often you are paying extra for a
trademark's reputation, software-as-a-service delivery, or a support
contract—rather than demonstrable added functional value over OSS
solutions. </span><br />
<span style="font-family: Verdana, sans-serif;">
</span><hr />
<span style="font-family: Verdana, sans-serif;">Making the open source argument is worth the effort.
Community-based software development has proven its value in some of the
most challenging spaces. Marketplace competitive forces suggest that
any business turning a blind eye to the open source movement is ceding a
significant advantage to competitors. Just as low-cost, shared
resources on the internet have dramatically reduced the barrier to entry
when it comes to infrastructure, the rapidly evolving breadth and
quality of open source components will quickly alter the competitive
landscape across many vertical marketplaces.</span></div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0tag:blogger.com,1999:blog-3038221849737878349.post-24972646905478233152018-05-21T14:42:00.000-05:002018-05-21T14:42:21.785-05:00Tesla & Open Source<div dir="ltr" style="text-align: left;" trbidi="on">
Just in case you didn't realize that Open Source Software is truly ubiquitous across industries, here is a story about <a href="https://electrek.co/2018/05/19/tesla-releases-softwar-open-source-licences/" target="_blank">Tesla releasing software to comply with GPL licensing terms.</a> According to the story this has been a thorny issue from some of the affected copyright holders, but at least it appears things are moving in the right direction.<br />
<br />
Just think, third parties will be able to experiment with Tesla add-ons, as well as discover bugs and security flaws much quicker through a community approach. I do hope Tesla releases a set of virtual services for testing and publishes a clear contribution path so we don't have hacked cars running down the road. Some day there may be an annual Tesla software conference! Imagine the t-shirt that accompanied the status of being an official Tesla Open Source contributor :-)<br />
<br />
In the end, Tesla's steps toward compliance are a win across the Open Source spectrum and will encourage community development practices to flourish.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37064, USA35.898723400000009 -86.962408635.48705240000001 -87.607855600000008 36.310394400000007 -86.3169616tag:blogger.com,1999:blog-3038221849737878349.post-40133574620354517972018-03-29T14:20:00.000-05:002018-03-29T14:20:00.193-05:00Oracle v. Google in Android Dispute<div dir="ltr" style="text-align: left;" trbidi="on">
Oracle and Google are at it again. The dispute was sent back to a federal trial court by the U.S. Court of Appeals for a damages determination this week.<br />
<br />
At issue is the nature of Google's use of various java API code in the ubiquitous Android operating systems found on so many phones and hand held devices. Google had earlier prevailed on a "fair use" argument before a federal jury, successfully arguing that the Android implementation of java API code was exempt from copyright law. Now, the appellate court's opinion all but assures a continuing battle for years to come given the potential for billions in damages at stake.<br />
<br />
Regardless of the ultimate outcome on this case, most corporate and academic environments today are flush with java based applications. Here is how I am able to offer some reassurance to most clients:<br />
<br />
<br />
<ol style="text-align: left;">
<li>Oracle's primary claims revolve around their contention that the Android java implementation was used to create a competing platform by embedding java in a mobile operating system distributed all over the world.</li>
<li>Oracle does not seem to have a problem with the use of the java environment as a base upon which to build business applications which do not duplicate, attempt to replace or alter core java functionality. In fact, the core licensing documents for java, often referred to as the "<a href="http://download.oracle.com/otn-pub/java/licenses/OTN_JavaEE_Legacy_Binary-Code-License_30Jan2012.txt?AuthParam=1522351091_a5ed6dc1a796970db9e1dda1df418721" target="_blank">Oracle Binary Code License Agreement for Java EE Technologies</a>", specifically anticipates this use case.</li>
</ol>
<div>
Since use cases conforming to #2 are far and away the most prevalent in the business and academic space, I feel confident continuing to recommend java based application development. However, if a client desires to embed java within a device for further distribution, e.g. a new refrigerator or toaster, I would be more inclined to approach Oracle for an appropriate commercial licensing agreement. </div>
<div>
<br /></div>
<div>
This <a href="https://www.bloomberg.com/news/articles/2018-03-27/oracle-wins-revival-of-billion-dollar-case-against-google" target="_blank">Bloomberg Technology article</a> was a good source of reference for this post and is recommended reading. </div>
<div>
<br /></div>
<div>
<span style="font-family: inherit;"><span style="color: #3c3c3c;">The case is </span><a href="https://www.bloomberg.com/quote/JAVA:US" itemprop="StoryLink" itemscope="itemscope" rel="nofollow noopener" style="-webkit-text-decoration-skip: objects; border-bottom-color: rgb(0, 200, 138); border-bottom-style: solid; border-width: 0px 0px 1px; color: #3c3c3c; font-stretch: inherit; font-variant-alternates: inherit; font-variant-east-asian: inherit; font-variant-ligatures: inherit; font-variant-numeric: inherit; font-variant-position: inherit; line-height: inherit; margin: 0px; padding: 0px; text-decoration: none; vertical-align: baseline;" title="Company Overview">Oracle America Inc.</a><span style="color: #3c3c3c;"> v. </span><a href="https://www.bloomberg.com/quote/GOOGL:US" itemprop="StoryLink" itemscope="itemscope" rel="nofollow noopener" style="-webkit-text-decoration-skip: objects; border-bottom-color: rgb(0, 200, 138); border-bottom-style: solid; border-width: 0px 0px 1px; color: #3c3c3c; font-stretch: inherit; font-variant-alternates: inherit; font-variant-east-asian: inherit; font-variant-ligatures: inherit; font-variant-numeric: inherit; font-variant-position: inherit; line-height: inherit; margin: 0px; padding: 0px; text-decoration: none; vertical-align: baseline;" title="Company Overview">Google Inc.</a><span style="color: #3c3c3c;">, 17-1118, U.S. Court of Appeals for the Federal Circuit (Washington). The trial court case is Oracle America Inc. v. Google Inc., 10cv3561, U.S. District Court for the Northern District of California (San Francisco).</span></span></div>
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37067, USA35.9046545 -86.77180169999996935.6988725 -87.094525199999964 36.1104365 -86.449078199999974tag:blogger.com,1999:blog-3038221849737878349.post-28066705854111317652017-11-13T13:37:00.000-06:002017-11-14T09:02:34.814-06:00Patent and Copyright Trolls<div dir="ltr" style="text-align: left;" trbidi="on">
Patent and Copyright Trolls are often called <a href="https://en.wikipedia.org/wiki/Patent_troll" target="_blank">non-practicing entities</a>. These descriptions refer to actors who legitimately own intellectual property in the form of current patents or copyrights, but rather than using them to further commerce or science through research, development or licensing activities, they actively seek opportunities to profit through aggressive infringement litigation and settlement strategies. These players are annoying at best and expensively dangerous to progress at worst. The public policy behind intellectual property ownership is designed to reward innovators and creative efforts with government protection while ideas and forms of expression can be fully developed to move society forward. Large corporations often devote significant capital and time into accumulating large patent portfolios of their own largely as a defensive mechanism against the various forms of Troll organizations. Here is an earlier <a href="http://www.pknlaw.com/2017/02/azure-ip-advantage-includes-oss.html" target="_blank">post</a> discussing an example for a unique customer offering from Microsoft with its Azure platform regarding intellectual property defense.<br />
<br />
This <a href="https://www.whitesourcesoftware.com/whitesource-blog/copyright-and-patent-trolls-in-open-source/?utm_source=act-on&utm_medium=email&utm_term=blog-copyright-and-patent-trolls-in-open-source&utm_campaign=Can%20the%20Open%20Source%20Community%20Slay%20the%20Patent%20and%20Copyright%20Trolls&utm_content=email&&&cm_mmc=Act-On%20Software-_-email-_-Can%20the%20Open%20Source%20Community%20Slay%20the%20Patent%20and%20Copyright%20Trolls-_-Read%20more%20about%20patent%20and%20copyright%20trolls%20%2526amp%3B%20the%20open%20source%20community" target="_blank">article by David Thompson</a> is an interesting read around the potential role of the open source community to address this problem and is well worth your time.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37064, USA35.898723400000009 -86.962408635.48705240000001 -87.607855600000008 36.310394400000007 -86.3169616tag:blogger.com,1999:blog-3038221849737878349.post-19587461378523094012017-08-11T14:49:00.000-05:002017-08-11T14:49:31.706-05:00Open Source for Voting?<div dir="ltr" style="text-align: left;" trbidi="on">
I ran across <a href="https://www.nytimes.com/2017/08/03/opinion/open-source-software-hacker-voting.html" target="_blank">this article</a> in the New York Times recently. It presents a fascinating juxtaposition of modern thinking on software security vulnerability approaches based on open source software with the very real need to ensure confidence in our electoral process. <br />
<br />
I have often made this argument myself in the corporate world but always in the context of saving money and increasing system resiliency. I am not always successful but at least these are arguments that have some traction in most business organizations.<br />
<br />
This spin on why community supported open source can be such a valuable resource to the democratic principles of society is both enlightening and encouraging.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37064, USA35.898723400000009 -86.962408635.48705240000001 -87.607855600000008 36.310394400000007 -86.3169616tag:blogger.com,1999:blog-3038221849737878349.post-14916696677353346192017-07-21T15:12:00.001-05:002017-07-21T15:12:05.103-05:00What is Package Management and why do I care?<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
For a simple overview of the topic, start with this <a href="https://en.wikipedia.org/wiki/Package_manager" target="_blank">Wikipedia entry</a>.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Two of the most common package repositories for open source components are:<br />
<br />
<ol>
<li>The <a href="https://mvnrepository.com/" target="_blank">Maven Repository</a> containing almost 7 million artifacts as of the date of this post</li>
<li>The <a href="https://www.nuget.org/" target="_blank">NuGet Gallery</a> currently hosting about 1 million artifacts concentrated on the Microsoft development platform.</li>
</ol>
<br />
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.<br />
<br />
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 <a href="http://www.microsoft.com/web/webpi/eula/nuget_release_eula.htm" target="_blank">NuGet license</a>. 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.<br />
<br />
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.<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-81606546391163744922017-07-06T16:13:00.000-05:002017-07-06T16:13:49.096-05:00Open Source in the Cloud<div dir="ltr" style="text-align: left;" trbidi="on">
Cloud based infrastructure (IaaS), platform as a service (PaaS), serverless computing, DevOps architecture; these are all enticing concepts to the start-up business wanting to compete instantly with more mature organizations. However new approaches to delivering almost limitless computing capacity via the myriad of cloud offerings available today require a fresh look at how to provision the software powering these new capabilities.<br />
<br />
Traditional software as a service (SaaS) and annual licensing model vendors are struggling to adapt since their normal metrics for billing customers are changing faster than they can update their spreadsheet formulas. How do you charge by the core in an elastic cloud environment? <br />
<br />
I suggest the answer will increasingly be an open source model. Open Source is rarely free of obligation, but it blends smoothly with the new delivery paradigms. While commercial software still has a niche in specialized applications, at least for a while longer, open source is the future. The software powered economy will continue to thrive but the underlying intellectual property is quickly becoming a commodity. Vendors are learning they need to bring value to their customers in the form of exceptional service, providing data insight, and adaption to or even anticipation of ever evolving security threats. Modern customers above all want to avoid the technical debt associated with vendor lock-in which will hamper growth. A closed source model is simply no longer flexible or responsive enough to keep pace.<br />
<br />
A quick spin through capabilities available with the virtual swipe of a credit card from Amazon Web Services, Microsoft Azure, Digital Ocean, and Google Cloud reveals the big players are quickly transforming their business models to adapt and exploit this new landscape with a strong preference for open source.<br />
<br />
How has the cloud changed your software procurement patterns?<br />
<br />
<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-15851931592821824902017-06-09T14:33:00.000-05:002017-06-09T14:33:23.916-05:00I thought that was Open Source???<div dir="ltr" style="text-align: left;" trbidi="on">
I am often asked to look into a product or component where there seems to be confusion as to the licensing model. It is understandable as copyright owners often evolve their products and services in different directions in response to market demands. Here are some of the scenarios I commonly discover:<br />
<br />
<ol>
<li>The product is truly open source, but has changed licensing models at least once if not multiple times throughout its life span. This scenario is fairly easy to address; the user simply has to decide if the latest version with its attendant features and bug fixes is worth the conditions to be compliant with the current license. If so, great. If not, then the user can move back in time to a version released under a more palatable license and start from that fork, understanding that there may not be an active community for support and continued development.</li>
<li>The product is not open source at all, but instead is released under some version of the "freemium" model. A version with restricted functionality or which is time limited can be downloaded with no purchase required. However, since source code is not provided accompanied by a license allowing perpetual use, creation of derivative works, and further distribution, it is definitely not open source. Users are often the most disappointed in this outcome as it has somewhat of a deceptive feel.</li>
<li>The product was released under a valid open source license up to a certain point in its development, but then the copyright holder chooses to evolve the code in a proprietary fashion and only offer new releases under commercial licensing terms. Most often the open source community which grew up around the original code line falls away once they understand there will be no further commitment from the copyright holder to the open source branch. While this scenario is understandable from the copyright holder's perspective, it can be seen as "burning a bridge" to the open source community. It would be very difficult to once again leverage the benefits of the open source contribution models once a project owner had followed this path.</li>
<li>By far the most common discovery is that a product has both a community edition and a commercial offering; the latter offering support and the latest features with the community edition lagging behind one or two releases. This is often encouraging to potential consumers as it gives them a "try before you buy" option or even a chance to influence both versions of the product by becoming an active member of the community. I usually encourage clients to begin with the community version, get involved and see what they can achieve. Then if the product becomes a crucial part of their business plan, they have the option to upgrade to the commercial level at any time.</li>
</ol>
<br />
Each of these scenarios can present problems to potential consumers, but with solid information as to licensing lineage there are also opportunities to be found.<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-75329258166431784622017-05-19T11:50:00.001-05:002017-05-19T11:50:26.857-05:00Artifex v. Hancom - OSS as Copyright or Contract?<div dir="ltr" style="text-align: left;" trbidi="on">
I ran across a very interesting article the other day (<a href="https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/?utm_source=" target="_blank">Keith Collins as published in Quartz on 11 May 2017</a>). It discusses a recent case filed in the US District Court for the Northern District of California, <a href="https://scholar.google.com/scholar_case?case=37795293356107925&q=artifex+v+hancom&hl=en&as_sdt=3,24" target="_blank">Artifex Software, Inc. v. Hancom, Inc.</a><br />
<br />
The gist of the dispute involves a software component published by Artifex under the GPLv3 open source license. It was also made available under a proprietary commercial licensing option for consumers wishing to commercialize the component. Hancom apparently wanted the best of both worlds, used the software under the terms of the GPL, yet refused to follow the terms regarding publishing derivative and or combined works under the GPL.<br />
<br />
Artifex filed suit resulting in an interesting court order in response to Hancom's motion to dismiss. Essentially, Judge Jacqueline Scott Corley ruled in part that Artifex could pursue its claim under a breach of contract theory. <br />
<br />
<blockquote class="tr_bq">
<span style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; display: inline !important; float: none; font-family: Arial, sans-serif; font-size: 15px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">Defendant contends that Plaintiff's reliance on the unsigned GNU GPL fails to plausibly demonstrate mutual assent, that is, the existence of a contract. Not so. The GNU GPL, which is attached to the complaint, provides that the Ghostscript user agrees to its terms if the user does not obtain a commercial license. Plaintiff alleges that Defendant used Ghostscript, did not obtain a commercial license, and represented publicly that its use of Ghostscript was licensed under the GNL GPU. These allegations sufficiently plead the existence of a contract.<span class="Apple-converted-space"> </span></span><i style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; font-family: Arial, sans-serif; font-size: 15px; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">See, e.g.,<span class="Apple-converted-space"> </span></i><a href="https://scholar.google.com/scholar_case?case=2181612481905015321&q=artifex+v+hancom&hl=en&as_sdt=3,24" style="-webkit-text-stroke-width: 0px; background-color: white; color: #660099; font-family: Arial, sans-serif; font-size: 15px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-decoration: underline; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><i>MedioStream, Inc. v. Microsoft Corp.,</i><span class="Apple-converted-space"> </span>749 F. Supp. 2d 507, 519 (E.D. Tex. 2010)</a><span style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; display: inline !important; float: none; font-family: Arial, sans-serif; font-size: 15px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">(concluding that the software owner had adequately pled a claim for breach of a shrink-wrap license).</span></blockquote>
<br />
<br />
This appears to be a new approach in these types of actions which are more often discussed in solely terms of copyright violations.<br />
<br />
It will be interesting to follow this case and see the ramifications to the broader interests of open source publishers and their ability to enforce the terms of the licenses chosen.<br />
<br />
Stay tuned....</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN 37064, USA35.898723400000009 -86.962408635.48705240000001 -87.607855600000008 36.310394400000007 -86.3169616tag:blogger.com,1999:blog-3038221849737878349.post-83333377143349487352017-03-31T13:49:00.000-05:002017-03-31T13:49:23.934-05:00OSS Governance Policy<div dir="ltr" style="text-align: left;" trbidi="on">
Open Source Software governance in the corporate context is the first step to both realizing the many benefits of OSS as well as mitigating any potential risks. Any good governance process should begin with a corporate policy spelling out the parameters of its applicability and purpose.<br />
<br />
<ul style="text-align: left;">
<li><u>Policy Applicability</u>: The policy should explicitly indicate who is covered. For OSS purposes, the most common actors are employees, vendors, outside agents or contractors who use open source software in the performance of their responsibilities on the company's behalf.</li>
</ul>
<br />
<ul style="text-align: left;">
<li><u>Policy Statement</u>: The policy should include an affirmative statement of what is permitted subject to any review and approval processes. At the policy level it is best to avoid laying out specific operational processes as these are often subject to change. But it is helpful if the policy delineates the parameters and purpose of what expected governance processes will cover. Examples might include:</li>
<ul>
<li>ensuring license compliance</li>
<li>understanding provenance</li>
<li>evaluation and mitigation of risk to company intellectual property</li>
<li>indication of the various stakeholders to participate in review; legal, architecture, security, quality etc.</li>
<li>establishing an executive owner and providing for waiver discretion</li>
</ul>
</ul>
<br />
<ul style="text-align: left;">
<li><u>Business Purpose</u>: Since all corporate policies should exist for the purpose of achieving organizational goals, a good open source policy will describe the nature of the OSS ecosystem and why it is desirable to participate. This background information will be useful as the policy is interpreted over time as necessary to evolve specific governance processes to meet new challenges and opportunities.</li>
</ul>
<br />
Finally, as a practical matter, I have found it better to address open source consumption policy separately from active participation and contribution to OSS community projects. Many times an organization will find it beneficial to acclimate itself to the consumption side of the equation first while building confidence through experience. <a href="http://www.pknlaw.com/2017/03/open-source-contribution-policy.html" target="_blank">Active community participation and contribution are a natural progression and often best served by separate policy considerations once the consumption processes are mature and functioning smoothly.</a><br />
<br />
Next up, I will begin addressing ideas for specific OSS governance processes.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-5979917914233117042017-03-31T13:47:00.001-05:002017-03-31T13:47:12.752-05:00Open Source Contribution Policy Considerations<div dir="ltr" style="text-align: left;" trbidi="on">
I have addressed Open Source Policy as a need for any organization which intends to consume from or contribute to the Open Source Community. Such policies are critical to form the foundation upon which good governance processes can be constructed and put effectively into daily operation.<br />
<br />
I thought it might be helpful to further discuss the policy needs as it relates specifically to the contribution side of the equation.<br />
<br />
There are many reasons why an organization may consider becoming an active contributor to one or more open source projects:<br />
<ol>
<li>Cost efficiencies - contributing simple bug fixes and feature enhancements needed by the organization back to the community edition can save enormous time and resources in the long run</li>
<li>Quality - a vibrant community supporting a project will most always result in a better project since every consumer is also a tester</li>
<li>Security - contributors have a vested interest in secure code. They take great pains to ensure their contributions follow best practices and reduce attack surfaces and vulnerabilities wherever possible in order to keep a project viable and a good long term investment.</li>
<li>Reducing technical debt - every software platform or architecture decision comes with a certain level of commitment and open source is no different. Active contributors ensure they have a voice in a project's direction and longevity ensuring the maximum return for their efforts.</li>
</ol>
This is by no means an exhaustive list but it is enough to justify the creation of a solid contribution policy for an organization to build upon in order to realize these and other benefits of open source.<br />
<br />
So, here are my suggestions for how a good open source contribution policy should be crafted:<br />
<br />
<ul>
<li>State objectives explicitly in the policy. This will help guide process development for policy implementation. The four reasons listed above are a good starting point and there are always others which may be specific to your client.</li>
<li>Don't lay out specific governance processes or procedures in the policy. This will not allow for the normal evolution required in such a dynamic area. Instead, list the subject matter which the policy expects to be covered by governance and implementation. Here are few examples:</li>
<ul>
<li>Evaluation of OSS license compatibility to business goals</li>
<li>Evaluation of patent/trademark questions</li>
<li>Quality controls including security issues</li>
<li>Criteria for evaluating a community compatible with business goals and culture</li>
</ul>
<li>Clearly articulate who or what team is accountable to implement the policy, make final decisions on governance, and grant exceptions when necessary.</li>
<li>Set up clear expectations for artifact record keeping, including where process definitions, instructions and training materials will reside.</li>
<li>Include a definitive statement for policy applicability. For example, does it apply to contractors as well as employees?</li>
<li>Indicate a time schedule for policy review to ensure updates are considered as needed.</li>
</ul>
<br />
Policy drafting is often viewed as less than useful, but if done with thoughtful input from those impacted it can enable clients to reach their open source goals.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-80505610819458693312017-03-17T13:29:00.001-05:002017-03-17T13:29:42.196-05:00Open Source Provenance<div dir="ltr" style="text-align: left;" trbidi="on">
It seems like common sense. In order to analyze potential risks for consuming a particular open source component or application, it is necessary to understand who owns the copyright and under what terms the owner has licensed it to the community.<br />
<br />
However, as anyone who has delved into the OSS world knows these questions more often result in muddled answers than crystal clear ones. Several reasons for the confusion become obvious once you step back and understand the nature of open source software:<br />
<br />
<ul>
<li>OSS often begins with an individual who was simply trying to solve a particular problem or need and thought others might like to try their solution and perhaps improve upon it. Such informal circumstances mean not much attention is paid to the OSS license chosen, and of course as is a copyright holder's prerogative, subsequent iterations of the same component are often released under different licenses over time.</li>
<li>OSS components are often bundled together into derivative works which taken as a whole address some larger problem, business or academic need. These derivative works are sometimes assigned licenses without regard for terms applicable to the base components or downstream compatibility.</li>
<li>Communities which manage an OSS project will often have contributors acknowledge a contribution agreement before submitting a new feature or bug fix. Most agreements I have reviewed contain all the basics one would expect but does the community carefully research the provenance of all the code submitted to ensure license compatibility?</li>
<li>Automated tools which scan code for license hints or even snippets of previously licensed code through sophisticated text comparison algorithms can often reveal a plethora of resulting "hits" and false positives to weed through.</li>
<li>It is becoming a common business model for companies to purchase the underlying copyrights for a popular open source project. This often results in a roadmap where certain versions or features are retained in an open source community edition while the newest capabilities are only provided via traditional proprietary licensing. And the line between the two is often shifting by design to maximize adoption and exploitation of the intellectual property.</li>
</ul>
<br />
Given all these potential concerns, how best to advise our clients?<br />
<br />
How does your organization address such issues?<br />
<br />
My approach is outlined next time.<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0tag:blogger.com,1999:blog-3038221849737878349.post-68058349795138907372017-03-09T16:09:00.000-06:002017-03-17T12:59:02.206-05:00Licensing Obligations - Copyleft or Viral Requirements<div dir="ltr" style="text-align: left;" trbidi="on">
<u>Copyleft or Viral Requirements</u>: These requirements are either some of the most onerous in the open source world, or they are the reason open source has flourished. It is really just a matter of perspective.<br />
<br />
At its most basic, copyleft (a play on the word copyright) terms require that a consumer who uses an OSS component to create any manner of derivative work, or perhaps causes such a component to be redistributed to others, or both, to license the entire resulting work product under the terms of the copyleft license at issue. This attachment of terms and conditions is sometimes why these licenses are referred to as viral in nature.<br />
<br />
There are many nuances to these licenses depending on specific use cases and one's interpretation of their obligations. However, there is agreement among professionals attempting to navigate these waters that it can be tricky at times.<br />
<br />
Examples include:<br />
<ol style="text-align: left;">
<li>GNU GPL - version three found <a href="https://www.gnu.org/licenses/gpl-3.0.en.html" target="_blank">here</a></li>
<li>GNU LGPL - version three found <a href="https://www.gnu.org/licenses/lgpl.html" target="_blank">here</a></li>
<li>GNU Affero GPL - version three found <a href="https://www.gnu.org/licenses/agpl.html" target="_blank">here</a></li>
<li>OSL - version three found <a href="http://rosenlaw.com/pdf-files/OSL3.0-comparison.pdf" target="_blank">here</a></li>
</ol>
<br />
<br />
Corporate OSS consumers tend to be wary of these licenses with reciprocal terms because they limit an entity's ability to exploit the code for commercial purposes. Conversely, those who choose these licenses to protect their intellectual property tend to do so exactly for the same reason, so that the code remains freely available for anyone to use, consistently available under the same licensing scheme without fear that later iterations will be walled off into some unacceptable proprietary licensing framework.<br />
<br />
I am firmly convinced these licenses have their place within the OSS ecosystem. However, it is imperative that individuals or organizations which contemplate using code subject to their terms fully understand both the freedom of use and reciprocal obligations which accompany the intellectual property in question.<br />
<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0tag:blogger.com,1999:blog-3038221849737878349.post-47888947104140059822017-03-03T13:28:00.000-06:002017-03-09T16:10:30.116-06:00Licensing Obligations - Source Code Availability Requirements<div dir="ltr" style="text-align: left;" trbidi="on">
<u>Source Code Availability Requirements</u>: It is not unusual for an open source license to require downstream consumers make the component source code easily available as a condition of use. This requirement nurtures the open source culture by ensuring any end user can have access to review and obtain copies of open source licensed code from applications in which they have an interest.<br />
<br />
A few examples of common open source licenses where this requirement is expressed to one degree or another include:<br />
<br />
<ul>
<li>Apache License 2.0</li>
<li>Mozilla Public License 2.0</li>
<li>Common Development and Distribution License 1.0</li>
<li>GNU GPL 2.0</li>
</ul>
<div>
<br />
Depending on the specific license involved, the source code requirement may be triggered by distribution or the creation of a derivative work or both.<br />
</div>
<div>
</div>
<div>
In order to consistently comply with the spirit of these requirements across multiple licenses in a given organization, I have found an obligation statement similar to the following satisfies or exceeds the majority of license terms in this category and is easily understood by business and technology resources:<br />
</div>
<div>
</div>
<div>
<em>"Component source code and supporting files must be made available in a timely manner to any end user through a reasonable request process."</em></div>
<div>
<em></em><br />
</div>
<div>
Such an approach allows software architects to plan on common compliance schemes such as providing web links to a publically available library of open source code or a soft transfer to an online knowledgebase or helpdesk request process.</div>
<div>
</div>
<div>
Next up, <a href="http://www.pknlaw.com/2017/03/licensing-obligations-copyleft-or-viral.html" target="_blank">Copyleft or Viral requirements</a>.</div>
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-22420208741237654692017-02-22T11:19:00.000-06:002017-03-03T13:29:29.665-06:00Licensing Obligations - Endorsement Restrictions<div dir="ltr" style="text-align: left;" trbidi="on">
<u>Endorsement Restrictions</u>: It is very common for an open source license to restrict use of the various contributor names, companies and or product names which may be associated with the creation of or enhancement to an open source project. This restriction allows people and entities to freely participate in the community driven development process without concern that downstream consumers or re-distributors might misappropriate or cause market confusion with valuable, often trademark protected intellectual property.<br />
<br />
<br />
I have found an obligation statement similar to the following, modeled after the 3rd clause in the <a href="https://opensource.org/licenses/BSD-3-Clause" target="_blank">BSD 3-Clause license</a>, satisfies or exceeds the majority of license terms in this category and is easily understood by business and technology resources:<br />
<br />
<em>"Neither the organization nor the names of contributors to the components may be used to endorse or promote products derived from the components without specific prior written permission."</em><br />
<em></em><br />
Next up, <a href="http://www.pknlaw.com/2017/03/licensing-obligations-source-code.html" target="_blank">source code availability requirements</a>.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-24630488591203700232017-02-13T13:58:00.000-06:002017-02-14T09:27:11.531-06:00How to do Public Domain the Right Way<div dir="ltr" style="text-align: left;" trbidi="on">
I ran across this excellent <a href="http://www.techtimes.com/articles/197075/20170212/art-for-free-met-museum-releases-thousands-of-artwork-images-for-unrestricted-use.htm" target="_blank">article</a> today in the Tech Times. It describes how the <a href="http://www.metmuseum.org/art/collection#!?perPage=20&showOnly=openaccess&sortBy=Relevance&sortOrder=asc&offset=0&pageSize=0" target="_blank">New York Metropolitan Museum of Art</a> has as of 7 February 2017 released approximately 375,000 high resolution images of its copyrighted artwork under the <a href="https://creativecommons.org/publicdomain/zero/1.0/legalcode" target="_blank">Creative Commons Zero</a> ("CC0") license.<br />
<br />
While I certainly appreciate the Met's effort to share its collection with the world, from an open source attorney's perspective I applaud their choice of the CC0 license to do so.<br />
<br />
It doesn't happen very often, but when I run across software intellectual property in the public domain, it can be challenging to trace the provenance back to an explicit grant upon which I feel comfortable advising a client to place their reliance. Since to my knowledge the earliest software was created in the 1940's and 1950's, it has probably not been in existence long enough for statutory periods to run. Therefore a grant is best. I have found some very simply one sentence grants that have to serve on occasion and from a practical standpoint have not been successfully challenged. But I am much more confident in something with additional substance that attempts to cover specific ground such as:<br />
<br />
<ol>
<li>List of IP rights being addressed</li>
<li>Waiver of those rights</li>
<li>Fallback clause to try to catch any exceptions or loopholes created by specific jurisdictions or future changes or interpretations of law</li>
<li>Limitations of Warranty and Disclaimers to protect the grantor(s) and retain patent and or trademark rights</li>
</ol>
In my mind the CC0 is best of breed for accomplishing a grant to the public domain and is an excellent vehicle for most such efforts.<br />
<br />
Now I just need to work some of these cool Met images into my next presentations :-)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7Z8OSxy_S2juMGP10J4LyGC7ix2AU0CcMnBmOJ9l3UVbgzb8tnGz2ylb0LXdDFIhZPLVG8V9ktj-BQbI60ZYy3yuZhZrpBBQSMvyTb9yOerziAkGYZJEoE0KT05mRupWo53FBmWtk4qY/s1600/Geometria+-+NY+Met.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7Z8OSxy_S2juMGP10J4LyGC7ix2AU0CcMnBmOJ9l3UVbgzb8tnGz2ylb0LXdDFIhZPLVG8V9ktj-BQbI60ZYy3yuZhZrpBBQSMvyTb9yOerziAkGYZJEoE0KT05mRupWo53FBmWtk4qY/s320/Geometria+-+NY+Met.png" width="183" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<span style="font-size: xx-small;">© 2000–2017 The Metropolitan Museum of Art. All rights reserved.</span></div>
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-48529166117595464202017-02-08T14:59:00.000-06:002017-02-08T15:01:57.713-06:00Azure IP Advantage includes OSS<div dir="ltr" style="text-align: left;" trbidi="on">
I saw this about Microsoft Azure today and was intrigued: <br />
<br />
<blockquote class="tr_bq">
<span style="background-color: #f0f1f1; color: black; display: inline; float: none; font-family: "segoeui" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 15px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Microsoft Azure customers now have access to best-in-industry protection against intellectual property (IP) risks in the cloud with Microsoft Azure IP Advantage program. One of the most comprehensive protection programs, it is designed to help customers protect their cloud-based innovations and investments against IP lawsuits and risks. We take seriously our responsibility to help ensure that the cloud is used for good. In partnership with our customers, we are working hard to help create an ecosystem where developers, entrepreneurs, enterprises, and customers can innovate with confidence.</span></blockquote>
See full information here: <a href="https://azure.microsoft.com/en-us/overview/azure-ip-advantage" target="_blank">Azure IP Advantage.</a><br />
<br />
For those of you consulting with clients on the benefits and risks of public cloud deployments it appears to be a new development in the industry which should certainly be considered.<br />
<br />
Of course this feature is brand new and as far as I am aware untested, but I certainly commend Microsoft for addressing the problem directly. <br />
<br />
I really like the "Springing License" and "Patent Pick" components and am especially impressed that the new policy <u>expressly includes open source code</u> in its indemnity pledge for Azure services. <br />
<br />
See the details in the <a href="https://www.microsoft.com/en-us/trustcenter/compliance/azureipadvantage" target="_blank">FAQ</a> and receive a copy of the full terms and conditions from <a aria-label="IPAdvant@microsoft.com" class="c-hyperlink" href="mailto:IPAdvant@microsoft.com" style="-webkit-text-stroke-width: 0px; background-color: #f0f1f1; box-sizing: inherit; color: #0078d7; font-family: SegoeUI, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; orphans: 2; outline: 0px; text-decoration: underline; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;" target="_blank" title="IPAdvant@microsoft.com">IPAdvant@microsoft.com</a><br />
<br />
I wonder if and when Google and Amazon will respond?</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0tag:blogger.com,1999:blog-3038221849737878349.post-30606501481986694862017-02-01T15:30:00.000-06:002017-02-22T11:20:25.348-06:00Licensing Obligations - Attribution, License Text Visibility and Re-distribution<div dir="ltr" style="text-align: left;" trbidi="on">
Open source licenses range from extremely simple, single sentence expressions of a copyright holder's terms to very professional, multi-paragraph documents covering everything from attribution to patent protection provisions. However, most licenses have terms creating categories of obligation on the part of each licensee. I have found it useful to group these obligations by type and draft clear business language interpretations in order to achieve compliance with both the letter and spirit of applicable licensing terms. My personal preference is to err on the side of a conservative interpretation when preparing these obligation statements. This allows a governance process to be largely automated through your choice of simple workflow tools. With this approach, only exceptional use cases require manual scrutiny and more precise analysis to ensure protection of both licensor and licensee interests.<br />
<br />
<u>Attribution</u>: It is very common for a license to specify one or more specific conditions requiring that the content creator(s) be given explicit credit for their work.<br />
<br />
<u>License Visibility and Re-distribution</u>: Many OSS licenses require license text be retained with the covered components. Sometimes there are explicit requirements for display at run time or acknowledgement alongside any other expression of copyright or license. It is also very common to require inclusion of the license text in the event components are redistributed either stand-alone or as part of a derivative work.<br />
<br />
<br />
I have found an obligation statement similar to the following satisfies or exceeds the vast majority of license terms in both categories and is easily understood by business and technology resources:<br />
<br />
"<em>The full text of the applicable <license name and version> license including warranty disclaimers and all copyright, patent, trademark and attribution notices from the components must be made available for end user review through an appropriate user interface at all times and or a copy of the <license name and version> license must be distributed with the components as applicable.</em>" <br />
<br />
Next up, <a href="http://www.pknlaw.com/2017/02/licensing-obligations-endorsement.html" target="_blank">endorsement restrictions</a>.<br />
<br />
<br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-85020137087651376572017-01-19T15:00:00.000-06:002017-01-19T15:00:08.981-06:00OSS Governance - Use Case Approach<div dir="ltr" style="text-align: left;" trbidi="on">
Once a good corporate policy is in place to support open source consumption and or contribution for your organization, it is time to think about how to implement governance processes consistent with policy goals.<br />
<br />
I prefer a use case based approach to set up a good decision making framework. While communication and workflow processes will vary with the administrative infrastructure of an organization, the basic use case parameters should be fairly consistent. My recommendation for the core focus areas of each use case is as follows:<br />
<br />
<ol style="text-align: left;">
<li><u>OSS component technical evaluation</u> - First and foremost open source components or applications should be a good technical solution for the business problem at hand. They should also fit within any established enterprise architecture frameworks established as a strategic direction for the organization. </li>
<li><u>OSS component security evaluation</u> - The prospective component should be scanned or otherwise evaluated for risk factors which might introduce an undesired vulnerability into your organization. </li>
<li><u>Method of use</u> - Will the component be used exactly as received from the community? Or will modifications be necessary to achieve desired results? Can it be isolated/abstracted from internal code or must it be directly embedded in existing projects to be effective? Sometimes this last distinction is discussed in terms of dynamic or static references.</li>
<li><u>Method of distribution</u> (if any) - Will the component be used internally only? Will it be hosted on a company web site or deployed to an internal cloud? Will it be installed at a third party (customer or hosting facility)? Will it become part of a standard distribution package (shrink wrapped or via electronic delivery)?</li>
<li><u>Applicable license terms</u> - The answers to the use case questions above must then be analyzed through the lens of the license(s) involved. As noted in earlier posts about license types, certain license types are more permissive while others can be very prescriptive in the obligations imposed on the consumer.</li>
</ol>
I like to think of the first four use case parameters as the input needed from the requestor. Depending on the use case, the requestor might be an internal product software development organization or perhaps just a business unit desiring to use an open source word processing application.<br />
<br />
The licensing parameter is where a good OSS attorney can add value by providing advice on how to avoid unnecessary risks while still taking full advantage of the benefits open source has to offer.<br />
<br />
Up next, I will discuss different types of licensing obligations found in open source and suggestions for compliance strategies.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0tag:blogger.com,1999:blog-3038221849737878349.post-66553155042829265782016-12-31T16:24:00.000-06:002016-12-31T16:24:04.093-06:00 IP Considerations for Releasing OSS (part 3 of 3)<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://www.pknlaw.com/2016/12/ip-considerations-for-releasing-oss.html" target="_blank">Continued from IP Considerations for Releasing OSS Part 2</a><br />
<u><a href="http://www.pknlaw.com/2016/12/ip-considerations-for-releasing-oss.html" target="_blank"><br /></a></u><br />
<u><br /></u>
<u>Trademarks.</u> Trademarks in the form of individual or organization names, symbols, designs etc. are often one of the most valuable aspects of intellectual property applicable to software. Purchasing and or OSS utilization decisions can be heavily influenced by a well known trademark's reputation for quality, performance and stability. Many practitioners agree that a trademark would be lost if included as part of a software's OSS licensing terms. This is because trademark law encourages an owner to maintain control over product quality bearing the mark. Since a basic principle of OSS licenses is to allow creation of derivative works, such control would be untenable in an open source scheme.<br />
<br />
Consequently, open source licenses do not include a trademark license and many explicitly preclude use of the copyright owner's name or other identifying marks as endorsement or promotion of derivative works.<br />
<br />
<u>Trade Secrets.</u> IP which an organization chooses to protect through trade secrecy restrictions should never be part of an open source project since the source code is published to the world.<br />
<br />
<span style="font-size: xx-small;">Please see these </span><a href="http://www.pknlaw.com/2016/12/oss-resources.html" target="_blank"><span style="font-size: xx-small;">sources</span></a><span style="font-size: xx-small;"> for a more in-depth discussion of these topics.</span></div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-84075431697575704022016-12-24T10:21:00.000-06:002016-12-31T16:25:56.926-06:00IP Considerations for Releasing OSS (part 2 of 3)<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://www.pknlaw.com/2016/12/ip-considerations-for-releasing-oss_34.html" target="_blank">Continued from IP Considerations for Releasing OSS Part 1</a><br />
<u></u><br />
<u>Patents.</u> Unlike copyrights which provide creators with exclusive rights to <em>do</em> certain activities, patents can be thought of as providing owners with the right to <em>prevent</em> others from doing certain things with the subject matter of their patents. Examples according to the U.S. Patent Act, <em>35 U.S.C. § 154 </em>include:<br />
<ol>
<li>right to exclude others from making products embodying a patented invention</li>
<li>right to exclude others from using products embodying a patented invention</li>
<li>right to exclude others from selling or offering for sale products embodying a patented invention</li>
<li>right to exclude others from importing products embodying a patented invention</li>
</ol>
Since commercial exploitation of these rights is often the reason for investing in patent prosecution, entities should weigh the "cost" of OSS licensing which implicates such patents against other goals such as market disruption or advantage of quickly establishing a public industry standard.<br />
<br />
Software published under an appropriate OSS license can still assert patent ownership, but the OSS license chosen should explicitly license any implicated patent rights to the OSS consumer as necessary for full software utilization. Otherwise adoption will be severely limited.<br />
<br />
Additionally, several OSS choices include what is sometimes called a "Patent Peace" provision. Such a provision can take various forms but usually terminates a licensee's rights to the original work if the licensee initiates a patent action against the licensor or often any licensee of the covered work. The intended effect is to specifically deter over reaching by downstream consumers while also discouraging such litigation in the OSS community at large.<br />
<br />
Next, <a href="http://www.pknlaw.com/2016/12/ip-considerations-for-releasing-oss_31.html" target="_blank">trademark and trade secret considerations.</a><br />
<br />
<span style="font-size: xx-small;">Please see these </span><a href="http://www.pknlaw.com/2016/12/oss-resources.html" target="_blank"><span style="font-size: xx-small;">sources</span></a><span style="font-size: xx-small;"> for a more in-depth discussion of these topics.</span></div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-1262727972936468472016-12-20T13:04:00.000-06:002016-12-24T10:23:39.259-06:00IP Considerations for Releasing OSS (part 1 of 3)<div dir="ltr" style="text-align: left;" trbidi="on">
The decision to release software under an open source license has some nuances requiring careful consideration to ensure desired goals are achieved. For purposes of this discussion, I will be approaching the question from the perspective of releasing an original work, though the same considerations apply when contemplating contribution to an existing community project with an established license and contributor policy.<br />
<br />
The first concept to understand is that software is the result of an intellectual endeavor resulting in the creation of both:<br />
<ul style="text-align: left;">
<li>intellectual property rights</li>
<li>rights to control copies of IP and any resulting distribution through any medium </li>
</ul>
<div style="text-align: left;">
It is important to realize the original creator (or their employer) has the right to separately license one or both types of property rights to as many different parties as desired.</div>
<br />
An organization considering publication under an open source license has multiple options to choose from varying by type and degree of IP protection. OSS allows and in fact encourages very liberal downstream distribution by nature so I will focus this series of posts on basic IP rights and related factors which should influence an OSS publication decision.<br />
<br />
<u>Copyrights.</u> <em>Copyright protection subsists ... in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device ... (17 U.S.C. § 102.)</em><br />
<br />
Even the simplest of OSS licenses tend to adequately provide for the reservation of copyright to the creator. But an OSS publisher should understand that many exclusive rights accruing to a copyright owner are immediately licensed to an OSS consumer under most OSS choices:<br />
<ol>
<li>right to make copies</li>
<li>right to prepare derivative works</li>
<li>right to distribute original or derivative works</li>
</ol>
It is probably best to think of an OSS license scheme as preserving basic copyright protection while actively encouraging the easiest path to wide dissemination and adoption within target user groups. Given this generalization, the specific OSS license chosen will then often influence the level of downstream adoption, contribution and further development by an active user community.<br />
<br />
Next up, <a href="http://www.pknlaw.com/2016/12/ip-considerations-for-releasing-oss.html" target="_blank">Patent considerations</a>.<br />
<br />
<br />
<span style="font-size: xx-small;"><span style="font-family: "times new roman" , "serif"; line-height: 115%;">Please see these <a href="http://www.pknlaw.com/2016/12/oss-resources.html" target="_blank">sources</a> for a more in-depth
discussion of these topics</span>.</span><br />
</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-18892147433437206662016-12-15T15:40:00.000-06:002016-12-15T15:40:21.880-06:00OSS License Types (Part 3 of 3) - Reciprocal Licenses<div dir="ltr" style="text-align: left;" trbidi="on">
This third post in the license type series will review the category of licenses often referred to as having a reciprocal nature.<br />
<ol>
<li><a href="http://www.pknlaw.com/2016/12/oss-license-types-part-1-of-3.html" target="_blank">Permissive licenses</a></li>
<li><a href="http://www.pknlaw.com/2016/12/oss-license-types-part-2-of-3-corporate.html" target="_blank">Corporate licenses</a></li>
<li>Reciprocal licenses</li>
</ol>
This group of licenses are called reciprocal because the licensee is usually required to adopt the license of the consumed component when creating and distributing any derivative works. Since the terms of the licenses generally require full source code disclosure, the ramifications of such reciprocity should be carefully considered. Sometimes we will see these licenses referred to as:<br />
<ol style="text-align: left;">
<li> "copyleft" - a play on the IP term "copyright", or</li>
<li> "viral" - because they "infect" any larger bodies of work upon incorporation, or</li>
<li>"hereditary" - because once these reciprocal terms take hold on a project they are passed down through the progeny of the software line</li>
</ol>
Common examples include:<br />
<ol>
<li>GPL (all versions) - GNU General Public License</li>
<li>LGPL - Lesser General Public License - this one is a little less onerous from a compliance perspective</li>
<li>AGPL - Affero GPL</li>
<li>OSL - Open Software License</li>
</ol>
Downstream reciprocity requirements imposed by these licenses require very careful use case analysis when contemplated in a commercial context to ensure business goals align with any required source code disclosures. Special attention must be directed to the definitions of derivative and collective works since the licenses themselves do not always use the generally accepted terms or definitions as established by copyright law. In addition, reciprocity is often triggered by distribution which is not always clearly defined by the terms of the license itself. There are a handful of reported interpretations by various courts which are somewhat informative and will be the subject of another post.<br />
<br />
In summary, advising clients on the use of OSS components subject to this category of licenses requires careful scrutiny of both the applicable license terms and the business intent driving a proposed use case. These licenses do serve a particular purpose within the broader market but must be approached with caution in order to avoid undesirable consequences.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664tag:blogger.com,1999:blog-3038221849737878349.post-23819048991541406122016-12-13T09:25:00.001-06:002016-12-15T15:41:16.848-06:00OSS License Types (Part 2 of 3) - Corporate Licenses<div dir="ltr" style="text-align: left;" trbidi="on">
This second post in the license type series will elaborate on what can be referred to as the corporate license category.<br />
<ol>
<li><a href="http://www.pknlaw.com/2016/12/oss-license-types-part-1-of-3.html" target="_blank">Permissive licenses</a></li>
<li>Corporate licenses</li>
<li><a href="http://www.pknlaw.com/2016/12/oss-license-types-part-3-of-3.html" target="_blank">Reciprocal licenses</a></li>
</ol>
<br />
We refer to these licenses as "corporate" because they are usually created by companies as a middle ground between permissive/academic licenses and reciprocal licenses.<br />
<br />
Downstream obligations for this category require careful use case analysis but can often be acceptable in a commercial context given proper planning and attention to license restrictions.<br />
<br />
Examples include:<br />
<ol>
<li>Apache - Apache Software Foundation</li>
<li>MPL - Mozilla Public License (Netscape)</li>
<li>CPL - Common Public License (IBM)</li>
<li>EPL - Eclipse Public License (IBM)</li>
<li>CDDL - Common Development and Distribution License (Sun Microsystems)</li>
<li>Microsoft Code Sharing License (Microsoft)</li>
</ol>
<br />
Unlike the other two categories, these licenses show clear signs of professional, attorney led draftsmanship. As a consequence, many of them address traditional intellectual property concerns one would expect to find in a more formal license agreement. These express terms are often welcomed by consumers and publishers alike since they directly address issues often left open to interpretation by the other two license groups. Examples include:<br />
<div>
</div>
<ol>
<li>Trademarks, often in the context of promotional use restrictions</li>
<li>Patents, often in the form of a patent peace provision</li>
<li>Warranty disclaimers and limitations of liability</li>
<li>Indemnification provisions</li>
<li>Clear definitions of important terms and concepts</li>
<li>Choice of law provisions</li>
<li>Export restrictions</li>
<li>Integration provisions</li>
</ol>
From a practical perspective, these licenses tend to take more time to evaluate. They are more extensive in their terms and more exact in their language. However, most in-house counsel and their outside counterparts appreciate the clarity these licenses can bring to a potential project. It is often easier to line up business objectives cleanly without the ambiguity of the simpler academic licenses and the sometimes obtuse language of the principle driven reciprocal options.<br />
<br />
Next up, reciprocal license alternatives can be challenging but workable in appropriate circumstances.</div>
P. Kevin Nelsonhttp://www.blogger.com/profile/13932331310181974643noreply@blogger.com0Franklin, TN, USA35.9250637 -86.868889935.7192797 -87.1916134 36.130847700000004 -86.5461664