Re: [task #16067] Submission of Dezyne

[Francesc Rocher]

Hi Iniev,

I'm very glad to see that the process was unblocked and the code released.
Whatever was the agreement between you, I'm pretty sure the submitters are
willing to improve and solve the details.

BR,
-- Francesc Rocher


On Mon, Mar 28, 2022 at 6:15 PM Ineiev  wrote:

> Update of task #16067 (project administration):
>
>   Status: In Progress => Done
>
>  Open/Closed:Open => Closed
>
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via Savannah
>   https://savannah.nongnu.org/
>
>

[task #16067] Submission of Dezyne

[Ineiev]

Update of task #16067 (project administration):

  Status: In Progress => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Francesc Rocher]

Follow-up Comment #37, task #16067 (project administration):

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

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #36, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #35, task #16067 (project administration):

[comment #34 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #34, task #16067 (project administration):

>> 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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.118-6f4c44.tar.gz Size:1630 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #33, task #16067 (project administration):

[comment #32 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #32, task #16067 (project administration):

> 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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #31, task #16067 (project administration):


[comment #30 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Amin Bandali]

Follow-up Comment #30, task #16067 (project administration):

Hi Janneke, all,

Sorry about the long delay here.

[comment #27 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[The fundamentals of fontdevelopm]

Follow-up Comment #29, task #16067 (project administration):


[comment #28 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #28, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #27, task #16067 (project administration):

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//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//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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #26, task #16067 (project administration):

[comment #24 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #25, task #16067 (project administration):

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

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.112-fde70.tar.gz Size:1444 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #24, task #16067 (project administration):

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.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #23, task #16067 (project administration):

[comment #21 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #22, task #16067 (project administration):

[typo]
* If you agree, can you please approve?

Greetings,
Janneke


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #21, task #16067 (project administration):

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 
 //
 // 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
.

 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 
 //
 // 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
  

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #20, task #16067 (project administration):

> 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #19, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #18, task #16067 (project administration):

> 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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Alfred M. Szmidt]

Follow-up Comment #17, task #16067 (project administration):

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: [task #16067] Submission of Dezyne

[Alfred M. Szmidt]

   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.

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 abrubtly.  The examples/README also declares what
the license is of the examples (AGPL).

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #16, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.112-b9b1e.tar.gz Size:1618 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #15, task #16067 (project administration):

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Alfred M. Szmidt]

Follow-up Comment #14, task #16067 (project administration):

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).


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #13, task #16067 (project administration):

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #12, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Alfred M. Szmidt]

Follow-up Comment #11, task #16067 (project administration):

What is holding up accepting this package?

>From what I see the issues raised are minor.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.106-e34fb.tar.gz Size:1620 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #10, task #16067 (project administration):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[anonymous]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.40-d1a779.tar.gz Size:1363 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[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.

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #8, task #16067 (project administration):

```
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
```

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.11-0ece7.tar.gz Size:1361 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

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.

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?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #6, task #16067 (project administration):

```
Ineiev writes:

> Follow-up Comment #5, task #16067 (project administration):
>
> [comment #4 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
```

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Additional Item Attachment, task #16067 (project administration):

File name: dezyne-2.14.0.rc2.10-c7b90.tar.gz Size:1415 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

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

[comment #4 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?).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #4, task #16067 (project administration):

```
Ineiev writes:

Hello Ineiev,

> [comment #2 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)
___

Additional Item Attachment:

File name: dezyne-2.14.0.rc2.2-d39ba7.tar.gz Size:1414 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Follow-up Comment #3, task #16067 (project administration):

[comment #2 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 
> 
>   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!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: [task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

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 

  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

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

Follow-up Comment #2, task #16067 (project administration):

[my email reply to savannah-register-public@gnu.org 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 

  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)
___

Additional Item Attachment:

File name: dezyne-2.14.0.rc1.5-a452e.tar.gz Size:1390 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Ineiev]

Update of task #16067 (project administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[task #16067] Submission of Dezyne

[Jan Nieuwenhuizen]

URL:
  

 Summary: Submission of Dezyne
 Project: Savannah Administration
Submitted by: janneke
Submitted on: Wed 03 Nov 2021 11:30:33 AM CET
 Should Start On: Wed 03 Nov 2021 12:00:00 AM CET
   Should be Finished on: Sat 13 Nov 2021 12:00:00 AM CET
Category: Project Approval
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

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):

* Group Administration



= 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






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/