Hi Martin; Am 02.06.2012 23:58, schrieb Martin Hejl: > Hi Erich, > >> I am not a lawyer, so I have the right to be convinced that >> as long as the source code of the project can be provided AND we >> document where it came from, that should be sufficient. > You're not a lawyer, and neither am I - but the rules set out at > http://sourceforge.net/apps/trac/sitelegal/wiki/Controversial%20project%20hosting#SourceAvailability > do not seem to give us much in the way of being space efficient by > simply linking to other sources. > > The part where it says that "SourceForge.net requires that source code > releases be made via our File Release System for any binary releases > made via our File Release System or any other project resource." seems > to make it clear (at least to me) that we're not even doing enough in > the way of redundancy (since I read that as us having to provide all > sources in the FRS as well, just having them in git is not good enough.). > I don't disagree with you (both that it's redundant, and that it's > stupid to have to provide sources ourselves, even though they're > available up-stream) - but the way I read the SF page, if we don't agree > with that, we'd better host the site somewhere else. And honestly, it > seems easier to waste a bit of space on the SF servers (since they > demand it), than to find a different host for the site. > > There's been plenty of discussion about that topic back in 2010 (just > look up the "Talks about versioning system" thread from September 2010) > - I still believe we're not fully complying to the terms that SF > demands, but since it seems I was the only one feeling that way, I > dropped the argument after a while. > > But I still read the SF page to state that we don't really have a choice > - and that we're not even burning _enough_ storage yet, since we only > keep things in git, but not also in the FRS.
I believe this has been solved with providing the source tarball in FRS for each release. > I don't think it should be that way, but that's the way I understand > SourceForge wants it to be. > >> If not then I >> reserve the right to believe that this license is stupid and should not >> be taken as an excuse to produce data waste. > I don't think it's so much about a license, but more about the Terms and > Conditions that SF imposes. > >> I would like to know what >> information theories would be violated by such massive data duplication. > None as far as I'm concerned - but don't try to apply logic to any > document that was written up by the legal department of a company :-) > >> Be it as it is and I am not in a position to change it, I still hate >> redundancy. > Same here. At the same time, if the upstream servers are not reliable, I > would see that as a valid reason for adding redundancy, just for the > sake of people being able to run a build even if those servers don't > happen do be up at a given point in time. There has been an exception by SF staff for packages considered to have a stable download source like gcc or the kernel - but we've learned last year that even those are not always online and we moved the kernel into our git repository as well, just to keep things going. kp ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
