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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 24, 2015 at 03:53:24PM +0000, Serge Hallyn wrote:
> Quoting Daniel P. Berrange (berrange@xxxxxxxxxx):
> > On Thu, Sep 24, 2015 at 02:41:49PM +0000, Serge Hallyn wrote:
> > > Quoting Fabio Kung (fabio.kung@xxxxxxxxx):
> > > > On Wed, Sep 16, 2015 at 12:29 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> 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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]