[Savannah-register-public] [task #10686] Submission of Opus Libre

[Mario Castelán Castro]

Follow-up Comment #5, task #10686 (project administration):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

2010-10-13 in GNU Savannah task #10686: "Submission of Opus Libre".

Hello Valentin.

We don't aim to be a bureaucracy, we aim to educate and promote our
philosphy and good licensing practices, that's why we ask the
maintainer to make changes according to what the GNU project and the
Free Software Foundation suggest, regarding software licensing.

> whilst the GPL header I use is indeed slightly different than the
> suggested one, it does include all the information needed: copyright
> statement and license information.

In overall there are 2 important differences between the license
header you're currently using and the customary one: yours lack
warranty disclamer and license URL.  Also, yours feature a shortened
and maybe less clear wording.

> If using exactly the suggested header is in fact mandatory [...]

No, it isn't mandatory.  Who said so?.

My insistence with the suggested GPL header is because it is known to
be of trust.  The GNU GPL header as suggested by the GNU project was
reviewed by several people, we consider it to be complete as includes
all relevant information.  We could also say it passed the test of
time, the GNU GPL 1 from 1989 contains this notice in its "howto"
section and has been successfuly used in thousands of free software
projects since.

We're very prone to miss something if we made yet another header for
the GNU GPL.  For instance, the one Opus Libre is using currently
lacks important aspects, as explained above.  These custom headers may
or may not be considered valid in a court or may miss something else
legaly important (The warranty disclamer, for example).  But We don't
want to include barely what's need to state the file is under the GNU
GPL.  We should also attend to other issues:

First, unless you actually offer a unconditional warranty, you don't
want to get sued if an user find a bug in the software.  Warranty
disclamers can avoid this problem.

We also want the user to know his rights even if he got the file in
question but didn't got a copy of the GPL (Although as the notice
itself states, a copy of the GNU GPL should be distributed along with
the work, but the vendor may forget, the copy may get lost, etc...).
If the license notice tells where a online copy can be found the user
can check the URL if he have internet access.

These are some of the possible issues with a custom license.  I hope
now you understand why the suggested header is used, and why we ask
you to use it.  If you still find this request to be a problem please
explain it comprehensively so we can get faster to a satisfactory
solution.

> As explicitely specified in each and every one of them, files that
> lack a GPL header are deprecated and to be removed

Fine, but please don't blame on me :).  The comment was "This file is
deprecated and must be adapted to the framework".  This don't tells me
they were to be removed.  The fact these files were included in the
tarball made me thought you meant them to be uploaded to GNU Savannah
and hence would be subject of evaluation, then I found the Copyright &
licensing information was missing.  In this case, these files were
removed, so it is no longer a problem.

What about ".directory" files and those under "share"?.  If you want
to upload these to GNU Savannah please state their Copyright &
licensing information.

> COPYING and README document *are* present in the tarball.

It's fine.  I didn't claim the contrary.

> I am not amused when the use of predefined answers tends to take an
> unnecessarily offensive turn.

There are no predefined answers.  There are prewritten chunks of text
which deals with the most common issues but these are manually
included and tuned for each message as we consider appropriate.

In my specific case, the collection/database I use for these
prewritten texts is a modified version of savannah.el as publicly
downloadable.  The download instructions are available in
http://savannah.gnu.org/maintenance/SavannahElVim.

Project reviewing is an exhausting task, I would want it to exist a
universally valid predefined answer ;).  But it's not that easy.

If you would like to help us in this task please see
http://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker.

I don't understand why you did chose to interpret that as "offensive"
but by no means I did meant it to be an offense.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At your option we can continue the registration process in the (D)VCS
repository of your choise inside GNU Savannah.  This means I would
approve the project just now provided you agree to fix any remaining
or further issue (If any) as soon as possible.

I will close this task when I can check all is ok but please bear in
mind you must follow the hosting requirements as long as you do use
GNU Savannah, regardless of the way you chose to continue the
registration process.

Regards and thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAky2VxEACgkQZ4DA0TLic4gnVACfUzbptL7rZyA6P0OEbgN/WsKj
kXsAn1DajY2BrknQDe41G1TF6H+kCF/2
=tdtL
-----END PGP SIGNATURE-----


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?10686>

_______________________________________________
  Mensaje enviado vía/por Savannah
  http://savannah.gnu.org/