Agreed. Just saying that if the software is important to the community, but the distribution/licensing terms are not, there's always a solution. That's all I was trying to get at. If, however, resources don't avail themselves, that can also be indicative that the need vs issue isn't overwhelming.
Increasingly, I am asking these questions of people who are willing to replace CAPX solutions with high internal OPEX. The answer continues to be that they've made their decision to alleviate lock-in. But there's always a trade-off, as you've just highlighted. On Mon, Dec 12, 2016 at 8:47 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > On 12 December 2016 at 16:35, Ash <a...@wildernessvoice.com> wrote: > >> I tend to agree with you, Sean. Also, if there's a concern that some >> project has changed its license, then just create a fork. In the case of >> this previously GPL code, it will at least be re-distributable. In the end, >> I just don't think this is a huge issue that cannot be easily managed. >> > > Creating a fork is easy. Maintaining a fork against bitrot, and managing > the drift between the 'official' version and the fork, is a task that > requires resources that are hard to find. > > We've put up patches to remove (At least) two drivers for exactly this > sort of switch before, and I think it was the right thing to do then and > now. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev