[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] Documentating hosting requirements
From: |
Nicodemo Alvaro |
Subject: |
Re: [Savannah-hackers-public] Documentating hosting requirements |
Date: |
Wed, 9 Dec 2009 01:11:47 +0100 |
On Thu, 03 Dec 2009 19:46:55 +0100
Sebastian Gerhardt <address@hidden> wrote:
> I always thought of Free Software as a label, kind of a trademark.
> Therefore I personally will continue to capitalize it but I won't argue
> with native speakers about how the official Savannah spelling should
> be ;)
RMS talks about that in a similar way in that "open source" is
too general to be a trademark. The same can be applied to the free
software term. If you look at any page on gnu.org or fsf.org, you
rarely see it is capitalized.
http://www.gnu.org/philosophy/free-software-for-freedom.html
> > ===== NEWLY REVISED VERSION BELOW =======
> >
> > Please read these usage terms carefully. If you do not follow
> > these terms, we will not accept your project. If we do not have enough
> > information to determine whether your project follows these terms, we
> > will have to ask you to register the project again with more details.
>
> Do we actually do this? Usually we ask on the tracker to fix issues we
> point out (as written further below), and only demand registering again
> if the submission is really FUBAR.
I am having a hard time arguing against what you are saying. Sometimes I
really ought to ask for more description on what the project is for. I
have a tendency to forget. So would the below be more acceptable?
"Please, read these usage terms carefully. If you do not follow these
terms, we will not accept your project. If you unsure how to follow
these terms, the Savannah Administrators may help you along. It would
help if you write a 100 word description with the programming languages
required, URL links to your dependencies, and the license that they
use."
Should the above also include the requirements threshold, since it
seems to flow somewhat.
> > B. No dependencies on non-free software.
> > 5. It must deliver the full functionality and convienence on a fully
> > free platform and free operating system environment. REVISED
> "convenience"
Fixed.
> > C. No non-free formats REVISED
> > 1. Your project must not create formats that can only be used
> > with non-free software. REVISED
>
> This is a very strict requirement. I think this goes a bit too far.
> If a free software can write such a file, doesn't that usually mean
> this file can be used with free software as well?
In software, there is a whole world of strange possibilities that can
be used against free software. Even so, I think it would be okay to
leave it out.
> > D. Speaking about free software
> > 1. Clearly describe your project as free software. REVISED
>
> This will be a momentous requirement as well. The way I understand it,
> we then will require the explicit label "free software" on any project
> description page, rather than just, say, in the license header.
One thing that strikes me, is that some people will leave out calling
their project open source in registration and then after approval call
it open source in their project description. Do you think it would it be
any better to say "You may describe your project as free software."?
Do you think the administrator should be advised to follow up and ask
them to revise their description?
> > E. Free software, documentation, and supporting file licenses REVISED
> > 1. All files must have a free license. Choose a standard, free license.
> > NEW (4)
>
> This paragraph is fine. But as this is one of the points that get
> missed, it should be moved up. To be A or B if you ask me ;)
I agree. How about this order?
Free software, documentation, and supporting file licenses
Applying the licenses
Speaking about free software
No dependencies on non-free software
No non-free formats
Use of project account
Advertisements
NonGNU and GNU Hosting
Requirements threshold
Why the legal checks
Helpful resources
> > I. Why the legal checks before approval? NEW (2)
>
> *nitpicking*
> This is no requirement but additional information, therefore it should
> not be enumerated the same way as the above.
Do you think this info would be better at the beginning as well? Does
this section really mean a tarball submitted through project
registration is not for public use? It seems to generalize tarballs are
not accessible to the public. I did not write it, so I am not quite
sure what to make out of it.
--
Nicodemo