Hi kp, > Thx for the pointer. > > AFAIK that reads that we have to provide a tarball of our cvs with each and > every release (currently 108M). I didn't really want to respond to Mike's mail, since I was hoping that I was misreading the implications. But unfortunately, I read the page the same way you do.
To me it sounds (if we want to stay in line with the terms of use with SF), that we either do that (but then, what actually _is_ a "binary releases made via our File Release System or any other project resource" - to me, it sounds like there'd have to be a new source tarball for every new package checked into CVS and made available via the packages page - if there is one for Bering uClibc 4 - if not, I guess one could argue that if CVS isn't good enough for providing source code, it doesn't qualify as a binary release either. But I'm not a lawyer....), or look for some other means of hosting the source and binaries. > But do you think that we have to include every source we use as well (gcc, > kernel,...)? Tough call - to me, "any binary releases made..." sounds like everything that's part of the binary release. So, kernel, yes, for sure (IMHO), some support libs, that are just needed for the build process, probably not. But drawing the line might be difficult. Just my two cents Martin -- You think that's tough? Try herding cats! ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
