Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Relicensing to MIT? #453

Open
29 of 35 tasks
davazp opened this issue Sep 21, 2022 · 50 comments
Open
29 of 35 tasks

Relicensing to MIT? #453

davazp opened this issue Sep 21, 2022 · 50 comments

Comments

@davazp
Copy link
Member

davazp commented Sep 21, 2022 •
edited
Loading

We are considering changing the license of JSCL from GPL3 to MIT.

To do so, we need contributors of significant parts of JSCL to agree.

If you are in this list, please comment in this thread telling us if you agree or not.

I apology for the ping if you are not interested.

Some contributions are small enough that we won't need permission. Below follows the contributions by author according to
git-quick-stats.

Even if you aren't a contributor, you can react with +1 or -1 to this issue to express your thoughts on the change.

Approve

Does NOT approve

Unknown

        Andrea Griffini <agriff@tin.it>:
          insertions:    718    (0%)
          deletions:     259    (0%)
          files:         33     (1%)
          commits:       18     (1%)
          lines changed: 977    (0%)
          first commit:  Tue Apr 30 08:54:21 2013 +0200
          last commit:   Mon May 6 08:56:18 2013 +0200

         Spenser Truex <spensertruexonline@gmail.com>:
          insertions:    1      (0%)
          deletions:     1      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 2      (0%)
          first commit:  Mon Jul 16 10:23:11 2018 -0700
          last commit:   Mon Jul 16 10:23:11 2018 -0700

         Robert Smith <quad@symbo1ics.com>:
          insertions:    2      (0%)
          deletions:     1      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 3      (0%)
          first commit:  Sat Apr 27 15:20:54 2013 -0700
          last commit:   Sat Apr 27 15:20:54 2013 -0700

         Nikodemus Siivola <nikodemus@random-state.net>:
          insertions:    74     (0%)
          deletions:     13     (0%)
          files:         9      (0%)
          commits:       7      (0%)
          lines changed: 87     (0%)
          first commit:  Sun Apr 28 16:37:03 2013 +0300
          last commit:   Sun Apr 28 16:41:48 2013 +0300

         vlad-km <gm5461@gmail.com>:
          insertions:    14270  (6%)
          deletions:     1847   (1%)
          files:         327    (13%)
          commits:       253    (15%)
          lines changed: 16117  (4%)
          first commit:  Sun Feb 11 16:30:41 2018 +0300
          last commit:   Sat Sep 10 15:38:24 2022 +0300

         Bill St. Clair <billstclair@gmail.com>:
          insertions:    4      (0%)
          deletions:     7      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 11     (0%)
          first commit:  Mon Jul 14 16:05:20 2014 -0400
          last commit:   Mon Jul 14 16:05:20 2014 -0400

         cxxxr <g23tlm@gmail.com>:
          insertions:    141    (0%)
          deletions:     83     (0%)
          files:         16     (1%)
          commits:       10     (1%)
          lines changed: 224    (0%)
          first commit:  Mon Aug 28 08:27:56 2017 +0900
          last commit:   Sun Oct 14 11:54:30 2018 +0900

         Samuel Chase <samebchase@gmail.com>:
          insertions:    49     (0%)
          deletions:     20     (0%)
          files:         15     (1%)
          commits:       9      (1%)
          lines changed: 69     (0%)
          first commit:  Mon May 13 00:55:30 2013 +0530
          last commit:   Thu May 16 22:18:59 2013 +0530

         chuchana <chuchana@gmx.de>:
          insertions:    1      (0%)
          deletions:     1      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 2      (0%)
          first commit:  Wed May 11 14:47:45 2016 +0200
          last commit:   Wed May 11 14:47:45 2016 +0200

         Fernando Borretti <eudoxiahp@gmail.com>:
          insertions:    83     (0%)
          deletions:     70     (0%)
          files:         3      (0%)
          commits:       3      (0%)
          lines changed: 153    (0%)
          first commit:  Fri Apr 17 19:03:02 2015 -0300
          last commit:   Sun Apr 19 12:54:25 2015 -0300

         Henry Irvine <henryirvine@mac.com>:
          insertions:    7      (0%)
          deletions:     1      (0%)
          files:         2      (0%)
          commits:       1      (0%)
          lines changed: 8      (0%)
          first commit:  Mon May 6 01:55:59 2013 +0900
          last commit:   Mon May 6 01:55:59 2013 +0900

         Yoteichi <plonk@piano.email.ne.jp>:
          insertions:    4      (0%)
          deletions:     4      (0%)
          files:         2      (0%)
          commits:       2      (0%)
          lines changed: 8      (0%)
          first commit:  Wed Jan 2 05:07:38 2019 +0900
          last commit:   Wed Jan 2 05:38:13 2019 +0900

         Olof-Joachim Frahm <olof@macrolet.net>:
          insertions:    486    (0%)
          deletions:     85     (0%)
          files:         50     (2%)
          commits:       42     (2%)
          lines changed: 571    (0%)
          first commit:  Sat May 18 00:38:58 2013 +0200
          last commit:   Tue Oct 15 22:41:56 2013 +0200

         Michael Grünewald <michipili@gmail.com>:
          insertions:    216    (0%)
          deletions:     25     (0%)
          files:         7      (0%)
          commits:       7      (0%)
          lines changed: 241    (0%)
          first commit:  Wed Oct 4 23:22:51 2017 +0200
          last commit:   Sat Nov 18 12:44:35 2017 +0100

         David Vázquez <davazp@gmail.com>:
          insertions:    204789 (88%)
          deletions:     194779 (95%)
          files:         1616   (65%)
          commits:       1097   (65%)
          lines changed: 399568 (91%)
          first commit:  Fri Dec 14 01:18:26 2012 +0000
          last commit:   Wed Sep 21 08:07:44 2022 +0200

         Helmut Kian <helmutkian@localhost.localdomain>:
          insertions:    206    (0%)
          deletions:     29     (0%)
          files:         5      (0%)
          commits:       3      (0%)
          lines changed: 235    (0%)
          first commit:  Tue Jun 16 12:19:12 2015 -0700
          last commit:   Wed Jun 17 10:57:53 2015 -0700

         Mihai Bazon <mihai.bazon@gmail.com>:
          insertions:    2012   (1%)
          deletions:     2008   (1%)
          files:         3      (0%)
          commits:       2      (0%)
          lines changed: 4020   (1%)
          first commit:  Sat Jan 5 11:56:28 2013 +0200
          last commit:   Sat Oct 21 16:09:15 2017 +0300

         Ken Harris <kengruven@gmail.com>:
          insertions:    2080   (1%)
          deletions:     592    (0%)
          files:         51     (2%)
          commits:       25     (1%)
          lines changed: 2672   (1%)
          first commit:  Sat May 4 23:32:00 2013 -0700
          last commit:   Wed Jun 19 11:44:44 2013 -0700

         pnathan <pnathan@vandals.uidaho.edu>:
          insertions:    113    (0%)
          deletions:     32     (0%)
          files:         12     (0%)
          commits:       7      (0%)
          lines changed: 145    (0%)
          first commit:  Tue May 7 22:31:42 2013 -0700
          last commit:   Sun Feb 16 23:16:05 2014 -0800

         Brit Butler <redline6561@gmail.com>:
          insertions:    8      (0%)
          deletions:     3      (0%)
          files:         3      (0%)
          commits:       1      (0%)
          lines changed: 11     (0%)
          first commit:  Thu May 9 09:44:40 2013 -0400
          last commit:   Thu May 9 09:44:40 2013 -0400

         Daniel Nagy <danielnagy@posteo.de>:
          insertions:    179    (0%)
          deletions:     37     (0%)
          files:         30     (1%)
          commits:       9      (1%)
          lines changed: 216    (0%)
          first commit:  Wed Sep 29 13:30:30 2021 +0200
          last commit:   Mon Aug 22 23:11:42 2022 +0200

         maxwellhansen <maxwellhansen@hotmail.com>:
          insertions:    3      (0%)
          deletions:     9      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 12     (0%)
          first commit:  Thu Apr 25 22:37:09 2013 -0700
          last commit:   Thu Apr 25 22:37:09 2013 -0700

         Bruce-Robert Fenn Pocock <brfennpocock@star-hope.org>:
          insertions:    224    (0%)
          deletions:     189    (0%)
          files:         11     (0%)
          commits:       10     (1%)
          lines changed: 413    (0%)
          first commit:  Sat Jul 30 01:52:10 2016 -0400
          last commit:   Fri Aug 12 16:13:01 2016 -0400

         Kasper Gałkowski <kpg@posteo.net>:
          insertions:    31     (0%)
          deletions:     0      (0%)
          files:         2      (0%)
          commits:       1      (0%)
          lines changed: 31     (0%)
          first commit:  Mon Mar 28 16:59:46 2022 +0200
          last commit:   Mon Mar 28 16:59:46 2022 +0200

         Alejandro Zamora Fonseca <allejjandrozf@gmail.com>:
          insertions:    13     (0%)
          deletions:     0      (0%)
          files:         2      (0%)
          commits:       1      (0%)
          lines changed: 13     (0%)
          first commit:  Mon Jun 19 05:21:20 2017 -0300
          last commit:   Mon Jun 19 05:21:20 2017 -0300

         jnjcc <jnjcc@live.com>:
          insertions:    45     (0%)
          deletions:     24     (0%)
          files:         7      (0%)
          commits:       6      (0%)
          lines changed: 69     (0%)
          first commit:  Sun Jul 6 16:28:55 2014 +1200
          last commit:   Thu Jul 31 20:17:33 2014 +1200

         Diogo Franco <diogoalexfranco@gmail.com>:
          insertions:    90     (0%)
          deletions:     10     (0%)
          files:         12     (0%)
          commits:       9      (1%)
          lines changed: 100    (0%)
          first commit:  Tue Apr 5 00:40:54 2016 +0100
          last commit:   Mon Apr 11 12:26:29 2016 +0100

         Raimon Grau <raimonster@gmail.com>:
          insertions:    4774   (2%)
          deletions:     4509   (2%)
          files:         41     (2%)
          commits:       32     (2%)
          lines changed: 9283   (2%)
          first commit:  Tue Dec 11 23:56:15 2012 +0100
          last commit:   Thu May 2 21:39:35 2013 +0200

         ErmineII <65429969+ErmineII@users.noreply.github.com>:
          insertions:    3      (0%)
          deletions:     0      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 3      (0%)
          first commit:  Thu Sep 17 18:55:30 2020 -0400
          last commit:   Thu Sep 17 18:55:30 2020 -0400

         rayslava <rayslava@gmail.com>:
          insertions:    91     (0%)
          deletions:     45     (0%)
          files:         8      (0%)
          commits:       7      (0%)
          lines changed: 136    (0%)
          first commit:  Sat Jan 19 18:45:11 2013 +0400
          last commit:   Tue Apr 21 19:23:54 2015 +0300

         Alfredo Beaumont <alfredo.beaumont@gmail.com>:
          insertions:    1151   (0%)
          deletions:     120    (0%)
          files:         52     (2%)
          commits:       35     (2%)
          lines changed: 1271   (0%)
          first commit:  Tue Apr 23 16:14:32 2013 +0200
          last commit:   Mon Jun 3 11:38:56 2013 +0200

         Vyacheslav Barinov <v.barinov@samsung.com>:
          insertions:    5      (0%)
          deletions:     5      (0%)
          files:         1      (0%)
          commits:       1      (0%)
          lines changed: 10     (0%)
          first commit:  Fri Aug 28 15:34:50 2015 +0300
          last commit:   Fri Aug 28 15:34:50 2015 +0300

         Owen Rodley <owen.rodley@gmail.com>:
          insertions:    967    (0%)
          deletions:     360    (0%)
          files:         114    (5%)
          commits:       64     (4%)
          lines changed: 1327   (0%)
          first commit:  Sat Apr 27 00:16:42 2013 +1200
          last commit:   Fri Jan 8 20:27:31 2016 +1100

         Javier Olaechea <pirata@gmail.com>:
          insertions:    298    (0%)
          deletions:     198    (0%)
          files:         34     (1%)
          commits:       26     (2%)
          lines changed: 496    (0%)
          first commit:  Mon Dec 21 15:48:19 2015 -0500
          last commit:   Mon Apr 11 03:21:26 2016 -0500

         Henry Steere <henry.steere@gmail.com>:
          insertions:    56     (0%)
          deletions:     41     (0%)
          files:         7      (0%)
          commits:       5      (0%)
          lines changed: 97     (0%)
          first commit:  Thu May 3 21:08:12 2018 +0200
          last commit:   Wed May 9 07:33:47 2018 +0200
@davazp davazp pinned this issue Sep 21, 2022
@nikodemus
Copy link
Contributor

nikodemus commented Sep 21, 2022 via email

@chuchana
Copy link
Contributor

I'm pretty sure you don't need my approval for the change, but just in case: you have it.

@rayslava
Copy link
Contributor

Okay, if you need an approval, I agree to the license change.

And v.barinov@samsung.com is also me, apparently I've performed commit from office without proper git config :)

@HenryS1
Copy link
Contributor

HenryS1 commented Sep 21, 2022

You have my approval if you need it.

@vlad-km
Copy link
Member

vlad-km commented Sep 21, 2022

I agree with changing to MIT-license

@mishoo
Copy link
Contributor

mishoo commented Sep 21, 2022

Agree.

@orodley
Copy link
Contributor

orodley commented Sep 21, 2022

Fine by me.

@nagy
Copy link
Contributor

nagy commented Sep 21, 2022

I consider my contributions in this project to be minuscule enough that I wont be holding anybody back, so consider my acceptance to be given.

But I also want to mention, that I think this is a bad idea. If a corporation can use this project to create profit, it should contribute something back to the project. A MIT license would allow a corporation to just take this project with nothing more than a mere mention.

If they disagree with the GPL3 because they vehemently do not want to release their source code, nothing prevents them from asking @davazp for an individual license.

So I think the GPL3 strengthens the interests of this project, where a MIT license would weaken it. But again, I agree to any outcome of this.

@Ferada
Copy link
Contributor

Ferada commented Sep 21, 2022

What @nagy said; I agree to the change though if the decision goes that way.

@davazp
Copy link
Member Author

davazp commented Sep 21, 2022

Just want to leave my (lack of) opinion here as well. I don't mind GPLv3 vs MIT, I agree with @nagy's argument, but I think it's unlikely to happen. And even if I don't think there is a reason to reject it because it's GPLv3 (you can make your app on it, just contribute changes to jscl itself), it seems many people feel that way.

However I have been asked a few timesthis already, so it that makes more people likely to use and contribute to the project, I welcome the change.

@rayslava
Copy link
Contributor

GPLv3 usage has one not-so-obvious consequence as well: it forbids tivoization explicitly, but this point leads to requirement of access to file system and this may become a blocker sometimes.

For example in our company we use GPLv2 code, we open all the source, and we upstream useful changes, but as for GPLv3 code, the license requires to allow filesystem access (e.g. to allow library replacement) and when we only have ROM with firmware we can't do that, so all the GPLv3-licensed code is just discarded unconditionally.

There were some cases when I'd be happy to work on open source projects during my paid hours, but GPLv3 prevented that. Not sure how common this situation is, though.

@abeaumont
Copy link
Contributor

Agree.

@billstclair
Copy link
Contributor

billstclair commented Sep 21, 2022 via email

@alejandrozf
Copy link
Contributor

Agree

@foretspaisibles
Copy link
Contributor

Agree and support the change!

@pnathan
Copy link
Contributor

pnathan commented Sep 21, 2022 via email

@kingcons
Copy link
Contributor

I agree. 👍

@stylewarning
Copy link
Contributor

+1

@6502
Copy link
Contributor

6502 commented Sep 21, 2022 via email

@PuercoPop
Copy link
Member

Similar to what others have said, I won't hold back the relicensing so I give my approval if it is deemed necessary but I disagree with the move away from copyleft licenses.

@eudoxia0
Copy link
Member

Approved.

@stylewarning
Copy link
Contributor

I'm totally OK with the change to MIT, but I'd love to know if there was a motivating factor, and whether the developers think it will encourage their own further development. 🙂

@samebchase
Copy link
Contributor

OK with the licensing change.

@davazp
Copy link
Member Author

davazp commented Sep 22, 2022

I'm totally OK with the change to MIT, but I'd love to know if there was a motivating factor, and whether the developers think it will encourage their own further development. 🙂

Good point. We're hearing lot of people 'not opposing' to it, but not if it'll make it easier for them to use. I'd love to hear that from others too!

This is the (latest) thread where the topic came up:
#441 (comment)

My opinion: I like copyleft but I think it doesn't fit a Lisp implementation well. I'd like people to feel comfortable that they can use it without making their work GPL too. By nature in Lisp, it's hard to state what is a 'improvement' to jscl vs just using it. (what if you do (defun cl:mapcar ...) in your application? I think the simplicity of MIT wins and it would solve that.

@kengruven
Copy link
Contributor

I already accepted a license change, a few years ago, for my contributions to JSCL — because I’d contributed to the "prelude" which would be included verbatim in the user's object code. (I had thought that the LGPL was created for basically just this purpose, and I don't know why it wasn't used here.)

Still, without more information, and as much as I can walk back my prior acceptance, I do not approve a license change away from the GNU GPL.

What's the driver behind this? Are there companies who wish to use Common Lisp on webpages, and want a license which is more corporate-friendly than user-freedom-preserving? While I recognize that this particular decision has virtually zero effect on the global software landscape, I don't think the world needs more software which can be used in proprietary software without giving anything back to the community.

Additionally, I've been around long enough to know that when someone says "I'd use/contribute to this, if only XYZ", in 99% of cases, even if you change XYZ, they're still not going to. It’s just an excuse. Nothing is ever gained by chasing drive-by suggestions.

As for whether the GPL "fits" Lisp: one of the first programs to ever use the GNU GPL was a Lisp (GNU Emacs), and it's still going strong today. I can't name any other 1980's software that I'm still using. Interestingly, GNU Emacs is also used extensively in the demo made by the person asking for this license change. This person is asking for JSCL to change its license on the grounds that "GPL is not freedom for programming tools ever" — while taking advantage of the freedoms offered by a GPL-licensed programming tool.

@vlad-km
Copy link
Member

vlad-km commented Sep 26, 2022 •
edited
Loading

Ken, thanks for the opinion of the one from persons who stood at the origins JSCL.

I already accepted a license change, a few years ago, for my contributions to JSCL — because I’d contributed to the "prelude" which would be included verbatim in the user's object code. (I had thought that the LGPL was created for basically just this purpose, and I don't know why it wasn't used here.)

My opinion: it is possible that in this case a separate license for this part of the code could be considered. I guess it will be fair.

In relation to unknown persons who want to change the license - I would look with great pleasure at the work of developers who would redesign the system for a proprietary product.

I think that language tools should be under a MIT license. But it's up to you - the authors of the system.

My opinion: licensing addons - at the discretion of their authors.

This text was written using EMACS, thanks to its author for this, and for the fact that there is no need to post the text of the license for this wonderful tool.

vbr,
@vlad-km

@vlad-km
Copy link
Member

vlad-km commented Sep 26, 2022

(what if you do (defun cl:mapcar ...)

In such a case there is a moderator and he has a button Close

Is not it?

@davazp
Copy link
Member Author

davazp commented Oct 6, 2022

Before we continue with the people missing, I think Ken Harris opposition is already quite significant, as he has contributed quite a lot and important code.

https://github.com/jscl-project/jscl/commits/master?author=kengruven

         Ken Harris <kengruven@gmail.com>:
          insertions:    2080   (1%)
          deletions:     592    (0%)
          files:         51     (2%)
          commits:       25     (1%)
          lines changed: 2672   (1%)
          first commit:  Sat May 4 23:32:00 2013 -0700
          last commit:   Wed Jun 19 11:44:44 2013 -0700

@brpocock
Copy link
Contributor

brpocock commented Oct 6, 2022 via email

@stylewarning
Copy link
Contributor

I don't think the world needs more software which can be used in proprietary software without giving anything back to the community.

As a counterpoint, many commercial institutions over ~2 decades have contributed back to SBCL despite its status as being public domain. SBCL, to my knowledge, has also not seen any serious forks.

Previous attempts to commercialize CMUCL are largely defunct.

I think a majority of Lisp hackers know that if they're going to use JSCL, it's in their own best interest to get improvements upstream. Maintaining your own fork is annoying and costly.

The difference between Emacs—which is cited as a potent example of GPL software—and JSCL is that Emacs is first and foremost a piece of application software (which is extended by a programming language), and JSCL is a programming language implementation. A second difference is that Emacs has and has had users since the beginning.

The fact that the implementation generates code, concatenates code, injects code, etc. that are all GPL only becomes a headache to others who are perhaps themselves trying to write FOSS software. Without a deep technical understanding of the implementation of JSCL, you have to assume the worst, and go with "using JSCL implies licensing my own code as GPL."

As pointed out, there are a variety of "workarounds" to this: LGPL, Lisp LGPL, etc. But, if JSCL should continue to be developed by its core team of hackers and maintainers, I personally think GPL will be a deterrent to its use.

We enforce freedom, but at what cost?

(FWIW, I'm pro-GPL, but I also know the Common Lisp community is exceedingly gaunt, and I'm not too hot on approaches that may deliberately make it smaller.)

@henryirvine
Copy link
Contributor

henryirvine commented Oct 6, 2022 via email

@Uthar
Copy link
Contributor

Uthar commented Oct 6, 2022

Agree

@kengruven
Copy link
Contributor

I think a majority of Lisp hackers know that if they're going to use JSCL, it's in their own best interest to get improvements upstream. Maintaining your own fork is annoying and costly.

Then what's the problem with sticking with the GNU GPL? Is there a significant need to appease this minority of potential JSCL users who want to modify and redistribute JSCL but keep their changes secret? Who are they, and why do they want this? Help me to understand.

Unless I've missed it, nobody has yet mentioned a concrete need for this proposed license change, beyond allowing some unspecified set of people to feel more "comfortable".

The difference between Emacs—which is cited as a potent example of GPL software—and JSCL is that Emacs is first and foremost a piece of application software (which is extended by a programming language), and JSCL is a programming language implementation. A second difference is that Emacs has and has had users since the beginning.

OK, then consider CLISP, which has used the GNU GPL since 1992. Their FAQ and license file both contain a reminder that using a GNU GPL compiler does not cause your program to be licensed under the GNU GPL. Do you think a similar notice on JSCL would appease potential users?

The fact that the implementation generates code, concatenates code, injects code, etc. that are all GPL only becomes a headache to others who are perhaps themselves trying to write FOSS software. Without a deep technical understanding of the implementation of JSCL, you have to assume the worst, and go with "using JSCL implies licensing my own code as GPL."

This should be a non-issue. 7 years ago, the JSCL project asked me (as a contributor to the "prelude" code) to re-license the code which would be included verbatim in the compiler output under the MIT license, which I agreed to.

The JSCL documentation should do a better job of communicating this. Or if that re-licensing never got completed, we should complete it now. We don't need to re-license the entire project to fix this one issue.

We enforce freedom, but at what cost?

At the cost of losing the massive market of corporations with Common Lisp programs that they want to run in client web browsers, and who also can't understand the distinction between a compiler and its output, I suppose! Licenses cost nuthin, so that's nuthin times nuthin, carry the nuthin...

@stylewarning
Copy link
Contributor

  1. There is a specific issue linked with a specific person who works on an active and open source project requesting to use this specific project with a different license.

  2. Nobody uses CLISP "in production", to my knowledge. I hear some school students use it, and few others. So I'm not personally terribly interested in using it as any sort of basis for decision-making.

  3. As you may know, a Lisp compiler rarely just batch compiles code with output that is independent of the language implementation itself. Lisp doesn't really permit free-standing code, unlike Rust or C.

Anyway, we may disagree philosophically, but as a representative of an employer of Lisp programmers—an employer that actually contributes back to the open-source community—we're not going to touch JSCL with a ten-foot pole. I know most any other commercial venture would likely agree.

That's fine. GPL isn't wrong. It's a reasonable choice for most any software project. It just means people who get paid to build stuff probably won't use JSCL for anything important.

@stylewarning
Copy link
Contributor

FWIW, for those following, this is CLISP's stated policy for determining whether you (the programmer) or you (the user of a program using this project that may use COMPILE-FILE) must license your code as GPL.

This copyright does NOT cover user programs that run in CLISP and
third-party packages not part of CLISP, if

a) They only reference external symbols in CLISP's public packages
that define API also provided by many other Common Lisp implementations
(namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS,
GRAY, EXT), i.e. if they don't rely on CLISP internals and would as
well run in any other Common Lisp implementation. Or

b) They only reference external symbols in CLISP's public packages
that define API also provided by many other Common Lisp implementations
(namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS,
GRAY, EXT) and some external, not CLISP specific, symbols in
third-party packages that are released with source code under a
GPL compatible license and that run in a great number of Common Lisp
implementations, i.e. if they rely on CLISP internals only to the
extent needed for gaining some functionality also available in a
great number of Common Lisp implementations.

Such user programs are not covered by the term "derived work" used in
the GNU GPL. Neither is their compiled code, i.e. the result of compiling
them by use of the function COMPILE-FILE. We refer to such user programs
as "independent work".

This is not a good example to follow. It's super vague.

  1. How do we judge functionality is equal to that of "many other Common Lisp implementations"? Same symbols? Same lambda lists? Same externally documented behavior?

  2. What counts as "referencing" a symbol? A symbol which the reader reads? A symbol that was INTERNed at runtime? A symbol that was accessed by do-symbols?

This sort of language is exactly what would motivate a corporate lawyer to say, "we aren't going to even attempt to interpret this on a legal basis," and, honestly, I reckon the Lisp community would have a hard time agreeing on what any of the above means in a technical sense.

@davazp
Copy link
Member Author

davazp commented Oct 7, 2022 •
edited
Loading

@kengruven You are right in that many times there is no a good (logical) reason for such a change. In many cases, they could do exactly the same with GPL. I don't think that is true for JSCL. But regardless, I think that is the wrong approach, because nobody is going to convince anyone else about it.

That is why, instead, I emphasized the argument of "some people are more comfortable with it", it seems silly, but that is sometimes perfectly valid! Sometimes we accept changes that are not ideal for us, just to keep people on board. We do that with pull requests all the time.

The fact is, some people want that change, whatever theirs (possibly wrong) reasons. So is this change unacceptable and worth blocking, or not really such a big deal?

(I realize the question doesn't sound 100% honest. We could ask the reverse, "why is changing GPL->MIT a big deal? why can't they concede?" Well, the world won't concede and I don't think it's a battle worth picking)

@ErmineII
Copy link
Contributor

ErmineII commented Oct 8, 2022

I agree for what it's worth with my 3 lines of code :)

@rabbibotton
Copy link

Has there been a final resolution on this yet? If not when could a decision be expected? (sorry for the push)

@equwal
Copy link
Contributor

equwal commented Oct 20, 2022 •
edited
Loading

-1
I don't want JSCL to be used just like Minix in the Intel ME.

https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/
https://wiki.installgentoo.com/wiki/Cuck_license

  • I'm not satisfied with arguments based on the "unlikelyness" of this to happen. JSCL is a perfect candidate for embedding, à la tivoisation. No. Javascript is already a dumpster fire of proprietary abuse.

I contribute to small utilities and so on which are MIT. I'm not sure I'd contribute to this project if it was MIT, considering the above. I do not give permission to license my contribution as MIT.

My contribution is changing two letters, so you can ignore my vote. Do not add me to the list of "approved" contributors though. I do not.
b51797b

@equwal
Copy link
Contributor

equwal commented Oct 20, 2022

There is Nothing New Under the Sun, and the proposed reasons for switching from GPL are not new.

The LLGPL was invented in response to these complaints, but the community decided it was unnecessary to use it, instead just using the standard GPL.

https://www.jolts.world/index.php/jolts/article/view/75/146

@davazp
Copy link
Member Author

davazp commented Oct 20, 2022 •
edited
Loading

Has there been a final resolution on this yet? If not when could a decision be expected? (sorry for the push)

So, there are some contributors who oppose to it with significant contributions so, this is essentially blocked now.

I wonder if we should just close the issue and forget about it 🤷 kind of ironic that majority of big contributors agree but can't change it 🙂 but anyway.

@rabbibotton
Copy link

rabbibotton commented Oct 20, 2022 •
edited
Loading

Shame I would have liked to have used jscl as part of CLOG but GPL/LGPL/AGPL is incompatible and legally untested for Lisp projects in the same binary image and limits the freedoms of the software (layman arguments won't change his reality).

David Vázquez Púa I really want to thank you for taking up this effort for me and the others from the other ticket that would have loved to use this project.

Being the author of at least five major GPL projects in Ada, one requirement I made was everyone had to assign copyright from the start to avoid code death by license should something like this happen on a developer tool. (of course that is not needed with BSD/MIT licenses)

@equwal
Copy link
Contributor

equwal commented Oct 20, 2022 •
edited
Loading

Shame I would have liked to have used jscl as part of CLOG but GPL/LGPL/AGPL is incompatible and legally untested for Lisp projects in the same binary image and limits the freedoms of the software (layman arguments won't change his reality).

David Vázquez Púa I really want to thank you for taking up this effort for me and the others from the other ticket that would have loved to use this project.

Being the author of at least five major GPL projects in Ada, one requirement I made was everyone had to assign copyright from the start to avoid code death by license should something like this happen on a developer tool. (of course that is not needed with BSD/MIT licenses)

Can you provide a source (or more explanation) for why you can't link things into the CL binaries? CL has plenty of separation features (esp. packages) in spite of your response.

https://www.jolts.world/index.php/jolts/article/view/75/146

I think if a case was made for the MIT license that:

  1. [✔] showed a genuine use case
  2. XXX showed that MIT was actually necessary and GPL cannot be okay.

Then the two significant detractors, the "okay I accept but..." crowd, and the insignificant detractors (me) might agree. You met point (1), but not (2). Your argument that "GPL is untested" is still unsubstantiated.

If point (2) is substantiated I will personally give my agreement, for what it's worth.
As a third point:
3) that changing to MIT will not result in undesireable outcomes

Well, of course it can.

@equwal
Copy link
Contributor

equwal commented Oct 20, 2022

Furthermore I'm disappointed that this poll was called without even making a case for the MIT license whatsoever. Everyone should disagree for that reason alone.

I'm not in favour of the change, but I think the MIT supporters should have a chance to make their case, as JSCL is already quite large, and it will be even harder to change it in the future.

@rabbibotton
Copy link

2 - simple, my users, myself and others, will not "link in" gpl/lgpl/agpl code into libraries I write or projects I write and open the door (even if just a change or a even a perception of chance) to legal issues.

3 - As for undesirable outcomes - allowing jscl to be used for non-free software - that is the practical difference. I am not interested in forcing GPL - I want to force them to use Common Lisp for commercial software!! so new younger devs have jobs :P

@stylewarning
Copy link
Contributor

https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/

This was an inflammatory, extremely low quality, and pretty cringy article. It was clearly an attempt to be a largely one-sided, persuasive essay. I think any good points they were close to making were constantly and consistently shrouded in substandard logic and poor analogies. Too bad.

@vlad-km
Copy link
Member

vlad-km commented Oct 21, 2022

Being the author of at least five major GPL projects in Ada,

dear user @rabbibotton can we watch these projects ?

@rabbibotton
Copy link

rabbibotton commented Oct 23, 2022 via email

@rabbibotton
Copy link

So more data now at a desktop:

Look on sourceforge at:
GNAVI which contains these projects:

  • GWindows the standard Windows frame work for Ada used today)
  • GNATCOM full inter-opt with COM/DCOM and also various other tools, used today)
  • GNAVI a full Delphi/VB like environment with ActiveX support for Ada. (I stopped updating it for the very issue here, the company behind GNAT - the only FOSS implementation - decided to add a GPL unto the runtime of the compiler and even though this can be worked around I decided not worth pursuing the project in Ada further as a result.)

GRAW - Ada on Rails - no longer public, licensing issues killed the project as an open project (related to GPL but not entirely)

GNOGA - the father of CLOG, used today in industrial systems, various commercial products etc.

They are all GPL with a clause common to Ada projects called the MGPL that allowed use in commercial products.

As an author of tools for developers, I want my open source projects to be used in commercial settings as well (you make your money on support not sales for the last 20 years) - and straight GPL doesn't fit. Hundreds of products I wrote for customers are GPL and it is my go to license for non-developer products, which means not public or owned by other companies.

JSCL is not a regular compiler where GPL is no big deal as long as the the runtime is BSD or some other more open license. In the case of JSCL the GPL for me and many others, jscl is a useless product as it can not be used in our commercial endeavors or our or our clients, that is a loss for Common Lisp period.

GPL/LGPL/AGPL is a good license, but in the Lisp world it is a dead end unless the entire project is GPL - it does't not promote Common Lisp, Jobs for young developers (or old), and future in IT departments, or commercial websites.

@jgarte
Copy link

jgarte commented May 14, 2023 •
edited
Loading

I think that this should stay GPL'd. Copyleft is a good thing 💯 💣 🙃

References

https://drewdevault.com/2019/06/13/My-journey-from-MIT-to-GPL.html
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests