taskSavannah Administration - Tasks: task #16067, Submission of Dezyne

 
 

task #16067: Submission of Dezyne

Submitter:  Jan Nieuwenhuizen <janneke>
Submitted:  Wed 03 Nov 2021 10:30:33 AM UTC
Votes:  181  
 
Should Start On:  Tue 02 Nov 2021 11:00:00 PM UTC Should be Finished on:  Fri 12 Nov 2021 11:00:00 PM UTC
Category:  Project Approval Priority:  * 5 - Normal
Status:  Done Privacy:  Public
Percent Complete:  0% Assigned to:  ineiev
Open/Closed:  Closed Effort:  0.00
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Wed 16 Mar 2022 04:52:05 PM UTC, comment #37: 

March 16 and the process is still stuck at this point, with no (public) answer/reaction since February 20, simply unbelievable!!

Francesc Rocher <rocher>
Sun 20 Feb 2022 03:28:12 PM UTC, comment #36: 

Can someone---anyone---please approve Dezyne right now and can we
discuss any details, the utter brokenness of this process, and any
changes to the guidelines and documentation later?

>> So from a Dezyne point of view, the discussion was
>> resolved.
>
> From evaluator's point of view, it hasn't been resolved yet; it makes little
> sense to post here until the private discussion is over.


Sorry for posting here again if that is inappropiate.

More than 10 days ago I have seen an email rehashing minor details that
were already discussed to death and deemed OK.  So I guess you are
asking us to trust that fruitful discussions are taking place elsewhere
(wondering about what, though)?  Because I haven't seen anything going
on for quite some time now (again!).  Also, I sure hope that GNU/FSF
will hurry up with making their processes---such as these---more
transparent.

As you can probably understand, we are getting requests about the
progress, the ETA and the timeline of hosting a package on Savannah and
I am not sure what to say (other than: it should not have taken more
than a few days to a week at most).  Some have even started to question
our sincerity of opening up the Dezyne sources and development process,
and the wisdom of choosing Savannah.

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Thu 10 Feb 2022 08:01:56 AM UTC, comment #35: 

comment #34:

> So from a Dezyne point of view, the discussion was
> resolved.


From evaluator's point of view, it hasn't been resolved yet; it makes little sense to post here until the private discussion is over.

> Yesterday, one more source file without a header was found.  Of course,
> I corrected that promptly, added headers to three more similar c++
> header files and I have uploaded a new tarball:


Thank you.

Ineiev <ineiev>
Site Administrator
Wed 09 Feb 2022 12:18:38 PM UTC, comment #34: 

>> The internal discussion was resolved in January
>
> No, not completely.


The discussion about the last non-issues that were raised:

  • All ASCII files, even if they are generated or trivial must have a

   copyright header,

  • Examples included in the documentation need individual copyright

   headers,

  • A file longer than 10 lines is never trivial,
  • A README file cannot serve to describe the copyright and license

   of ASCII files,

were resolved as being a much too strict--and wrong--interpretation of
the guidelines.  So from a Dezyne point of view, the discussion was
resolved.

> Something has happened.  You know that there was a follow-up.


The follow-up was meant to explain the above two points.  Then, there
was no remark on the explanation for over a week.  There is also another
thread about improving the maintainer guidelines and fixing this
approval process.  I do not see why that should hold up Dezyne, though.

Yesterday, one more source file without a header was found.  Of course,
I corrected that promptly, added headers to three more similar c++
header files and I have uploaded a new tarball:

    https://savannah.nongnu.org/task/download.php?file_id=52825

Someone please approve Dezyne right now.  Thanks.

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 07 Feb 2022 10:01:54 AM UTC, comment #33: 

comment #32:

> The internal discussion was resolved in January


No, not completely.

> where Richard explained
> why those files are trivial--like I did back in November.  Nothing has
> happened since then.


Something has happened.  You know that there was a follow-up.

Ineiev <ineiev>
Site Administrator
Mon 07 Feb 2022 08:57:24 AM UTC, comment #32: 

> The submission is still discussed privately.


The internal discussion was resolved in January where Richard explained
why those files are trivial--like I did back in November.  Nothing has
happened since then.  Why else would I have (desperately) added bandali
to the CC here?

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 07 Feb 2022 07:21:39 AM UTC, comment #31: 

comment #30:

>
> Would you please forward a copy of the recommendation/decision
> resulting from the escalation (preferably along with any other
> relevant context or discussion) to me so I could review/verify
> and hopefully help move this forward?


The submission is still discussed privately.

Ineiev <ineiev>
Site Administrator
Sun 06 Feb 2022 09:24:30 PM UTC, comment #30: 

Hi Janneke, all,

Sorry about the long delay here.

comment #27:

> As escalating this issue has shown (it would be great if the escalation
> process was documented and transparent, let's work on that later), the
> Dezyne sources are compliant with the requirements for copyright and
> licensing.


Would you please forward a copy of the recommendation/decision
resulting from the escalation (preferably along with any other
relevant context or discussion) to me so I could review/verify
and hopefully help move this forward?

Thanks.

Amin Bandali <bandali>
Site Administrator
Fri 04 Feb 2022 02:52:10 PM UTC, comment #29: 

comment #28:

> We expected an instant approval of Dezyne, or at least more discussion.
>
> But apparently we have overlooked the third option: Nothing happens.
>
> Today it is exactly three months ago that I submitted Dezyne to
> savannah.  I would really like to get a community going and collect
> their feedback and input, a savannah git repository and a mailing-list
> is essential.  Help!
>
> Greetings,
> Janneke
>


You should be patient about this, because it might take a while for the assigned user to respond to the comments.

-*- <_289157>
Wed 02 Feb 2022 09:27:34 AM UTC, comment #28: 

Hello,

As I wrote, we asserted that:

> As escalating this issue has shown [..], the Dezyne sources are
> compliant with the requirements for copyright and licensing.


That was a week ago.  I asked:

> Please approve the Dezyne package to be hosted on savannah:
>
>     https://savannah.nongnu.org/task/?func=detailitem&item_id=16067#votes


We expected an instant approval of Dezyne, or at least more discussion.

But apparently we have overlooked the third option: Nothing happens.

Today it is exactly three months ago that I submitted Dezyne to
savannah.  I would really like to get a community going and collect
their feedback and input, a savannah git repository and a mailing-list
is essential.  Help!

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Wed 26 Jan 2022 06:32:07 AM UTC, comment #27: 

As escalating this issue has shown (it would be great if the escalation
process was documented and transparent, let's work on that later), the
Dezyne sources are compliant with the requirements for copyright and
licensing.

Please approve the Dezyne package to be hosted on savannah:

    https://savannah.nongnu.org/task/?func=detailitem&item_id=16067#votes

Some background and rationale:

The approval process should establish if the submitter of a package is
willing to make any effort.  If they are, the most egregious issues
should be pointed out and corrected.  Let minor stuff be fine, maybe
point it out.  Lack of license, lack of clear liccense, license
problems are most important.  In general, regular source files should
have copyright headers.  Such problems were pointed out (thank you!!)
and corrected in the first few messages.  There it should have stopped.

While all source code in the Dezyne package comes with copyright and
license headers, the source tarball does include some ASCII files
without individual copyright and license headers.  That is OK; for data
files or included snippets we need to strike a balance between the
effort involved of adding headers and the triviality of the data.

Adding a header to such files would be very inconvenient and is
unnecessary.  A README file is used to explain the copyright and license
status of such files.  Also, one or two disputable cases are not enough
to disqualify a package, especially if the author's intentions are
reasonably clear.  Of course, if a header can be added without any
complications, that should always be preferred and we should ask the
author to do so.  That happened in the first few messages in this
thread.

The detais below should not be necessary, this has been almost
discussed "to death" in this task.  Anyway:

   * Test baseline data:
      test/all/<test>/baseline/*

These be generated by running "test/bin/update.sh" (to be distributed,
only in git right now).  Because these baseline files are trivial and
moreover can be generated automatically.

   * Input trace data
      test/all/<test>/trace

The amount of actual information in that is so little that they are
trivial for copyright.  Also, these can be generated by running "dzn
verify" or "dzn traces".

   The file "test/all/README" explains the license for this test data
   to be CC0-1.0.

   * Dezyne and gerenated .texi snippets included in the manual:
     doc/examples/*.dzn
     doc/parse/*.dzn
     doc/parse/*.texi
     doc/semantics/*.dzn

These file are a necessary part of the manual and thus follow the
copyright of the manual.  On top of that, these

    doc/examples/README
    doc/parse/README
    doc/semantics/README

README files explain their copyright and license.

That's it, thank you for reading this far.  After approving Dezyne,
let's make sure that the maintainer's guidelines and approval process
are documented better to reflect this, and make for a more welcoming
and pleasant experience for newcomers, and less frustrating work for
the evaluators!

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 13 Dec 2021 10:28:39 AM UTC, comment #26: 

comment #24:

> Using @include assumes texinfo format.  The texinfo format does not
> recognize "//" as a comment marker, and needs escaping for braces "{"
> and "}".  For example:
>
>     // header
>     // comment
>     interface {
>     ..
>     }
>
> becomes
>
>     @c header
>     @c comment
>     interface @{
>     ..
>     @}


...or it becomes

     @c header
     @verbatim
     // comment
     interface {
     ..
     }
     @end verbatim

> which makes the example unusable for the Dezyne tooling.  While that
> is "only" very inconvenient for us maintainers, it is terrible for our
> users who want to try such an example out.


A one-liner like sed '/^@\(verbatim\|end verbatim\)/d;s,^@c,//,' will convert it to a usable form which you can put to $docdir/examples, so this detail is completely up to you.

Even an hopeless fool like your humble servant can easily make a build system that will choke on the word 'Copyright' in any file in the archive; if such things counted, the guidelines would mean very little.  The point is, I shouldn't do such things.

> > https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:
> >
> >> Any file more than ten lines long is nontrivial for this purpose.
>
> As Alfred also mentioned in #17, your reading of the requirements is
> far to strict and not what is intended.


It matters little what Alfred mentioned, it doesn't matter very much what Ineiev said, what matters is what the guidelines tell; the guidelines are pretty clear and unambiguous.

> If you know the Dezyne language, there is really no other way to
> express what is explained in the text than in these three examples.


Yes, there are.

> Also, whitespace and other trivial lines with only parentheses or
> braces must not be counted.  The first example has, indeed eleven
> lines and the second one is seven lines.  Both are trivial.


It doesn't read, 'ten non-trivial lines'---it reads, 'Any file more than ten lines long'.

Empty lines serve their purpose---they provide visual separation, so they do contribute, even if less than other lines.

Now, I wouldn't raise this issue if it were about files that are dozen lines long or so, but join.dzn is clearly longer, even if we drop lines less than 5 non-blank characters long, so at any rate, some of these files definitely need notices; therefore I suggest that you err on the side of copyrightability when you add them, it won't be much extra work---if you do that at all.

Ineiev <ineiev>
Site Administrator
Thu 09 Dec 2021 10:15:25 AM UTC, comment #25: 

Hi!

I have uploaded a new tarball

    https://savannah.nongnu.org/task/download.php?file_id=52460

which removes the ASCII doc snippets.

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Tue 07 Dec 2021 01:00:15 PM UTC, comment #24: 

Hello!

>> 100 lines (more than twice as long) that mostly draw attention to
>> copyright headers.
>
> If you use @include rather than @verbatiminclude, you'll be able to hide them
> in texinfo comments.  Isn't it a trivial technique?


Using @include assumes texinfo format.  The texinfo format does not
recognize "//" as a comment marker, and needs escaping for braces "{"
and "}".  For example:

    // header
    // comment
    interface {
    ..
    }

becomes

    @c header
    @c comment
    interface @{
    ..
    @}

which makes the example unusable for the Dezyne tooling.  While that
is "only" very inconvenient for us maintainers, it is terrible for our
users who want to try such an example out.  I hope you can agree that
we are making the wise choice here.

>> Furthermore, the examples above are trivial creations, and therefore
>> not copyrightable.
>
> No, they are not trivial.  Let us agree on this, at last.
>
> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:
>
>> Any file more than ten lines long is nontrivial for this purpose.


As Alfred also mentioned in #17, your reading of the requirements is
far to strict and not what is intended.

If you know the Dezyne language, there is really no other way to
express what is explained in the text than in these three examples.
Note that the third example is not even given...because it is equally
trivial.

Also, whitespace and other trivial lines with only parentheses or
braces must not be counted.  The first example has, indeed eleven
lines and the second one is seven lines.  Both are trivial.

AND, quoting #21

    To remove any doubt, the README makes the dual licensing clear, the
    copyright is of course listed in the dezyne.texi of the manual itself
    (and can bee derived from git or the ChangeLog).

I again, respectfully ask you to approve.

Jan Nieuwenhuizen <janneke>
Tue 07 Dec 2021 12:08:49 PM UTC, comment #23: 

comment #21:

>
> 100 lines (more than twice as long) that mostly draw attention to
> copyright headers.


If you use @include rather than @verbatiminclude, you'll be able to hide them in texinfo comments.  Isn't it a trivial technique?

> Furthermore, the examples above are trivial creations, and therefore
> not copyrightable.


No, they are not trivial.  Let us agree on this, at last.

https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:

> Any file more than ten lines long is nontrivial for this purpose.

Ineiev <ineiev>
Site Administrator
Tue 07 Dec 2021 11:04:36 AM UTC, comment #22: 

[typo]

  • If you agree, can you please approve?

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Tue 07 Dec 2021 11:03:01 AM UTC, comment #21: 

Ineiev writes:

>> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>>
>>     Some formats do not have room for textual annotations; for these
>>     files, state the copyright and copying permissions in a README file
>>     in the same directory.
>
> Quite right.  These are text files, they do have room for textual
> annotations.


No, there is no room for that.  Let me show you what would happen to
our documentation when adding copyright headers to these files.  The
semantics chapter would change from this:

    5.3 Direct multiple out events
    ==============================

    A requires port inevitably triggering multiple out-events (‘r.a’, ‘r.b’)
    is implemented as one function call for each out-event posting in the
    component queue, followed by a single flush call to trigger component
    processing of the events.  The below 2 versions of the component are
    indistinguishable looking from the outside.

         interface I
         {
           out void a ();
           out void b ();
           behavior
           {
             on inevitable: {a; b;}
           }
         }

         component direct_multiple_out1
         {
           provides I p;
           requires I r;
           behavior
           {
             on r.a (): p.a ();
             on r.b (): p.b ();
           }
         }

       [small, 1in image]

         import direct_multiple_out.dzn;

         component direct_multiple_out2
         {
           provides I p;
           requires I r;
           behavior
           {
             on r.a (): {}
             on r.b (): {p.a (); p.b ();}
           }
         }

       [small, 1in image]

       The third variant is left as an exercise to the reader.

48 lines that fit on one screen, change and turn out to look like this:

    5.3 Direct multiple out events
    ==============================

    A requires port inevitably triggering multiple out-events (‘r.a’, ‘r.b’)
    is implemented as one function call for each out-event posting in the
    component queue, followed by a single flush call to trigger component
    processing of the events.  The below 2 versions of the component are
    indistinguishable looking from the outside.

         // Dezyne --- Dezyne command line tools
         //
         // Copyright © 2018 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
         //
         // This file is part of Dezyne.
         //
         // Dezyne is free software: you can redistribute it and/or modify it
         // under the terms of either:
         //
         //   the GNU Affero General Public License as published by the Free
         //   Software Foundation, either version 3 of the License, or (at your
         //   option) any later version.
         //
         // or
         //
         //  the GNU Free Documentation License version 1.3 or later; with no
         //   Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts,
         //
         // Dezyne is distributed in the hope that it will be useful, but
         // WITHOUT ANY WARRANTY; without even the implied warranty of
         // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
         // Affero General Public License for more details.
         //
         // You should have received a copy of the GNU Affero General Public
         // License along with Dezyne.  If not, see <http://www.gnu.org/licenses/>.

         interface I
         {
           out void a ();
           out void b ();
           behavior
           {
             on inevitable: {a; b;}
           }
         }

         component direct_multiple_out1
         {
           provides I p;
           requires I r;
           behavior
           {
             on r.a (): p.a ();
             on r.b (): p.b ();
           }
         }

       [small, 1in image]

         // Dezyne --- Dezyne command line tools
         //
         // Copyright © 2018 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
         //
         // This file is part of Dezyne.
         //
         // Dezyne is free software: you can redistribute it and/or modify it
         // under the terms of either:
         //
         //   the GNU Affero General Public License as published by the Free
         //   Software Foundation, either version 3 of the License, or (at your
         //   option) any later version.
         //
         // or
         //
         //  the GNU Free Documentation License version 1.3 or later; with no
         //   Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts,
         //
         // Dezyne is distributed in the hope that it will be useful, but
         // WITHOUT ANY WARRANTY; without even the implied warranty of
         // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
         // Affero General Public License for more details.
         //
         // You should have received a copy of the GNU Affero General Public
         // License along with Dezyne.  If not, see <http://www.gnu.org/licenses/>.

         import direct_multiple_out.dzn;

         component direct_multiple_out2
         {
           provides I p;
           requires I r;
           behavior
           {
             on r.a (): {}
             on r.b (): {p.a (); p.b ();}
           }
         }

       [small, 1in image]

       The third variant is left as an exercise to the reader.

100 lines (more than twice as long) that mostly draw attention to
copyright headers.  Using copyright headers here is clearly
unacceptable, since:

   Some formats do not have room for textual annotations

Furthermore, the examples above are trivial creations, and therefore
not copyrightable.  To remove any doubt, the README makes the dual
licensing clear, the copyright is of course listed in the dezyne.texi
of the manual itself (and can bee derived from git or the ChangeLog).

So with this explanation, we should now be in full compliance with
https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html.

If agree, can you please approve?

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Tue 07 Dec 2021 09:43:44 AM UTC, comment #20: 

> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>
>     Some formats do not have room for textual annotations; for these
>     files, state the copyright and copying permissions in a README file
>     in the same directory.


Quite right.  These are text files, they do have room for textual annotations.

Ineiev <ineiev>
Site Administrator
Tue 07 Dec 2021 08:03:53 AM UTC, comment #19: 

Alfred M. Szmidt writes:

Hello!

So...are we OK now?

> Ineiev writes:
> > examples/README has two issues: first, the AGPL is GFDL-incompatible,


I addressed this in #16, by usingthe GFDL license

> For the examples, another solution is to license them under the AGPL
> and the GFDL.


and then (#18) re-added AGPL as a duel license using this wording

    Dezyne examples are distributed under the terms of either:

      the GNU Free Documentation License version 1.3 or later; with no
      Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts,

    or

      the GNU Affero General Public License version 3 or later.

Maybe I should have included this for you to review yesterday?  If you,
like yesterday, are still waiting for a new tarball to review this
README change, please let me know!

> > second, READMEs may only be used for binary files.


> Your reading of the requirements is far to strict and not what is intended,
> the rules do not apply only to binaries, and it is not a matter of size.
> There are plenty of other considerations to take into account.


and settles the last issue, right?  See
https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

    Some formats do not have room for textual annotations; for these
    files, state the copyright and copying permissions in a README file
    in the same directory.

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 06 Dec 2021 02:50:05 PM UTC, comment #18: 

> For the examples, another solution is to license them under the AGPL and the
> GFDL.


That's a helpful suggestion, thanks!  I will do that just like "Licensing
of GNU Packages" describes.  I did not upload yet another tarball for
this change.

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 06 Dec 2021 02:32:10 PM UTC, comment #17: 

For the examples, another solution is to license them under the AGPL and the GFDL.

Your reading of the requirements is far to strict and not what is intended, the rules do not apply only to binaries, and it is not a matter of size.  There are plenty of other considerations to take into account.

Alfred M. Szmidt <ams>
Mon 06 Dec 2021 01:39:55 PM UTC, comment #16: 

Hello!

> I'm sorry; in fact, I wasn't so busy as I was puzzled.


Ah.  Well, please do not hesitate to add a comment if you have any
other puzzle or question.  We would very much appreciate to get these
last issues resolved.  As you can probably imagine, also some our
users are eagerly anticipating this free software release!

> Files like doc/examples/join.dzn should contain valid copyright and
> license notices,


Sure, they are part of the documentation; the dezyne.texi manual has

    @verbatiminclude examples/join.dzn

so, we distribute a README file in each directory (see comment #10, we
failed to distribute these earlier).

> and if they are part of documentation, their license
> should be GFDL-compatible.  I fail to explain why you missed that.


Ah, so then this was probably your puzzle?  I have done some reading
and I found that [A]GPL code cannot be included in GFDL documentation
(yet, I somehow remembered reading that this issue had long been
"corrected").

The READMEs for the doc/ snippets (and the https://reuse.software
spec) have been updated to specify the GFDL for these code snippets
too.

See:

    https://savannah.nongnu.org/task/download.php?file_id=52440

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Mon 06 Dec 2021 01:34:37 PM UTC, comment #15: 

No, I'm not going to dismiss it abruptly, it has never been my intention.

No, the files are not small; examples/README has two issues: first, the AGPL is GFDL-incompatible, second, READMEs may only be used for binary files.

Ineiev <ineiev>
Site Administrator
Mon 06 Dec 2021 12:14:25 PM UTC, comment #14: 

Lets please assume best intentions, people miss things.

The files are small and can be considered non-copyrightable, so please
don't dismiss it so abruptly.  The examples/README also declares what
the license is of the examples (AGPL).

Alfred M. Szmidt <ams>
Mon 06 Dec 2021 11:26:53 AM UTC, comment #13: 

I'm sorry; in fact, I wasn't so busy as I was puzzled.

Files like doc/examples/join.dzn should contain valid copyright and license notices, and if they are part of documentation, their license should be GFDL-compatible.  I fail to explain why you missed that.

Ineiev <ineiev>
Site Administrator
Fri 03 Dec 2021 07:09:57 PM UTC, comment #12: 

Hi,

Know you're all terribly busy, so here is a friendly ping!

I have also uploaded a new tarball with minor improvements

    https://savannah.nongnu.org/task/download.php?file_id=52424

It was suggested to me that adding https://reuse.software compliancy
might help.  The current tarball is almost compliment, the only
exception is the naming of the license files, we prefer the GNU naming
style (COPYING, COPYING.LESSER etc).

So, I have added a target: check-reuse, to temporarily satisfy the "reuse" tool
in that respect.  Here is what it says right now:

    make check-reuse
    rm -rf LICENSES
    mkdir -p LICENSES LICENCES
    ln COPYING LICENSES/GPL-3.0-or-later.text
    ln COPYING.AGPL LICENSES/AGPL-3.0-or-later.text
    ln COPYING.CC0 LICENSES/CC0-1.0.text
    ln COPYING.LESSER LICENSES/LGPL-3.0-or-later.text
    ln doc/fdl-1.3.texi LICENSES/GFDL-1.3-no-invariants-or-later.text
    reuse lint
    # SUMMARY

    * Bad licenses:
    * Deprecated licenses:
    * Licenses without file extension:
    * Missing licenses:
    * Unused licenses:
    * Used licenses: AGPL-3.0-or-later, CC0-1.0, GFDL-1.3-no-invariants-or-later, GPL-3.0-or-later, LGPL-3.0-or-later
    * Read errors: 0
    * Files with copyright information: 3002 / 3002
    * Files with license information: 3002 / 3002

    Congratulations! Your project is compliant with version 3.0 of the REUSE Specification :-)
    rm -rf LICENSES

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Fri 03 Dec 2021 07:04:26 PM UTC, comment #11: 

What is holding up accepting this package?

From what I see the issues raised are minor.

Alfred M. Szmidt <ams>
Fri 26 Nov 2021 11:34:48 AM UTC, comment #10: 

Hello Ineiev,

> Follow-up Comment #9, task #16067 (project administration):
>
> Your copies of the GPL and the LGPL differ by a few characters from current
> GNU files; please update them from https://www.gnu.org/licenses/gpl-3.0.html
> and https://www.gnu.org/licenses/lgpl-3.0.html.


Okay updated just now to the latest versions to use https:// and spaces
instead of TABs.  Thank you.

> Files like test/all/semantics/semantics.org still have no valid copyright and
> license notices.


Yes, that's another test baseline file for an irregular test.  Moved to

   test/all/semantics/baseleline/semantics.org

updated the test script, and removed from the distribution.

Similarly, for the test baseline data in

    test/all/state-diagram/default.dot
    test/all/state-diagram/hide-actions.dot
    test/all/state-diagram/hide-labels.dot
    test/all/state-diagram/remove-extended.dot
    test/all/state-diagram/remove-ports.dot

moved to:

    test/all/state-diagram/baseline/default.dot
    test/all/state-diagram/baseline/hide-actions.dot
    test/all/state-diagram/baseline/hide-labels.dot
    test/all/state-diagram/baseline/remove-extended.dot
    test/all/state-diagram/baseline/remove-ports.dot

updated the test script, and removed from the distribution.

> Next time, please check all copyrightable files before submitting your
> new tarball again.


We wrote a script and found a 3-line script wrapper

    bin/scm2json.in

that was missing a copyright header.  As it has been obsolete for some
years now, it has been removed.

We also found that some README files were in place but missing from
the distribution; this has been corrected; these are now also
distributed:

   doc/examples/README
   doc/parse/README
   doc/semantics/README
   dzn/templates/README
   test/language/README
   test/lts/README

See:

    https://savannah.nongnu.org/task/download.php?file_id=52345

Greetings,
Janneke

Jan Nieuwenhuizen <janneke>
Fri 26 Nov 2021 07:50:35 AM UTC, comment #9: 

Your copies of the GPL and the LGPL differ by a few characters from current GNU files; please update them from https://www.gnu.org/licenses/gpl-3.0.html and https://www.gnu.org/licenses/lgpl-3.0.html.

Files like test/all/semantics/semantics.org still have no valid copyright and license notices. Next time, please check all copyrightable files before submitting your new tarball again.

Ineiev <ineiev>
Site Administrator
Wed 24 Nov 2021 02:48:27 PM UTC, comment #8: 

```
Ineiev writes:

> Follow-up Comment #7, task #16067 (project administration):
>
>> I wholeheartedly agree that we must reduce ambiguity and minimize the
>> risk of error thereby mitigating the risk of legal exposure. At the
>> same time this risk -- a product of likelyhood and impact -- has to be
>> weighed against the effort involved.
>
> I think one should be a lawyer in order to estimate the risk.  FSF's lawyers
> did that and wrote the current recommendations.


Yes, I know the recommendations.

> Now, what effort would be involved?  I guess, preprocessing the files with a
> one-line script before comparing them against the output.


Sadly the effort that would be involved is considerably higher than
this.

So we have decided to remove the test data baseline from the
distribution:

    https://savannah.nongnu.org/task/download.php?file_id=52338

and I very much hope we are OK now!

Greetings,
Janneke
```

Jan Nieuwenhuizen <janneke>
Tue 23 Nov 2021 11:04:44 AM UTC, comment #7: 

> I wholeheartedly agree that we must reduce ambiguity and minimize the
> risk of error thereby mitigating the risk of legal exposure. At the
> same time this risk -- a product of likelyhood and impact -- has to be
> weighed against the effort involved.


I think one should be a lawyer in order to estimate the risk.  FSF's lawyers did that and wrote the current recommendations.

Now, what effort would be involved?  I guess, preprocessing the files with a one-line script before comparing them against the output.

> I have asked some other free software
> developers and have looked for inspiration in other GNU
> projects.


This isn't a very strong argument: what if those GNU packages err exactly in those places?

Ineiev <ineiev>
Site Administrator
Fri 12 Nov 2021 11:24:07 AM UTC, comment #6: 

```
Ineiev writes:

> Follow-up Comment #5, task #16067 (project administration):
>
> comment #4:
>>
>> The baseline files are generated, like so
>>
>>     ./pre-inst-env dzn -v verify test/all/Alarm/Alarm.dzn \
>>        > test/all/Alarm/baseline/verify/Alarm \
>>        2> test/all/Alarm/baseline/verify/Alarm.stderr
>
> That doesn't make them uncopyrightable: if I generate an ASCII art file from a
> bronze statue, the result will be a derived work and inherit the copyright of
> the original picture; the fact that it's machine-readable mustn't
> matter---after all, any file is machine-readable (did you mean something
> else?).


I wholeheartedly agree that we must reduce ambiguity and minimize the
risk of error thereby mitigating the risk of legal exposure. At the
same time this risk -- a product of likelyhood and impact -- has to be
weighed against the effort involved.  I struggle to find a
satisfactory solution for this.  I have asked some other free software
developers and have looked for inspiration in other GNU
projects. These are my findings:

GAWK and SED use generated ASCII output in a tree directory structure,
without individual copyright/licence headers:

    https://git.savannah.gnu.org/cgit/gawk.git/tree/test/badargs.ok

Gawk does have the README in the same directory but it does not
mention all ~1000 files explicitly.

    https://git.savannah.gnu.org/cgit/gawk.git/tree/test/README

SED does not have a README in their test baseline directory and
depends on a higher level README, like Dezyne does right now:

    https://git.savannah.gnu.org/cgit/sed.git/tree/testsuite/8bit.good

GCC and GLIBC use an approach that is even more similar to Dezyne, no
copyrigt/licence header on any of their test baseline data, see e.g.,

    https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=fixincludes/tests/base/bits/fenv.h
    https://ftp.gnu.org/pub/gnu/gcc/gcc-11.2.0/gcc-11.2.0.tar.gz
      gcc-11.2.0/fixincludes/tests/base/bits/fenv.h

    https://sourceware.org/git/?p=glibc.git;a=blob;f=iconvdata/testdata/ANSI_X3.4-1968
    https://ftp.gnu.org/pub/gnu/glibc/glibc-2.34.tar.gz
      glibc-2.34/iconvdata/testdata/ANSI_X3.4-1968

and no README in every individual directory that mentions every file
explicitly.

After seeing these examples, I fail to see why the README

    dezyne-2.14.0.rc2.10-c7b90/test/all/README

in

    https://savannah.nongnu.org/task/download.php?file_id=52258

that states it holds for all subdirectories, does not adequately
address all our collective needs.

Greetings,
Janneke
```

Jan Nieuwenhuizen <janneke>
Fri 12 Nov 2021 07:48:18 AM UTC, comment #5: 

comment #4:

>
> "Inconvenient" was really the wrong term to use.  I should have said
> something like: "generated and machine-readable".  Sorry fo the
> confusion!


I'm not sure I restore the whole intended sentence correctly, then.

> The baseline files are generated, like so
>
>     ./pre-inst-env dzn -v verify test/all/Alarm/Alarm.dzn \
>        > test/all/Alarm/baseline/verify/Alarm \
>        2> test/all/Alarm/baseline/verify/Alarm.stderr


That doesn't make them uncopyrightable: if I generate an ASCII art file from a bronze statue, the result will be a derived work and inherit the copyright of the original picture; the fact that it's machine-readable mustn't matter---after all, any file is machine-readable (did you mean something else?).

Ineiev <ineiev>
Site Administrator
Thu 11 Nov 2021 10:52:31 AM UTC, comment #4: 

```
Ineiev writes:

Hello Ineiev,

> comment #2:
>>
>> > test/all/livelock_synchronous/baseline/simulate/livelock_synchronous
>> > ideally,
>> > they should additionally contain copyright and license notices.
>>
>> Right.  These baselines are generated and diffed against the output:
>> a header would be very inconvenient and there is not much to
>> copyright either.
>
> I believe they are copyrightable, and I'm not convinced headers
> are really inconvenient---no more than it's inconvenient to follow
> the GPL or to call the operating system "GNU/Linux".


"Inconvenient" was really the wrong term to use.  I should have said
something like: "generated and machine-readable".  Sorry fo the
confusion!

> These are text files, the copyright and license notices should be
> included in them.


Eh no -- this does not make any sense to me.  My fault for setting you
off on the wrong foot, sorry.

The baseline files are generated, like so

    ./pre-inst-env dzn -v verify test/all/Alarm/Alarm.dzn \
       > test/all/Alarm/baseline/verify/Alarm \
       2> test/all/Alarm/baseline/verify/Alarm.stderr

the regression test then DIFFs the output, like so:

    diff -u test/all/Alarm/baseline/verify/Alarm \
     <(./pre-inst-env dzn -v verify test/all/Alarm/Alarm.dzn)

The input trace files are generated by dzn verify, e.g.

    ./pre-inst-env dzn verify test/all/Alarm/Alarm.dzn \
      > test/all/Alarm/trace

and are also machine readable, both this

    ./pre-inst-env dzn verify test/all/Alarm/Alarm.dzn \
      | ./pre-inst-env dzn simutale test/all/Alarm/Alarm.dzn

and this

    cat test/all/Alarm/trace
      | ./pre-inst-env dzn simutale test/all/Alarm/Alarm.dzn

are valid commands.

Of course, before applying patches they should be properly reviewed!  We
use a very strict layout for test/all/*, as every directory is processed
in a generic way by the regression test framework.  I am convinced that
anything out of the ordinary should be easily spotted.

>> > Then, the LGPLv3 is written as additional permissions for GPLv3; if you
> use
>> > it, you
>> > should also include a copy of GPLv3, your tarball misses it.
>>
>> Ah sure; another oversight: COPYING.LESSER is in the git archive, I've
>> added it to the distribution.
>
> Err...
>
> The LGPLv3 is written as additional permissions for GPLv3;
> if you use it, you should also include a copy of GPLv3,
> your tarball misses it.


Oops, I misread your remark; I thought it was COPYING.LESSER that was
missing...  It makes much sense to me now, I just never distributed
anything using the LGPL before.  I have included a COPYING.GPL file in
the archive and in the distribution too.

Thanks!  Greetings,
Janneke
```

(file #52236)

Jan Nieuwenhuizen <janneke>
Thu 11 Nov 2021 08:43:36 AM UTC, comment #3: 

comment #2:

>
> > test/all/livelock_synchronous/baseline/simulate/livelock_synchronous
> > ideally,
> > they should additionally contain copyright and license notices.
>
> Right.  These baselines are mostly generated and diffed against the
> output: a header would be very inconvenient and there is not much to
> copyright either.


I believe they are copyrightable, and I'm not convinced headers
are really inconvenient---no more than it's inconvenient to follow
the GPL or to call the operating system "GNU/Linux".

> I have now added this test/all/README:
>
> --8<---------------cut here---------------start------------->8---
> #+TITLE: Dezyne test baseline
>
> Copyright © 2021 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
>
>   Copying and distribution of this file, with or without modification,
>   are permitted in any medium without royalty provided the copyright
>   notice and this notice are preserved.
>
> Additional test data files:
>
>     META:     */META
>     baseline: */baseline/...
>     trace:    */trace
>
>     All META, baseline and trace files are distributed under the GNU Affero
>     General Public License version 3 or later.
> --8<---------------cut here---------------end--------------->8---


These are text files, the copyright and license notices should be included
in them.  README files should be in the same directory with the files
in question, and they should only be used when those files can't contain
copyright and license notices---and they should list the covered files
explicitly, if they don't, it's too easy to get the things wrong
when someone adds new unrelated files.

> > Then, the LGPLv3 is written as additional permissions for GPLv3; if you use
> > it, you
> > should also include a copy of GPLv3, your tarball misses it.
>
> Ah sure; another oversight: COPYING.LESSER is in the git archive, I've
> added it to the distribution.


Err...

The LGPLv3 is written as additional permissions for GPLv3;
if you use it, you should also include a copy of GPLv3,
your tarball misses it.

> For Mes and Emacsy I have chosen to relicense the files with an LGPL
> header.  This was an oversight.  I have added a patch to change the

...

> Also, I have fixed the gen-ChangeLog target to include the ChangeLog
> stub that holds the copyright and license; for Dezyne and Emacsy.


Thank you!

Ineiev <ineiev>
Site Administrator
Tue 09 Nov 2021 11:27:55 AM UTC, comment #2: 

[my email reply to -email is unavailable- does not seem to show up here, pasted below]
```
Ineiev writes:

Hi Ineiev,

> Files like
> test/all/async_calling_context/cs/main.cs have no copyright and license
> notices.
> Files like test/all/shell_injected/c++/main.cc do refer to their sources, but
> ideally,
> they should additionally contain copyright and license notices.


Oops; these were all generated and manually changed (mains that do not
need any change are not distributed).  I have removed the "Generated by"
and added a regular copyright header to:

    test/all/async_calling_context/c++/main.cc
    test/all/async_calling_context/cs/main.cs
    test/all/async_shell/c++/main.cc
    test/all/async_shell/cs/main.cs
    test/all/blocking_shell/c++/main.cc
    test/all/blocking_shell/cs/main.cs
    test/all/hello_namespace_foreign/c++/library_foreign.cc
    test/all/shell_injected/c++/main.cc
    test/all/shell_injected/cs/main.cs
    test/bin/semantics.sh

> test/all/livelock_synchronous/baseline/simulate/livelock_synchronous
> ideally,
> they should additionally contain copyright and license notices.


Right.  These baselines are mostly generated and diffed against the
output: a header would be very inconvenient and there is not much to
copyright either.  The same goes for trace files and the JSON META
files.

I have now added this test/all/README:

--8<---------------cut here---------------start------------->8---
#+TITLE: Dezyne test baseline

Copyright © 2021 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>

  Copying and distribution of this file, with or without modification,
  are permitted in any medium without royalty provided the copyright
  notice and this notice are preserved.

Additional test data files:

    META:     */META
    baseline: */baseline/...
    trace:    */trace

    All META, baseline and trace files are distributed under the GNU Affero
    General Public License version 3 or later.
--8<---------------cut here---------------end--------------->8---

> Then, the LGPLv3 is written as additional permissions for GPLv3; if you use
> it, you
> should also include a copy of GPLv3, your tarball misses it.


Ah sure; another oversight: COPYING.LESSER is in the git archive, I've
added it to the distribution.

> Could you also check GNU Mes and Emacsy?  For example, ChangeLog in
> Emacsy tarballs misses copyright and license notices; some Emacsy
> files refer to the LGPL, but no copy of that license is provided.


For Mes and Emacsy I have chosen to relicense the files with an LGPL
header.  This was an oversight.  I have added a patch to change the
copyright header for these

    mes/module/mes/lalr.scm
    module/mes/getopt-long.scm
    module/mes/optargs.scm

so that they are also distributed under the GPL v3+.  They were imported
from GNU Guile but there is no need to use the LGPL here.

And similarly for Emacsy:

   emacsy/agenda.scm
   emacsy/coroutine.scm
   scripts/doc-snarf.scm

Also, I have fixed the gen-ChangeLog target to include the ChangeLog
stub that holds the copyright and license; for Dezyne and Emacsy.

Greetings,
Janneke

```

(file #52227)

Jan Nieuwenhuizen <janneke>
Tue 09 Nov 2021 08:34:18 AM UTC, comment #1: 

Files like test/all/livelock_synchronous/baseline/simulate/livelock_synchronous
test/all/async_calling_context/cs/main.cs have no copyright and license notices.
Files like test/all/shell_injected/c++/main.cc do refer to their sources, but ideally,
they should additionally contain copyright and license notices.

Then, the LGPLv3 is written as additional permissions for GPLv3; if you use it, you
should also include a copy of GPLv3, your tarball misses it.

Could you also check GNU Mes and Emacsy? For example, ChangeLog in Emacsy tarballs misses copyright and license notices; some Emacsy files refer to the LGPL, but no copy of that license is provided.

Ineiev <ineiev>
Site Administrator
Wed 03 Nov 2021 10:30:33 AM UTC, original submission:  

A new project has been registered at Savannah
This project account will remain inactive until a site admin approves
or discards the registration.

Registration Administration

While this item will be useful to track the registration process,
approving or discarding the registration must be done using the specific Group Administration page, accessible only to site administrators,
effectively logged as site administrators (superuser):

Registration Details

  • Name: Dezyne
  • System Name:  dezyne
  • Type: non-GNU software and documentation
  • License: GNU Affero General Public License v3 or later (for the runtime: GNU LESSER GPL v3 or later

for the documentation: GNU FDL v1.3 or later)


Description:

Dezyne is a programming language and set of tools that aim to eliminate
the need for testing by applying formal verification methods.

The Dezyne language uses a component model that implements event based
coroutines.

Dezyne is free software, it is distributed under the terms of the GNU
Affero General Public Licence version 3 or later.

Dezyne comes with dzn-runtime: a reference implementation for component
coroutines.  dzn-runtime is free software, it is distributed under the
terms of the GNU Lesser General Public Licence version 3 or later.

Other Software Required:

GNU Guile 3.0.5 or later -- LGPL v3+ -- https://gnu.org/software/guile/
Guile-JSON version 4.x -- GPL v3+ -- https://savannah.nongnu.org/projects/guile-json/
GNU Make -- GPL v3+ -- https://www.gnu.org/software/make/
mCRL2 version 202106.0  Boost Software License, Version 1.0 -- https://mcrl2.org

To run the regression test, these additional packages are needed:

- for C++11: GNU gcc (g++) version 5.4 or later -- GPL v3+ -- https://gcc.gnu.org

Other Comments:

Project website: dezyne.org
Company website: verum.com

Verum will announce the release version 2.14.0 as free software on November 16th and I will want to upload a git archive then.

We will want to have a git upload check for commits to be signed, like GNU guix has.

Attached is a the latest release candidate for version 2.14.0

Tarball URL:

https://savannah.nongnu.org/submissions_uploads/dezyne-2.14.0.rc1.tar.gz

Jan Nieuwenhuizen <janneke>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52825:  dezyne-2.14.0.rc2.118-6f4c44.tar.gz added by janneke (2MiB - application/gzip - dezyne-2.14.0.rc2.118-6f4c44.tar.gz, missing .hh header, tarballs no longer necessary)
file #52460:  dezyne-2.14.0.rc2.112-fde70.tar.gz added by janneke (1MiB - application/gzip - dezyne-2.14.0.rc2.112-fde70.tar.gz, doc snippets ASCII files removed)
file #52440:  dezyne-2.14.0.rc2.112-b9b1e.tar.gz added by janneke (2MiB - application/gzip - dezyne-2.14.0.rc2.112-b9b1e.tar.gz, doc snippets now GFDL)
file #52345:  dezyne-2.14.0.rc2.40-d1a779.tar.gz added by None (1MiB - application/x-gzip - dezyne-2.14.0.rc2.40-d1a779.tar.gz)
file #52338:  dezyne-2.14.0.rc2.11-0ece7.tar.gz added by janneke (1MiB - application/x-gzip - dezyne-2.14.0.rc2.11-0ece7)
file #52258:  dezyne-2.14.0.rc2.10-c7b90.tar.gz added by janneke (1MiB - application/x-gzip - dezyne-2.14.0.rc2.10-c7b90.tar.gz)
file #52236:  dezyne-2.14.0.rc2.2-d39ba7.tar.gz added by janneke (1MiB - application/x-gzip)
file #52227:  dezyne-2.14.0.rc1.5-a452e.tar.gz added by janneke (1MiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rocher (Posted a comment)
  • -email is unavailable- added by rocher (Voted in favor of this item)
  • -email is unavailable- added by bandali (Posted a comment)
  • -email is unavailable- added by janneke
  • -email is unavailable- added by carlc (Voted in favor of this item)
  • -email is unavailable- added by janneke
  • -email is unavailable- added by ams (Posted a comment)
  • -email is unavailable- added by janneke (Voted in favor of this item)
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by janneke (Submitted the item)
  •  

    There are 181 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-28 ineiev StatusIn Progress Done
        Open/ClosedOpen Closed
    2022-03-17 ineiev Carbon-CopyRemoved 289157 -
    2022-03-17 ineiev Carbon-CopyRemoved fontdevelopment -
    2022-03-09 rocher Carbon-Copy- Added rocher
    2022-02-09 janneke Attached File- Added dezyne-2.14.0.rc2.118-6f4c44.tar.gz, #52825
    2022-02-02 janneke Carbon-Copy- Added bandali
    2022-01-27 carlc Carbon-Copy- Added carlc
    2022-01-05 _289157 Carbon-Copy- Added fontdevelopment
    2021-12-09 janneke Attached File- Added dezyne-2.14.0.rc2.112-fde70.tar.gz, #52460
    2021-12-07 janneke Carbon-Copy- Added rutger
    2021-12-06 janneke Attached File- Added dezyne-2.14.0.rc2.112-b9b1e.tar.gz, #52440
    2021-12-03 janneke Attached File- Added dezyne-2.14.0.rc2.106-e34fb.tar.gz, #52424
    2021-11-26 janneke Carbon-Copy- Added janneke
    2021-11-26 None Attached File- Added dezyne-2.14.0.rc2.40-d1a779.tar.gz, #52345
    2021-11-24 janneke Attached File- Added dezyne-2.14.0.rc2.11-0ece7.tar.gz, #52338
    2021-11-12 janneke Attached File- Added dezyne-2.14.0.rc2.10-c7b90.tar.gz, #52258
    2021-11-11 janneke Attached File- Added dezyne-2.14.0.rc2.2-d39ba7.tar.gz, #52236
    2021-11-09 janneke Attached File- Added dezyne-2.14.0.rc1.5-a452e.tar.gz, #52227
    2021-11-09 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top


    Powered by Savane 3.9