unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Arne Babenhauserheide <arne_bab@web.de>
To: guile-user@gnu.org
Subject: Re: guile-json, SRIFs and licenses
Date: Wed, 06 Nov 2019 21:04:17 +0100	[thread overview]
Message-ID: <87o8xoai0u.fsf@web.de> (raw)
In-Reply-To: <CAD2gp_TKw+ENEjZJ+-=dfmPty2+NMQcZRz+wchw4yX=m2b_RCw@mail.gmail.com>

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

  reply	other threads:[~2019-11-06 20:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.69.1572973210.27743.guile-user@gnu.org>
2019-11-06  0:02 ` guile-user Digest, Vol 204, Issue 2 Zelphir Kaltstahl
2019-11-06  0:28   ` John Cowan
2019-11-06  8:19     ` guile-json, SRIFs and licenses Zelphir Kaltstahl
2019-11-06 14:36       ` John Cowan
2019-11-06 14:56         ` Zelphir Kaltstahl
2019-11-06 15:38           ` John Cowan
2019-11-06 20:04             ` Arne Babenhauserheide [this message]
2019-11-09 13:28             ` Mark H Weaver
2019-11-09 18:53               ` John Cowan
2019-11-10 14:26                 ` Arne Babenhauserheide
2019-11-08 16:42     ` guile-user Digest, Vol 204, Issue 2 Mark H Weaver
2019-11-08 17:54       ` John Cowan
2019-11-08 18:18         ` Mark H Weaver
2019-11-08 18:52           ` John Cowan
2019-11-08 19:47             ` Mark H Weaver
2019-11-08 18:52           ` Aleix Conchillo Flaqué
2019-11-08 19:33             ` Mark H Weaver
2019-11-08 19:37               ` John Cowan
2019-11-08 19:33             ` John Cowan
2019-11-08 20:03               ` Mark H Weaver
2019-11-06  6:12 ` Greg Coladonato
2019-11-06 11:18   ` Zelphir Kaltstahl
     [not found]   ` <CA+XASoWs-_SiG9+ubSvuWq-YRVQHdwhPTaJ0HdRR=nN4eMb-ng@mail.gmail.com>
2019-11-06 14:16     ` Greg Coladonato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8xoai0u.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).