On Jan 15, 2008 11:30 AM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > The other issue is how long does the > source code need to be available from the primary source for GNU GPL > or other licenses requirements? Both of these are probably moot > questions... but I will play mr ignoramus. As of right now.. we don't have to keep source any longer than we keep binaries because we distribute under 3a of the GPL. When you get binaries from servers we control, you pretty much have to decide whether or not you want the source then. If you redistribute what you got from us, the onus is on you to provide source for anyone who takes binaries from you. That's how it stands right now. Soon, like F9 soon, I'd really like to be able to see us extend access to source for 'long enough' so that downstream distributors can rely on us and point people back to us for source for a specific period of time..after which they are again responsible for providing source to people if they choose to continue distributing. I think after fudcon a lot of the stakeholders agree that we can do something along these lines, cover our asses legally speaking, and more important not be assholes about source access. They aren't the same thing, necessarily. I'm hoping we can solve the tagging issues with cvs so we can generate srpm from an archive of our cvs and lookaside caches and know with reasonable assurance that the result is the desired srpm that koji used. To do that we might break some contributors' work flow associated with using forced retagging.. and I'd like to avoid doing that. But being responsible about access to sources is a very important thing. From a legal perspective i think we have our asses covered by just giving someone a full archive of our cvs and look aside cache (using archive.org for example) and letting them dig through it. But I don't want to just do the minimum here and be an ass. I want to try to make sure that we have a source distribution that is easy enough to use, but isn't continuing to burden our infrastructure by having to cache srpms when we don't have to. Give me a cvs tag namespace that maintainers don't need to forcibly retag that maps to releasable binary builds and we have a simple way to regenerate srpm's on the fly just from the cvs archive. And the cvs archive is not a bottleneck in terms of space. We simply cannot rely on koji's cache for any time scale of merit. Koji takes up way more space that what is actually in cvs and the lookaside, and its naive to think we can get away with trying to historically cache at the koji level. CVS where we deal with source material, and that is where we need to re-generate historic srpms when asked for. if we move to some other source control system, then we make sure we have a similar ability.. but how we deal with source distribution requirements as it impacts downstream distributors (like our ambassadors who hand out binaries at tradeshows) needs to be enhanced sooner rather than later. It's not going to wait for cvs to be replaced. -jef _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
