Re: guile-user Digest, Vol 204, Issue 2

Re: guile-user Digest, Vol 204, Issue 2

[Zelphir Kaltstahl]

This is great! A solid JSON parsing and outputting library is important
for a programming language these days! Thanks for your work!

On 11/5/19 6:00 PM, guile-user-request@gnu.org wrote:
> Message: 1
> Date: Mon, 4 Nov 2019 22:28:12 -0800
> From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
> To: guile-user <guile-user@gnu.org>
> Subject: [ANN] guile-json 3.3.0 released
> Message-ID:
> 	<CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I'm pleased to announce guile-json 3.3.0. This new version comes with a few
> improvements: guile-json will now throw an exception if the native scheme
> value used to build a JSON document is invalid (this is done before
> printing any JSON). Also, an additional key argument #:validate can be
> given to ignore the validation in the case performance is important and the
> data is known to be valid. Empty JSON array slots are also considered
> invalid, before they were generating an invalid scheme representation. A
> few more details can be found on the NEWS file.
>
> https://github.com/aconchillo/guile-json
>
> Best,
>
> Aleix

Re: guile-user Digest, Vol 204, Issue 2

[John Cowan]

+1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
implementation....

Is there any chance of dual-licensing it under MIT?

On Tue, Nov 5, 2019 at 7:03 PM Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
wrote:

> This is great! A solid JSON parsing and outputting library is important
> for a programming language these days! Thanks for your work!
>
> On 11/5/19 6:00 PM, guile-user-request@gnu.org wrote:
> > Message: 1
> > Date: Mon, 4 Nov 2019 22:28:12 -0800
> > From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
> > To: guile-user <guile-user@gnu.org>
> > Subject: [ANN] guile-json 3.3.0 released
> > Message-ID:
> >       <
> CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi,
> >
> > I'm pleased to announce guile-json 3.3.0. This new version comes with a
> few
> > improvements: guile-json will now throw an exception if the native scheme
> > value used to build a JSON document is invalid (this is done before
> > printing any JSON). Also, an additional key argument #:validate can be
> > given to ignore the validation in the case performance is important and
> the
> > data is known to be valid. Empty JSON array slots are also considered
> > invalid, before they were generating an invalid scheme representation. A
> > few more details can be found on the NEWS file.
> >
> > https://github.com/aconchillo/guile-json
> >
> > Best,
> >
> > Aleix
>
>

guile-json, SRIFs and licenses

[Zelphir Kaltstahl]

Hi!

What is the requirement in terms of licenses for SRFI implementations?

I personally think that MIT is a terrible license (one of the I don't
care licenses) as it does not make sure, that modifications flow back to
the community. Do SRFIs require MIT license? And if so, why?

~ Zelphir

On 11/6/19 1:28 AM, John Cowan wrote:
> +1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
> implementation....
>
> Is there any chance of dual-licensing it under MIT?
>
> On Tue, Nov 5, 2019 at 7:03 PM Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
> wrote:
>
>> This is great! A solid JSON parsing and outputting library is important
>> for a programming language these days! Thanks for your work!
>>
>> On 11/5/19 6:00 PM, guile-user-request@gnu.org wrote:
>>> Message: 1
>>> Date: Mon, 4 Nov 2019 22:28:12 -0800
>>> From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
>>> To: guile-user <guile-user@gnu.org>
>>> Subject: [ANN] guile-json 3.3.0 released
>>> Message-ID:
>>>       <
>> CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> Hi,
>>>
>>> I'm pleased to announce guile-json 3.3.0. This new version comes with a
>> few
>>> improvements: guile-json will now throw an exception if the native scheme
>>> value used to build a JSON document is invalid (this is done before
>>> printing any JSON). Also, an additional key argument #:validate can be
>>> given to ignore the validation in the case performance is important and
>> the
>>> data is known to be valid. Empty JSON array slots are also considered
>>> invalid, before they were generating an invalid scheme representation. A
>>> few more details can be found on the NEWS file.
>>>
>>> https://github.com/aconchillo/guile-json
>>>
>>> Best,
>>>
>>> Aleix
>>

Re: guile-json, SRIFs and licenses

[John Cowan]

The MIT license is required for all SRFIs, both texts and implementations:
the exact wording appears at the end of every SRFI, and is adjusted over
time as the MIT license changes (very slightly).  I wasn't there at the
time, but it was probably adopted because MIT, like BSD, is a universal
donor: it can be incorporated into software that is preponderantly under
any other license.  Chicken, for instance, is under the BSD license, but
you can compile and distribute a Chicken program under any license — unless
it incorporates one of the 31 GPLed eggs.

What looks like a commons from inside the GNUverse looks more like a walled
garden to the rest of FLOSS.



On Wed, Nov 6, 2019 at 3:19 AM Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
wrote:

> Hi!
>
> What is the requirement in terms of licenses for SRFI implementations?
>
> I personally think that MIT is a terrible license (one of the I don't
> care licenses) as it does not make sure, that modifications flow back to
> the community. Do SRFIs require MIT license? And if so, why?
>
> ~ Zelphir
>
> On 11/6/19 1:28 AM, John Cowan wrote:
> > +1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
> > implementation....
> >
> > Is there any chance of dual-licensing it under MIT?
> >
> > On Tue, Nov 5, 2019 at 7:03 PM Zelphir Kaltstahl <
> zelphirkaltstahl@posteo.de>
> > wrote:
> >
> >> This is great! A solid JSON parsing and outputting library is important
> >> for a programming language these days! Thanks for your work!
> >>
> >> On 11/5/19 6:00 PM, guile-user-request@gnu.org wrote:
> >>> Message: 1
> >>> Date: Mon, 4 Nov 2019 22:28:12 -0800
> >>> From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
> >>> To: guile-user <guile-user@gnu.org>
> >>> Subject: [ANN] guile-json 3.3.0 released
> >>> Message-ID:
> >>>       <
> >> CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
> >>> Content-Type: text/plain; charset="UTF-8"
> >>>
> >>> Hi,
> >>>
> >>> I'm pleased to announce guile-json 3.3.0. This new version comes with a
> >> few
> >>> improvements: guile-json will now throw an exception if the native
> scheme
> >>> value used to build a JSON document is invalid (this is done before
> >>> printing any JSON). Also, an additional key argument #:validate can be
> >>> given to ignore the validation in the case performance is important and
> >> the
> >>> data is known to be valid. Empty JSON array slots are also considered
> >>> invalid, before they were generating an invalid scheme representation.
> A
> >>> few more details can be found on the NEWS file.
> >>>
> >>> https://github.com/aconchillo/guile-json
> >>>
> >>> Best,
> >>>
> >>> Aleix
> >>
>
>

Re: guile-json, SRIFs and licenses

[Zelphir Kaltstahl]

Hi John!

I am just putting my thoughts he, as I do not decide these matters of
course:

I think in this case, it might be a good idea to make sure, that
guile-json runs on all Schemes implementing a standard level and keep it
free software, to avoid the problem of people grabbing it and making it
proprietary software. If it is that standard conform, it would hopefully
require no effort to use the library in other Schemes. Then the only
obstacle would be finding the repository and downloading the code.

Not sure how standard Guile's module system is, but maybe one could use
a module system from the SRFIs to get more compatibility with other
Scheme dialects.

What would be the effects of guile-json being dual-licensed?

If the implementation for an SRFI is under MIT, cannot people take that
instead of the original guile-json repository and make it proprietary?

How could the dual license work, so that we still make sure, that
guile-json can only be used as free software?

Regards,

Zelphir

On 11/6/19 3:36 PM, John Cowan wrote:
> The MIT license is required for all SRFIs, both texts and
> implementations: the exact wording appears at the end of every SRFI,
> and is adjusted over time as the MIT license changes (very slightly). 
> I wasn't there at the time, but it was probably adopted because MIT,
> like BSD, is a universal donor: it can be incorporated into software
> that is preponderantly under any other license.  Chicken, for
> instance, is under the BSD license, but you can compile and distribute
> a Chicken program under any license — unless it incorporates one of
> the 31 GPLed eggs.
>
> What looks like a commons from inside the GNUverse looks more like a
> walled garden to the rest of FLOSS.
>
>
>
> On Wed, Nov 6, 2019 at 3:19 AM Zelphir Kaltstahl
> <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@posteo.de>> wrote:
>
>     Hi!
>
>     What is the requirement in terms of licenses for SRFI implementations?
>
>     I personally think that MIT is a terrible license (one of the I don't
>     care licenses) as it does not make sure, that modifications flow
>     back to
>     the community. Do SRFIs require MIT license? And if so, why?
>
>     ~ Zelphir
>
>     On 11/6/19 1:28 AM, John Cowan wrote:
>     > +1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
>     > implementation....
>     >
>     > Is there any chance of dual-licensing it under MIT?
>     >
>     > On Tue, Nov 5, 2019 at 7:03 PM Zelphir Kaltstahl
>     <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@posteo.de>>
>     > wrote:
>     >
>     >> This is great! A solid JSON parsing and outputting library is
>     important
>     >> for a programming language these days! Thanks for your work!
>     >>
>     >> On 11/5/19 6:00 PM, guile-user-request@gnu.org
>     <mailto:guile-user-request@gnu.org> wrote:
>     >>> Message: 1
>     >>> Date: Mon, 4 Nov 2019 22:28:12 -0800
>     >>> From: Aleix Conchillo Flaqué <aconchillo@gmail.com
>     <mailto:aconchillo@gmail.com>>
>     >>> To: guile-user <guile-user@gnu.org <mailto:guile-user@gnu.org>>
>     >>> Subject: [ANN] guile-json 3.3.0 released
>     >>> Message-ID:
>     >>>       <
>     >>
>     CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com
>     <mailto:CA%2BXASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>>
>     >>> Content-Type: text/plain; charset="UTF-8"
>     >>>
>     >>> Hi,
>     >>>
>     >>> I'm pleased to announce guile-json 3.3.0. This new version
>     comes with a
>     >> few
>     >>> improvements: guile-json will now throw an exception if the
>     native scheme
>     >>> value used to build a JSON document is invalid (this is done
>     before
>     >>> printing any JSON). Also, an additional key argument
>     #:validate can be
>     >>> given to ignore the validation in the case performance is
>     important and
>     >> the
>     >>> data is known to be valid. Empty JSON array slots are also
>     considered
>     >>> invalid, before they were generating an invalid scheme
>     representation. A
>     >>> few more details can be found on the NEWS file.
>     >>>
>     >>> https://github.com/aconchillo/guile-json
>     >>>
>     >>> Best,
>     >>>
>     >>> Aleix
>     >>
>

Re: guile-json, SRIFs and licenses

[John Cowan]

On Wed, Nov 6, 2019 at 9:56 AM Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
wrote:

> I think in this case, it might be a good idea to make sure, that
> guile-json runs on all Schemes implementing a standard level and keep it
> free software, to avoid the problem of people grabbing it and making it
> proprietary software.
>
Lots of people who are quite committed to free and open source software
don't actually think that's a problem.  There are two traditional arguments
in favor of putting libraries under the GPL:

1) "Block embrace, extend, and extinguish":  the proprietary version gets
all the new and sexy features while the original FLOSS version languishes.
I don't think this is much of a problem for an implementation controlled by
a stable specification like a SRFI: new features will be non-conforming
features.

2) "Benefit GPLed programs":  if a library is GPLed, it supposedly gives
the advantages of using that library only to GPLed applications.  That was
the explicit reason for making readline a GPL library, and it did make
CLISP GPL-licensed; similarly with the Objective-C front end to gcc.   I
think history shows that this doesn't work very well in the long run:
rather than accepting the GPL, a lot of duplicative effort was put into
libedit/editline, which provides the same user-visible functions (but no
longer has a readline-compatible interface).  One of the purposes of FLOSS
is to try to *prevent* duplicated effort.

If it is that standard conform, it would hopefully require no effort to use
> the library in other Schemes. Then the only obstacle would be finding the
> repository and downloading the code.
>

That could be said of any license.  Whether or not a GPLed JSON library
requires the Scheme implementation to be itself GPL depends on the
implementation, but certainly a stand-alone *application* that uses it
would have to be.

> How could the dual license work, so that we still make sure, that
> guile-json can only be used as free software?
>

You can't.  If blocking proprietary free-riding is more important than
widespread use across different Schemes (the goal of the SRFIs and all
standardization efforts), then the GPL is the license of choice.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
And through this revolting graveyard of the universe the muffled,
maddening beating of drums, and thin, monotonous whine of blasphemous
flutes from inconceivable, unlighted chambers beyond Time; the
detestable pounding and piping whereunto dance slowly, awkwardly, and
absurdly the gigantic tenebrous ultimate gods --the blind, voiceless,
mindless gargoyles whose soul is Nyarlathotep. (Lovecraft)

Re: guile-json, SRIFs and licenses

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]


John Cowan <cowan@ccil.org> writes:

> On Wed, Nov 6, 2019 at 9:56 AM Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
> wrote:
>> I think in this case, it might be a good idea to make sure, that
>> guile-json runs on all Schemes implementing a standard level and keep it
>> free software, to avoid the problem of people grabbing it and making it
>> proprietary software.

I’d like to give my own reason for accepting the MIT for wisp. My reason
is simply that SRFIs are supposed to be a standard.

Scheme SRFIs are a distributed effort to create a better programming
experience for those who use Scheme. There is a lot of choice, and if
all Schemes go off into different directions, you as developer lose
mobility between Schemes, and this often benefits the proprietary
systems that can pay more people to work on the shiny you need.

Therefore it is a viable decision to give an implementation away —
though not the only one.

> Lots of people who are quite committed to free and open source software
> don't actually think that's a problem.  There are two traditional arguments
> in favor of putting libraries under the GPL:
>
> 1) "Block embrace, extend, and extinguish":  the proprietary version gets
> all the new and sexy features while the original FLOSS version languishes.
> I don't think this is much of a problem for an implementation controlled by
> a stable specification like a SRFI: new features will be non-conforming
> features.
>
> 2) "Benefit GPLed programs":  if a library is GPLed, it supposedly gives
> the advantages of using that library only to GPLed applications.  That was
> the explicit reason for making readline a GPL library, and it did make
> CLISP GPL-licensed; similarly with the Objective-C front end to gcc.   I
> think history shows that this doesn't work very well in the long run:
> rather than accepting the GPL, a lot of duplicative effort was put into
> libedit/editline, which provides the same user-visible functions (but no
> longer has a readline-compatible interface).

You could also say that the GPL-licensing of readline is a huge success
story because it provided an edge to Free Software over proprietary
software for decades.

GCC did not mainly lose its edge for technical reasons, but because
Apple poured money into LLVM to have a compiler they can proprietarize.

> One of the purposes of FLOSS is to try to *prevent* duplicated effort.

I disagree with that point. The purpose of FLOSS is to have the option
to avoid proprietary software.

To that end every bit of additional effort required to create comparable
proprietary software is a good thing.

However for the SRFI this would also mean that running free software
which uses the SRFI on another Scheme implementation would require
additional work, so the edge to Free Software would be far smaller and
the cost might outweight the benefits. Might.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: guile-json, SRIFs and licenses

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> [...]  There are two traditional arguments
> in favor of putting libraries under the GPL:

[...]

> 2) "Benefit GPLed programs":  if a library is GPLed, it supposedly gives
> the advantages of using that library only to GPLed applications.

You're mistaken.  A GPLed library can be used by any program covered by
a *GPL-compatible* license.

> I think history shows that this doesn't work very well in the long run:
> rather than accepting the GPL, a lot of duplicative effort was put into
> libedit/editline,

It's a mistake to conclude from this that it didn't work well.  Avoiding
duplicative effort is _not_ a core goal of the Free Software Movement.

A vastly more important goal is that free software should exist for all
of the jobs that people want to use their computers for, so that users
need not sacrifice their freedom to do their computing.  The GNU GPL has
helped *enormously* with that goal.  For example, we gained our first
free C++ compiler thanks to the GNU GPL, because they built it on GCC.
Ditto for Objective C, and CLISP.

Those are major historical examples, but the same thing happens quite
frequently and unremarked in smaller examples, whenever a boss would
reflexively tell an employee that a program they wrote should be kept
proprietary, but is compelled to make it free software because it
depends on a copylefted library (such a Guile-JSON).

See <https://www.gnu.org/philosophy/pragmatic.html> for more on this.

Providing an inducement to others make more software into free software
is in fact the main goal of the GNU GPL, and you didn't even include it
in your list of "traditional arguments in favor of putting libraries
under the GPL".

> Whether or not a GPLed JSON library requires the Scheme implementation
> to be itself GPL depends on the implementation, but certainly a
> stand-alone *application* that uses it would have to be.

Again, you are mistaken.  Check your facts, please.  See
<https://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible>.

      Thanks,
        Mark

Re: guile-json, SRIFs and licenses

[John Cowan]

On Sat, Nov 9, 2019 at 8:29 AM Mark H Weaver <mhw@netris.org> wrote:


> You're mistaken.  A GPLed library can be used by any program covered by
> a *GPL-compatible* license.
>

At the cost of making the resulting work as a whole under the GPL.


> Those are major historical examples, but the same thing happens quite
> frequently and unremarked in smaller examples, whenever a boss would
> reflexively tell an employee that a program they wrote should be kept
> proprietary, but is compelled to make it free software because it
> depends on a copylefted library (such a Guile-JSON).
>

Well, I suppose that happens; certainly it has happened in the past, as
your examples show.  However, all the bosses I have worked for in the last
few decades (and I've made my living for forty years as most programmers
do, by writing proprietary software), simply say "No GPLed components,
ever.  If he has to pay for me or another to write the components
ourselves, he'd much rather do that than the alternative.

My present employer takes a slightly more enlightened view.  Employes are
free to contribute to existing open-source projects on whatever terms.
Like most, we use GPLed programs in proprietary shell scripts, which the
FSF allows, and I wrote and GPLed a wrapper around an existing GPLv3
library to transform it into a server (our code opens a raw TCP connection,
writes data, reads the results back).  That repo is not yet publicly
available, but it will be made so when the release that uses it is
distributed to our customers.

> Whether or not a GPLed JSON library requires the Scheme implementation
> > to be itself GPL depends on the implementation, but certainly a
> > stand-alone *application* that uses it would have to be.
>
> Again, you are mistaken.  Check your facts, please.  See
> <https://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible>.
>

That page defines GPL-compatibility thus:  "[If] the other license and the
GNU GPL are compatible, you can combine code released under the other
license with code released under the GNU GPL in one larger program.  All
GNU GPL versions permit such combinations privately; they also permit
distribution of such combinations provided the combination is released
under the same GNU GPL version."

Thus if the JSON library is combined into the Scheme implementation as part
of it, and that implementation is released, it must be released under the
GPL.  If a stand-alone application (as opposed to a mere script that
invokes the implementation) written in Scheme makes use of a GPLed library,
it too (if publicly distributed) must be GPLed.  That's what I said

As for clang, Apple funded it for commercial reasons, but there were
efforts among BSD developers to write their own C compiler for years before
that, though they came to nothing.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!    --Duck Soup

Re: guile-json, SRIFs and licenses

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]


John Cowan <cowan@ccil.org> writes:

>> Whether or not a GPLed JSON library requires the Scheme implementation
>> > to be itself GPL depends on the implementation, but certainly a
>> > stand-alone *application* that uses it would have to be.
>>
>> Again, you are mistaken.  Check your facts, please.  See
>> <https://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible>.
…
> Thus if the JSON library is combined into the Scheme implementation as part
> of it, and that implementation is released, it must be released under the
> GPL.  If a stand-alone application (as opposed to a mere script that
> invokes the implementation) written in Scheme makes use of a GPLed library,
> it too (if publicly distributed) must be GPLed.  That's what I said

The precise statment would be: If you use a GPL’ed library, you must
license your own code under a GPL-compatible license and release the
application as a whole under the GPL.

I’m often in that bind at work myself. If I’d just like to use a lib,
but it’s GPL licensed. I hope that some day our product management/sales
will release under free licenses.

> As for clang, Apple funded it for commercial reasons, but there were
> efforts among BSD developers to write their own C compiler for years before
> that, though they came to nothing.

There is lots of history for GPL-criticism by BSD developers. I don’t
agree with their reasoning.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: guile-user Digest, Vol 204, Issue 2

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> +1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
> implementation....

Zelphir could propose a SRFI for the API only, with no reference
implementation.  The existing implementation could remain copylefted.

       Mark

Re: guile-user Digest, Vol 204, Issue 2

[John Cowan]

Unfortunately not.  A SRFI must have a sample implementation to get
finalized (otherwise it is feared there would be too many WIBNI SRFIs).
The implementation doesn't have to be portable, but it has to have the
correct license.

On Fri, Nov 8, 2019 at 11:43 AM Mark H Weaver <mhw@netris.org> wrote:

> John Cowan <cowan@ccil.org> writes:
>
> > +1.  If only it weren't GPL3, which makes it ineligible to be a SRFI
> > implementation....
>
> Zelphir could propose a SRFI for the API only, with no reference
> implementation.  The existing implementation could remain copylefted.
>
>        Mark
>

Re: guile-user Digest, Vol 204, Issue 2

[Mark H Weaver]

I wrote:
> Zelphir could propose a SRFI for the API only, with no reference
> implementation.  The existing implementation could remain copylefted.

John Cowan <cowan@ccil.org> replied:
> Unfortunately not.  A SRFI must have a sample implementation to get
> finalized (otherwise it is feared there would be too many WIBNI SRFIs).
> The implementation doesn't have to be portable, but it has to have the
> correct license.

That's unfortunate.  I stand corrected.

Nonetheless, I find it regrettable that you've chosen to pressure a
library author on a GNU project forum to abandon copyleft licensing.
Personally, I don't think that SRFIs are important enough to justify
bowing to such pressure.  Guile-JSON's association with Guile and Guix
is enough for it to gain wide adoption, whether it is a SRFI or not.
That said, it is of course Aleix's decision how to license his library.

      Thanks,
        Mark

Re: guile-user Digest, Vol 204, Issue 2

[John Cowan]

Distinguo.  I have not *pressured* the author to dual license; that is, I
have not exercised force or undue influence (of which I have none).  I have
*asked* them to do so and presented arguments in favor of it.   A fortiori,
I am not asking them to bow to me, but to act if they agree with my
reasoning.  Please retract the word "pressure".

In addition, I did not know (though I certainly should have checked) that
the guile-json copyright has remained with the author rather than being
assigned to the FSF.  I will communicate directly with the author.

On Fri, Nov 8, 2019 at 1:19 PM Mark H Weaver <mhw@netris.org> wrote:

> I wrote:
> > Zelphir could propose a SRFI for the API only, with no reference
> > implementation.  The existing implementation could remain copylefted.
>
> John Cowan <cowan@ccil.org> replied:
> > Unfortunately not.  A SRFI must have a sample implementation to get
> > finalized (otherwise it is feared there would be too many WIBNI SRFIs).
> > The implementation doesn't have to be portable, but it has to have the
> > correct license.
>
> That's unfortunate.  I stand corrected.
>
> Nonetheless, I find it regrettable that you've chosen to pressure a
> library author on a GNU project forum to abandon copyleft licensing.
> Personally, I don't think that SRFIs are important enough to justify
> bowing to such pressure.  Guile-JSON's association with Guile and Guix
> is enough for it to gain wide adoption, whether it is a SRFI or not.
> That said, it is of course Aleix's decision how to license his library.
>
>       Thanks,
>         Mark
>

Re: guile-user Digest, Vol 204, Issue 2

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> Distinguo.  I have not *pressured* the author to dual license; that is, I
> have not exercised force or undue influence (of which I have none).

According to <https://en.wiktionary.org/wiki/pressure#Verb>, "pressure"
means: "To encourage or heavily exert force or influence", and according
to <https://en.wiktionary.org/wiki/encourage#Verb>, "encourage" means
(among other senses) "To spur on, strongly recommend."

As an example use of the word "pressure", wiktionary offers this:

  Do not let anyone pressure you into buying something you do not want.

For another source, according to
<https://dictionary.cambridge.org/us/dictionary/english/pressure>:

  "If you put pressure on someone, you try to cause that person to do
  something by persuading or threatening them"

Here, I used the word "pressure" in the sense of to "persuade" or to
"spur on, strongly recommend."

Therefore, I think I used the word correctly here.

      Thanks,
        Mark

Re: guile-user Digest, Vol 204, Issue 2

[Aleix Conchillo Flaqué]

On Fri, Nov 8, 2019 at 10:19 AM Mark H Weaver <mhw@netris.org> wrote:

> I wrote:
> > Zelphir could propose a SRFI for the API only, with no reference
> > implementation.  The existing implementation could remain copylefted.
>
> John Cowan <cowan@ccil.org> replied:
> > Unfortunately not.  A SRFI must have a sample implementation to get
> > finalized (otherwise it is feared there would be too many WIBNI SRFIs).
> > The implementation doesn't have to be portable, but it has to have the
> > correct license.
>
> That's unfortunate.  I stand corrected.
>
> Nonetheless, I find it regrettable that you've chosen to pressure a
> library author on a GNU project forum to abandon copyleft licensing.
> Personally, I don't think that SRFIs are important enough to justify
> bowing to such pressure.  Guile-JSON's association with Guile and Guix
> is enough for it to gain wide adoption, whether it is a SRFI or not.
> That said, it is of course Aleix's decision how to license his library.
>
>
Don't worry Mark. I don't feel any pressure at all.

Until now it hadn't even occurred to me that guile-json could become an
SRFI. Regarding the license, I have been happy with GPL3 so far. Since my
main focus is on Guile (as a hobby) I'm also happy and humbled that
projects like Guix, GnuCash and others use it.

I would of course be a bit sad if a new SRFI implementation shows up and
people start replacing guile-json with it, so that's something for me to
consider. If at some point I decide to switch to the MIT license I assume
the projects that currently use guile-json would still be able to use it
(probably renamed to some SRFI number) the same way they use other SRFIs,
right? Of course they would need to be ported, which would probably be a
bit painful if the SRFI API diverges too much from guile-json.

I'm also surprised there hasn't been any other Scheme implementations that
hasn't made an SRFI for JSON, I'm sure all of them have their own
implementations. May be SRFIs are not a huge priority? May be they should
be? I don't have an answer for that.

So, for now, I think I will keep things as is unless the Guile community
and guile-json users tell me to switch or do something different.

Best,

Aleix

Re: guile-user Digest, Vol 204, Issue 2

[Mark H Weaver]

Hi Aleix,

Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote:
> If at some point I decide to switch to the MIT license I assume
> the projects that currently use guile-json would still be able to use it
> (probably renamed to some SRFI number) the same way they use other SRFIs,
> right?

Yes, as long as it's GPL-compatible.  The X11 and Expat licenses are
both GPL-compatible.  The ambiguous term "MIT license" usually refers to
one of those two licenses.

      Mark

Re: guile-user Digest, Vol 204, Issue 2

[John Cowan]

The specific wording can be found at point 9 of <
https://srfi.schemers.org/srfi-process.html>.

On Fri, Nov 8, 2019 at 2:34 PM Mark H Weaver <mhw@netris.org> wrote:

> Hi Aleix,
>
> Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote:
> > If at some point I decide to switch to the MIT license I assume
> > the projects that currently use guile-json would still be able to use it
> > (probably renamed to some SRFI number) the same way they use other SRFIs,
> > right?
>
> Yes, as long as it's GPL-compatible.  The X11 and Expat licenses are
> both GPL-compatible.  The ambiguous term "MIT license" usually refers to
> one of those two licenses.
>
>       Mark
>

Re: guile-user Digest, Vol 204, Issue 2

[John Cowan]

On Fri, Nov 8, 2019 at 1:52 PM Aleix Conchillo Flaqué <aconchillo@gmail.com>
wrote:

If at some point I decide to switch to the MIT license
>

Dual licensing is also a possibility, so that users who prefer the GPLv3
license would still have it.


> I assume the projects that currently use guile-json would still be able to
> use it (probably renamed to some SRFI number)
>

In R6RS and R7RS systems, the same library can appear under two different
names very easily.


> Of course they would need to be ported, which would probably be a bit
> painful if the SRFI API diverges too much from guile-json.
>

One thing that attracted me to guile-json is that it provides both a parser
and a printer, and has very few dependencies and those are of a portable
sort.  Furthermore, its internal representation of JSON does not have any
corner cases except using #nil (which is not portable off Guile) instead of
'null, something that is trivially changeable.


> I'm also surprised there hasn't been any other Scheme implementations that
> hasn't made an SRFI for JSON, I'm sure all of them have their own
> implementations. May be SRFIs are not a huge priority?
>

It's not surprising that most Scheme implementers are considered with their
Scheme rather than all of Scheme.  Improving the state of the art for all
of Scheme, however, is my particular task.  As such, I will beg or borrow
(but not steal) whatever I can.


> So, for now, I think I will keep things as is unless the Guile community
> and guile-json users tell me to switch or do something different.
>

Understood.  You can disregard the issue that I filed at Github.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
With techies, I've generally found
If your arguments lose the first round
Make it rhyme, make it scan / Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

Re: guile-user Digest, Vol 204, Issue 2

[Mark H Weaver]

John Cowan <cowan@ccil.org> wrote:
> Dual licensing is also a possibility, so that users who prefer the GPLv3
> license would still have it.

Dual licensing with a lax license option would eliminate the main
advantage of copyleft, namely that it offers an inducement to those who
wish to use Guile-JSON to release their code as free software.

See <https://www.gnu.org/philosophy/pragmatic.html> for more.

     Thanks,
       Mark

Re: guile-user Digest, Vol 204, Issue 2

[Greg Coladonato]

Aleix, I tried to follow the link at
https://github.com/aconchillo/guile-json to download your tar file at
http://download.savannah.gnu.org/releases/guile-json/guile-json-3.3.0.tar.gz,
but that URL redirects to "bigsearcher.com". Are others able to download
the tar file from that savannah URL?

Greg

On Tue, Nov 5, 2019 at 9:04 AM <guile-user-request@gnu.org> wrote:

> Send guile-user mailing list submissions to
>         guile-user@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/guile-user
> or, via email, send a message with subject or body 'help' to
>         guile-user-request@gnu.org
>
> You can reach the person managing the list at
>         guile-user-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of guile-user digest..."
>
>
> Today's Topics:
>
>    1. [ANN] guile-json 3.3.0 released (Aleix Conchillo Flaqué)
>    2. Re: [ANN] guile-json 3.3.0 released (John Cowan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 4 Nov 2019 22:28:12 -0800
> From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
> To: guile-user <guile-user@gnu.org>
> Subject: [ANN] guile-json 3.3.0 released
> Message-ID:
>         <
> CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I'm pleased to announce guile-json 3.3.0. This new version comes with a few
> improvements: guile-json will now throw an exception if the native scheme
> value used to build a JSON document is invalid (this is done before
> printing any JSON). Also, an additional key argument #:validate can be
> given to ignore the validation in the case performance is important and the
> data is known to be valid. Empty JSON array slots are also considered
> invalid, before they were generating an invalid scheme representation. A
> few more details can be found on the NEWS file.
>
> https://github.com/aconchillo/guile-json
>
> Best,
>
> Aleix
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Nov 2019 09:32:27 -0500
> From: John Cowan <cowan@ccil.org>
> To: Aleix Conchillo Flaqué <aconchillo@gmail.com>
> Cc: guile-user <guile-user@gnu.org>
> Subject: Re: [ANN] guile-json 3.3.0 released
> Message-ID:
>         <
> CAD2gp_QbbQ8YfBf_cSxLr2iHyZtKdcbhqtPafOJ+W0_NQKgfkA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Thanks, this is great!  I'm curious though why you didn't take up my
> suggestion of using 'null rather than #nil, given the points I raised at <
> https://github.com/aconchillo/guile-json/issues/31>.
>
> On Tue, Nov 5, 2019 at 1:28 AM Aleix Conchillo Flaqué <
> aconchillo@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm pleased to announce guile-json 3.3.0. This new version comes with a
> few
> > improvements: guile-json will now throw an exception if the native scheme
> > value used to build a JSON document is invalid (this is done before
> > printing any JSON). Also, an additional key argument #:validate can be
> > given to ignore the validation in the case performance is important and
> the
> > data is known to be valid. Empty JSON array slots are also considered
> > invalid, before they were generating an invalid scheme representation. A
> > few more details can be found on the NEWS file.
> >
> > https://github.com/aconchillo/guile-json
> >
> > Best,
> >
> > Aleix
> >
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> guile-user mailing list
> guile-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/guile-user
>
>
> ------------------------------
>
> End of guile-user Digest, Vol 204, Issue 2
> ******************************************
>


-- 
Sent from my Palm Pilot

Re: guile-user Digest, Vol 204, Issue 2

[Zelphir Kaltstahl]

I also cannot download that tarball and on:
https://bigsearcher.com/mirrors/nongnu/guile-json/ it does not exist.

(http://download.savannah.gnu.org/releases/guile-json redirects to
https://bigsearcher.com/mirrors/nongnu/guile-json/)

On Github one can download it.

On 11/6/19 7:12 AM, Greg Coladonato wrote:
> Aleix, I tried to follow the link at
> https://github.com/aconchillo/guile-json to download your tar file at
> http://download.savannah.gnu.org/releases/guile-json/guile-json-3.3.0.tar.gz,
> but that URL redirects to "bigsearcher.com". Are others able to download
> the tar file from that savannah URL?
>
> Greg
>
> On Tue, Nov 5, 2019 at 9:04 AM <guile-user-request@gnu.org> wrote:
>
>> Send guile-user mailing list submissions to
>>         guile-user@gnu.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.gnu.org/mailman/listinfo/guile-user
>> or, via email, send a message with subject or body 'help' to
>>         guile-user-request@gnu.org
>>
>> You can reach the person managing the list at
>>         guile-user-owner@gnu.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of guile-user digest..."
>>
>>
>> Today's Topics:
>>
>>    1. [ANN] guile-json 3.3.0 released (Aleix Conchillo Flaqué)
>>    2. Re: [ANN] guile-json 3.3.0 released (John Cowan)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 4 Nov 2019 22:28:12 -0800
>> From: Aleix Conchillo Flaqué <aconchillo@gmail.com>
>> To: guile-user <guile-user@gnu.org>
>> Subject: [ANN] guile-json 3.3.0 released
>> Message-ID:
>>         <
>> CA+XASoUHWAqaPqVPQQg5sUErMoe9pKYdfm57ng679PgsY5Eq9Q@mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Hi,
>>
>> I'm pleased to announce guile-json 3.3.0. This new version comes with a few
>> improvements: guile-json will now throw an exception if the native scheme
>> value used to build a JSON document is invalid (this is done before
>> printing any JSON). Also, an additional key argument #:validate can be
>> given to ignore the validation in the case performance is important and the
>> data is known to be valid. Empty JSON array slots are also considered
>> invalid, before they were generating an invalid scheme representation. A
>> few more details can be found on the NEWS file.
>>
>> https://github.com/aconchillo/guile-json
>>
>> Best,
>>
>> Aleix
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 Nov 2019 09:32:27 -0500
>> From: John Cowan <cowan@ccil.org>
>> To: Aleix Conchillo Flaqué <aconchillo@gmail.com>
>> Cc: guile-user <guile-user@gnu.org>
>> Subject: Re: [ANN] guile-json 3.3.0 released
>> Message-ID:
>>         <
>> CAD2gp_QbbQ8YfBf_cSxLr2iHyZtKdcbhqtPafOJ+W0_NQKgfkA@mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Thanks, this is great!  I'm curious though why you didn't take up my
>> suggestion of using 'null rather than #nil, given the points I raised at <
>> https://github.com/aconchillo/guile-json/issues/31>.
>>
>> On Tue, Nov 5, 2019 at 1:28 AM Aleix Conchillo Flaqué <
>> aconchillo@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm pleased to announce guile-json 3.3.0. This new version comes with a
>> few
>>> improvements: guile-json will now throw an exception if the native scheme
>>> value used to build a JSON document is invalid (this is done before
>>> printing any JSON). Also, an additional key argument #:validate can be
>>> given to ignore the validation in the case performance is important and
>> the
>>> data is known to be valid. Empty JSON array slots are also considered
>>> invalid, before they were generating an invalid scheme representation. A
>>> few more details can be found on the NEWS file.
>>>
>>> https://github.com/aconchillo/guile-json
>>>
>>> Best,
>>>
>>> Aleix
>>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> guile-user mailing list
>> guile-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/guile-user
>>
>>
>> ------------------------------
>>
>> End of guile-user Digest, Vol 204, Issue 2
>> ******************************************
>>
>

Re: guile-user Digest, Vol 204, Issue 2

[Greg Coladonato]

Thank you Aleix, that one worked

On Wed, Nov 6, 2019 at 12:13 AM Aleix Conchillo Flaqué <aconchillo@gmail.com>
wrote:

> Weird. Savannah has a set of mirrors, may be the one you hit is no longer
> valid. Try this one:
> http://nongnu.askapache.com/guile-json/guile-json-3.3.0.tar.gz
>
> On Tue, Nov 5, 2019 at 10:12 PM Greg Coladonato <gcoladon@gmail.com>
> wrote:
>
>> Aleix, I tried to follow the link at
>> https://github.com/aconchillo/guile-json to download your tar file at
>> http://download.savannah.gnu.org/releases/guile-json/guile-json-3.3.0.tar.gz,
>> but that URL redirects to "bigsearcher.com". Are others able to download
>> the tar file from that savannah URL?
>>
>