Re: [Savannah-hackers-public] legal entities
On Sat, Apr 03, 2010 at 12:16:44AM +, Karl Berry wrote: Hmm. What the lawyer actually said is: Copyright law allows the notice to include a generally known alternative designation of the owner, and we believe the project name should qualify for that. So the question would be whether the alias or nickname is a generally known alternative designation. Some are, some aren't. But I don't see how we could make that (legal) judgement -- if the project owner(s) want to take the risk and use a project name, an alias, or anything except the actual legal entities involved, it seems to me that is up to them. We don't need to be (and cannot be) the law here. What we can do, if we want to, is explain the above: using aliases of whatever sort can make it harder to get damages in court, so we do not recommend the practice (for the project's sake). Sylvain, do you agree? Yes. It seems to me that keeping track of who wrote what is crucial, if only to be able to investigate copyright infrightment claims, but we're not here to track such infrightments, so let the project deal with the consequences. -- Sylvain
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
On Thu, Apr 8, 2010 at 9:02 PM, Sylvain Beucler b...@gnu.org wrote: Is this OK, or do I need to find another solution? ASL2 is compatible with GPLv3 (and not with GPLv2). Does that answer your question? Not really. Let me put it another way: if I were to host a project licensed under the Apache 2.0 license on Savannah the FSF would probably not like it. But is it OK to serve some Apache 2.0 JavaScript code from the nongnu.org domains, for demonstration purposes? Alex.
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
On Thu, Apr 08, 2010 at 10:20:41PM +0200, Alex Fernandez wrote: On Thu, Apr 8, 2010 at 9:02 PM, Sylvain Beucler b...@gnu.org wrote: Is this OK, or do I need to find another solution? ASL2 is compatible with GPLv3 (and not with GPLv2). Does that answer your question? Not really. Let me put it another way: if I were to host a project licensed under the Apache 2.0 license on Savannah the FSF would probably not like it. But is it OK to serve some Apache 2.0 JavaScript code from the nongnu.org domains, for demonstration purposes? Well since the ASLv2 is compatible with the GPLv3, there's no problem with hosting software licensed under the ASL2 at Savannah. The licensing requirement for code is that its license be compatible with the GPL (latest version). Consequently you can also use ASLv2's scripts in nongnu.org webpages. Is it OK or did I miss something entirely? -- Sylvain
Re: [Savannah-hackers-public] Setting up bzr+ssh on Savannah.
Hi,
(sorry for the delay, I had troubles coping with everything over the
past few weeks).
I have no problem with turning sftp off.
I'm glad you're working to get an official way to disable
user-controlled plugins in bzr, server-side.
What you also need to do is:
- coordinate with other bzr users
- move the bzr service to the 'vcs-noshell' VM (instead of the current
'sftp' VM) - so you don't disable SFTP access to the download area.
I gave you root access to 'colonialone.fsf.org' (the rsa key only).
Check:
http://savannah.gnu.org/maintenance/SavannahArchitecture
to access other areas of Savannah.
The rule is: what you break, you fix.
If you agree with the rule, you can proceed with the changes :)
--
Sylvain
On Mon, Mar 22, 2010 at 05:57:09PM -0400, Karl Fogel wrote:
Ping. Any reaction from Savannah admins to the proposal below?
Karl Fogel kfo...@red-bean.com writes:
Okay, so how about we:
1) Turn off sftp access.
2) Apply the diff at the end of this mail :-).
3) Update the developer instructions accordingly.
Configuration files are not under a VCS, but a good deal of
information can be found in the bzr repository for project
'administration'.
Thanks. (After we agree on the course of action, I'll have some changes
to submit to administration/bzr.txt too.)
Regarding commit emails: let's just continue using bzr-hookless-email
for now. It works, and right now the problem we're trying to solve is
bzr+ssh:// access. We can tackle other Bazaar issues afterwards.
Below is the diff; please review. If you like it, my next step will be
to come up with the developer instructions so those currently using
sftp:// can switch over. (Naturally, we'll warn them first and set a
flag date.)
[[[
Restore Bazaar bzr+ssh:// access, but this time without plugins.
* /usr/local/bin/sv_membersh: Suppress logging in the modern way.
Add the '--no-plugins' option to the bzr serve command.
* /etc/membersh-conf.pl: Set use_bzr to 1.
]]]
--- /usr/local/bin/sv_membersh 2010-03-17 15:38:57.0 -0400
+++ /usr/local/bin/sv_membersh 2010-03-17 16:00:02.0 -0400
@@ -151,12 +151,11 @@
} elsif ($use_bzr and $ARGV[1] =~ m:$regexp_bzr:) {
-# bzr wants to write a ~/.bzr.log
-# Tip: mkdir -m 755 /var/lib/bzr
-# ln -s /dev/null /var/lib/bzr/.bzr.log
-$ENV{'HOME'} = '/var/lib/bzr';
+# bzr wants to write a ~/.bzr.log. Suppress that (see
+# https://bugs.edge.launchpad.net/bzr/+bug/106117 for more).
+$ENV{'BZR_LOG'} = '/dev/null';
# authorize 'bzr serve' in SSH tunnel mode
-exec($bin_bzr, 'serve', '--inet', '--directory='.$dir_bzr,
'--allow-writes')
+exec($bin_bzr, '--no-plugins', 'serve', '--inet',
'--directory='.$dir_bzr, '--allow-writes')
or die(Failed to exec '$bin_bzr serve --inet --directory=$dir_bzr
--allow-writes': $!);
} elsif ($use_hg and $ARGV[1] =~ m:$regexp_hg:) {
--- /etc/membersh-conf.pl2010-03-17 14:31:11.0 -0400
+++ /etc/membersh-conf.pl2010-03-17 15:31:55.0 -0400
@@ -17,4 +17,4 @@
# SFTP-accessible area (== local access) when said commit hook support
# is eventually ready in bzr
-#$use_bzr = '1';
+$use_bzr = '1';
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 April 8th 2010 in savannah-hackers-public@gnu.org thread Hosting Apache 2.0 JavaScript code. There was a discussion some months ago about whether the or any later clause was mandatory or not. I don't remember what happen that time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAku+R/IACgkQZ4DA0TLic4jUgACfcuihTYUo16RzF5x49/UZqJLl 2N4An2mGhrvVYggxwH9+J/7KEPKsu5ls =wDTt -END PGP SIGNATURE-
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
Hi again, On Thu, Apr 8, 2010 at 10:36 PM, Sylvain Beucler b...@gnu.org wrote: Well since the ASLv2 is compatible with the GPLv3, there's no problem with hosting software licensed under the ASL2 at Savannah. The licensing requirement for code is that its license be compatible with the GPL (latest version). Oh well, I thought that it had to be licensed under an FSF-sponsored license (the GPL or variants). Consequently you can also use ASLv2's scripts in nongnu.org webpages. Great! Is it OK or did I miss something entirely? Right on target, thanks! Alex.
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
There was a discussion some months ago about whether the or any later clause was mandatory or not. I don't remember what happen that It is definitely mandatory for GNU licenses (GPL, LGPL, FDL). Should it be mandatory for the Apache license too? I'm not sure that it needs to be mandatory, although it should certainly be recommended.
Re: [Savannah-hackers-public] Hosting Apache 2.0 JavaScript code
On Thu, Apr 08, 2010 at 05:16:53PM -0400, Mario Castelán Castro wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 April 8th 2010 in savannah-hackers-public@gnu.org thread Hosting Apache 2.0 JavaScript code. There was a discussion some months ago about whether the or any later clause was mandatory or not. I don't remember what happen that time. (Note: stripping the context makes it harder to answer.) GPL or any later version clause is mandatory. We don't allow GPLv2-only code because it makes it hard or impossible to upgrade when problems are found in the GPL. -- Sylvain
[Savannah-hackers-public] [gnu.org #561831] www.nongnu.org/project home pages 404
Hi Sylvain,
[beuc - Thu Apr 01 16:40:05 2010]:
So, that makes me think that the initial checkout on Mar 22nd did
not
work because there was nothing to check out yet when curl was called
from /usr/local/share/perl/5.10.0/Savane/Cvs.pm. Is that possible?
That sounds unlikely, basically the code is:
WebCvsMakeAreaSavannahNonGNU:
CvsMakeAreaSavannah($name,$dir_cvs,$is_public,'web');
# prepare curl params
system ('/usr/bin/curl', 'http://www.gnu.org/new-savannah-
project/new.py',
'-s', '-F', type=$ws_type, '-F', project=$name);
I don't really know what happened with web sync at the time :/
Hmm. Do we have evidence of this happening a lot, or just this once?
Perhaps some debug code is in order to get more information the next
time it goes wrong...
Thanks,
Ward.
--
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior System Administrator
