Re: [libvirt] [PATCH v2] lxc: fuse mount for /proc/cpuinfo

On Thu, Sep 24, 2015 at 03:53:24PM +0000, Serge Hallyn wrote: > Quoting Daniel P. Berrange (berrange(a)redhat.com): > > On Thu, Sep 24, 2015 at 02:41:49PM +0000, Serge Hallyn wrote: > > > Quoting Fabio Kung (fabio.kung(a)gmail.com): > > > > On Wed, Sep 16, 2015 at 12:29 PM, Serge Hallyn <serge.hallyn(a)ubuntu.com&gt; wrote: > > > > > > > > > > Ok, so I could create a project on github, but that doesn't come with > > > > > a m-l. Last I used it, sf was problematic. Any other suggestions for > > > > > where to host a mailing list? Might the github issue tracker suffice? > > > > > We could (as worked quite well for lxd) have a specs/ directory in a > > > > > libresource source tree, and use issues and pull reuqests to guide the > > > > > api specifications under that directory. Just a thought. > > > > > > > > This all sgtm. A mailing list for design discussions + github issue > > > > tracker seems to be working well for many open source projects I've > > > > been tracking lately. Most of them are using Google Groups for their > > > > mailing lists. > > > > > > Well for starters I created https://github.com/hallyn/libresource . We > > > should create a real project for it but it's a start. (I'll create an > > > organization if this starts to move) > > > > > > Actually I suppose the first step would be deciding on a license. Normally > > > I default to gplv2, but for this that may not be appropriate. Apache > > > license? Can be settled in an issue or pull request for a License file, > > > I think. > > > > My personal preference is always LGPLv2+ for libraries, since it gives > > ability to use from non-open source apps, but is still copyleft. I know > > corporates tend to prefer non-copyleft licenses like Apache these days, > > but that is generally for ulterior motives like being able to do dual > > open/closed products. > > I think one of the most important consumers would be procps, and this > wouldn't be an issue for them. Now one of the reasons we want this is > so that software like databases and big java apps can check their > real available resources to scale - would this be an issue for them, > or do we think they would just link to or execute commands from > procps? I guess where it could become an issue is if $BIGVENDOR wants to bundle a copy of the library statically with their app. Some companies are (irrationally) paranoid about shipping anything copyleft themselves, so Apache could suit that. Its a tradeoff, as it obviously lets them embrace & extend rather than forcing them to share improvements they make.