Is it possible to sell commercial use rights to an open source Racket package?

253 views
Skip to first unread message

Sage Gerard

unread,
Aug 23, 2019, 9:25:02 AM8/23/19
to us...@racket-lang.org
--I believe this email was lost due to me not being subscribed to the list last time I sent it. Sorry if this is a duplicate.

Has someone tried to release an open source Racket project under a license that enforces paid commercial use of that project? Light Googling suggests this would be antithetical to the LGPL if not open source in general, but https://download.racket-lang.org/license.html says "the Racket license does not restrict you at all."

I understand no replies here or any web page constitutes legal advice, so please take my question in the spirit of respecting the LGPL's sublicensing restrictions and learning what other people are doing to earn money independently using Racket.

~slg


Stephen De Gabrielle

unread,
Aug 23, 2019, 10:02:00 AM8/23/19
to Racket Users
Hi Sig,

GNU provides they reason why not to use LGPL: https://www.gnu.org/licenses/why-not-lgpl.html


- Github has a summary of what they think the meaning of LGPL is https://choosealicense.com/licenses/ 

GNU also provides this; https://www.gnu.org/licenses/lgpl-java.html which I *believe* mirrors what is written at https://download.racket-lang.org/license.html
 
I hope this helps. 

Kind regards, 

Stephen

Philip McGrath

unread,
Aug 23, 2019, 11:28:54 AM8/23/19
to Stephen De Gabrielle, Racket Users
One issue you would encounter is that deciding what is a "commercial" use can be difficult. This comes up with Creative Commons licenses (https://creativecommons.org/faq/#does-my-use-violate-the-noncommercial-clause-of-the-licenses):
… there will always be uses that are challenging to categorize as commercial or noncommercial. CC cannot advise you on what is and is not commercial use.

CC has a 255-page study titled "Defining 'Noncommercial'" which they clarify does not, in fact, define "noncommercial."

However, regardless of whether you should do this, I believe you can. The LGPL governs your use of Racket itself in your product: it does not dictate the terms of the license you use for your code (except that people must be allowed to re-link your code with new/modified versions of Racket). I can write programs in Racket and release them under the AGPL; someone else can release their Racket programs under an entirely non-free proprietary license. If you want to use a license to charge money only to "commercial" users, you can find or create a license that (hopefully)  expresses your intent. However, such a license would not meet the definition of "open source" or free/libre software, due to "discrimination against fields of endeavor" (https://opensource.org/osd).

(I am not a lawyer; this is just my understanding as a creator and user of software.)

-Philip


--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/b4fb588c-6043-4eb5-8e6d-d987ed465849%40googlegroups.com.

Alexander Shopov

unread,
Aug 23, 2019, 11:32:20 AM8/23/19
to sa...@sagegerard.com, Racket Users
The part "earning what other people are doing to earn money independently using Racket." is interesting in itself - people may answer while you may check presentations at RacketConf where there are comercial usages of Racket.

Take my answer with a large pinch of salt but here is gist:
The DrRacket distribution is LGPL3 - you may use it, change it, distribute it and distibute changes to it under LGPL i.e. every time you distribute it you will have to provide the source (under same licence). You cannot impose more obligations or weave obligations stemming from that.

Since Racket licence is LGPL you may distibute your modules that link to it and there are basically no obligations for those modules. Those additional modules may impose whatever conditions you want. Thus you might distribute them in the binary format of Racket, you may distribute in source form - and no matter what way you do the distribution you may demand payment for whatever usage - commercial or not. You may prevent changes or distribution of changes.

"enforcing" would have to be done via the court system - for example when someone uses your modules in a way different from your license.

Now - what comprises linking (as different to 'derivative work') is a convoluted matter. FSF site will be helpful in that yet the legal practice may be different in different countries.

The sentence "the Racket license does not restrict you at all" means it does not restrict your modules.
In a wider sense it also means that your usage of Racket is not restricted, but distribution of Racket (AKA conveying) is a different matter (and there are conditions on that)

Kind regards:
al_shopov

Alexis King

unread,
Aug 23, 2019, 11:40:13 AM8/23/19
to Sage Gerard, us...@racket-lang.org
Disclaimer: I am not a lawyer. (But, as others have mentioned, the answer is yes.)

In the subject of your subject, you mention “an open source Racket package,” but in the body of your email, you talk about “an open source Racket project.” If you are genuinely talking about a Racket package (in the `raco pkg` sense, distributed as source code), then you are likely not distributing Racket, in which case you are not restricted by Racket’s license at all. You are free to license your package however you want, commercially or otherwise. You’re only bound to the terms of Racket’s license if you redistribute Racket itself.

If you are instead talking about a Racket application, distributed bundled with a Racket runtime or any Racket libraries (such as a bundle created with `raco distribute`), then you are beholden to the terms of the Racket license. You are likely required by the terms of the LGPL to make your application’s source files available to your users, as Racket’s ubiquitous use of macros generally precludes replacing library dependencies without recompiling their dependents. However, that does not force you to license your source files under the LGPL, only make them available under your commercial, proprietary license.

Distributing a closed-source, non-LGPL Racket application without violating Racket’s licensing terms is likely to be very difficult or impossible, pending the still-ongoing MIT + Apache 2 relicensing effort. But you already said your project is open source, anyway, so that doesn’t matter for you.

Alexis

P.S. I think the interpretation of the LGPL given in the page you linked is wrong, as it seems to assume that access to your bytecode files is sufficient to relink your application against modified versions of Racket. In the presence of macros (and, to a lesser extent, cross-module inlining), this is very often not true. However, there is scant legal precedent for the interpretation of the LGPL, so ultimately it’s hard to guess what a court would find convincing.

Matthew Butterick

unread,
Aug 23, 2019, 2:03:48 PM8/23/19
to Sage Gerard, Racket list

On Aug 23, 2019, at 6:24 AM, Sage Gerard <sa...@sagegerard.com> wrote:

Has someone tried to release an open source Racket project under a license that enforces paid commercial use of that project? Light Googling suggests this would be antithetical to the LGPL if not open source in general, but  https://download.racket-lang.org/license.html says "the Racket license does not restrict you at all."


I am a lawyer, and I remain mostly mystified about Racket's licensing / IP ownership status since it joined Software Freedom Conservancy in June 2018. 

In some cases, SFC takes ownership of trademarks and copyrights [1] which means that in terms of license interpretation & enforcement, assumedly the buck would now stop with them. 

Did SFC do so in this case? No idea. Before the switch, Karen Sandler from SFC circulated [2] a template agreement [3] but AFAIK the actual agreement that Racket's core team signed, and the details thereof, has never been shared with the community. (Can it? Should it? Not my call. Or did I miss it?)

Furthermore, the original SFC/Racket press release mentioned a "newly formed Project Leadership Committee" [4] — there's never been any mention of who's on this committee, or whether their responsibilities involve licensing. 

Lingering elsewhere: the relicensing project that commenced more than 2.5 years ago [5] — not clear whether under the SFC this effort is alive, dead, or what. Of course, Galaxy's Edge took 3 yrs to build, so maybe I'm being unreasonably impatient. 

(BTW though I do not redistribute Racket, there's often a certain amount of modified Racket code in packages I maintain, therefore the limitations on Racket code also limit the licensing of my packages. Other things being equal I'd rather use a license more liberal than the LGPL.)



Alexis King

unread,
Aug 23, 2019, 2:24:45 PM8/23/19
to Matthew Butterick, Sage Gerard, Racket Users
> On Aug 23, 2019, at 13:03, Matthew Butterick <m...@mbtype.com> wrote:
>
> In some cases, SFC takes ownership of trademarks and copyrights [1] which means that in terms of license interpretation & enforcement, assumedly the buck would now stop with them.

AFAIK, copyright of the Racket codebase is not the Racket core team’s to give. Racket has no CLA, so its copyright belongs to all of the individual contributors, core team members or not. If the Racket core team did own the copyright, the relicensing effort would have amounted to little more than a decision. But as-is, whether the SFC takes ownership of copyrights held by the core team or not is irrelevant, as any individual Racket contributor could choose to enforce the terms of the license for their contributions should they desire. But I’m sure you knew all that already—you’re the lawyer—so I’m curious what you know that I don’t.

At any rate, I second your desire to know what the status of the relicensing effort actually is. Are we looking at three stragglers left on the list who still haven’t signed? A dozen? A hundred? And maybe more importantly, how many lines of code do they really own? At what point can we not just rewrite those portions of the codebase? I know that figuring out ownership can be tricky for long-running software projects like these, since the question of what constitutes derivative work from the original contribution is often unclear, but even just a ballpark estimate would be nice to know.

Matthew Butterick

unread,
Aug 23, 2019, 3:19:38 PM8/23/19
to Alexis King, Racket list
You're omitting some key facts. So no, I don't agree with your legal analysis. 

But the underlying point remains: there is unnecessary murkiness around Racket's licensing status. 

Alexis King

unread,
Aug 23, 2019, 3:29:38 PM8/23/19
to Matthew Butterick, Racket list
> On Aug 23, 2019, at 14:19, Matthew Butterick <m...@mbtype.com> wrote:
>
> You're omitting some key facts.

Maybe so, but that is, in fact, why I sent the email. I was hoping you could clue me in as to what I was missing. (Maybe it’s unfair of me to ask you for free legal analysis, but I don’t feel like it’s all that unreasonable to ask for just a little clarification here.)

Sage Gerard

unread,
Aug 23, 2019, 3:42:14 PM8/23/19
to m...@mbtype.com, lexi....@gmail.com, us...@racket-lang.org
First, thank you all for the responses.

Originally I figured I would need to find some key contacts and ask them to review my Racket package* for written permission to publish under a proposed license. But if ownership itself is a question mark, I wonder if I should just pick LGPL for safety and then move to multilicense if an opportunity presents itself. To add context, I aim to use a custom license.

When it comes to finding that opportunity; Does this thread provide enough information for me to retain an attorney and get candid advice on how to proceed, or would (s)he be unable to answer given the state of ownership?

* Meaning `raco pkg`. Good catch, Alexis.

-slg




-------- Original Message --------
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5AC224B1-ED3B-4083-A165-FEB9AB9A701A%40mbtype.com.

Matthew Butterick

unread,
Aug 23, 2019, 3:48:16 PM8/23/19
to Alexis King, Racket list
Bradley Kuhn, director of the SFC, has explained why FLOSS projects don't need CLAs, along with some underlying legal truths about FLOSS contributions. [1] 

Alexis King

unread,
Aug 23, 2019, 5:30:12 PM8/23/19
to Matthew Butterick, Racket list
Thank you for the link. I read through it, along with the (much longer) blog post linked at the beginning. The first thing it made me realize is that I should be more clear: I am not advocating for a CLA! I agree with most of the arguments against them that both posts make.

All I was saying is that, given Racket does not have any form of copyright assignment agreement, as the blog post calls them, Racket as an organization does not possess the copyright to contributors’ code, and they do not control enforcement of that copyright. AFAICT, the linked blog post supports that (though it argues that’s a good thing, which I agree with, and it also makes an argument that a CLA doesn’t necessarily change that in a simple way, either, which was indeed news to me and was interesting to read).

I feel like I have reason to believe my interpretation is correct, as it isn’t entirely theoretical. In 2014, the developers of the popular, open-source Minecraft server modding framework, CraftBukkit, decided to retire the project after years of volunteer work. Mojang, Minecraft’s developer, announced they had secretly purchased ownership of the project from its co-founders years before when they had hired several of them to become Mojang employees, and they said would continue the project themselves. That upset several of the volunteers, as they realized Mojang had been knowingly exploiting their unpaid labor for years without offering any help. One of the developers of CraftBukkit proceeded to send Mojang a DMCA takedown request for his own source code, as CraftBukkit was GPL-licensed, and the whole project was technically illegal to begin with (since it modified and redistributed proprietary Minecraft source code).

Assuming the takedown request was legal (which is to say, assuming the developer really did hold the copyright), then to comply with it, Mojang would have needed to either release the Minecraft server code under the GPL, something they were clearly not about to do, or abandon CraftBukkit (or at least the parts of it that developer wrote). They chose the latter, despite surely having a perfectly capable legal team. Realistically, do I think any Racket contributors are going to start DMCAing projects in violation of the LGPL for parts of the Racket codebase they hold copyright on? No. But I don’t see why the situation would legally be any different for Racket than it was for CraftBukkit.

Neil Van Dyke

unread,
Aug 23, 2019, 7:20:36 PM8/23/19
to Sage Gerard, Racket-Users List
(Replying to 2 messages...)

Summary: I think there's probably no barrier for you with Racket's
licensing and intentions, but you will need to talk with your lawyer
about the unusual licensing you want to do for your own software. Also,
a few related thoughts.

Sage Gerard wrote on 8/23/19 9:24 AM:
> Has someone tried to release an /open source/ Racket project under a
> license that enforces paid commercial use of that project?

It's my impression that the Racket professors intend that you be able to
do this, and would be happy to see you to do this.  And at least some of
the third-parties, as well.

Separate from Racket professors, SFC might also have a bit different
perspective, since it has some noteworthy FSF influences.  (FSF is
well-known to be philosophically opposed to the approach I think you
alluded to, and has suggested other ways to make money from software.)

You might get better answers in a few weeks.  (The US school year starts
in about a week, and people are finishing up vacations, and a bunch of
new things have been happening at once.)

> and learning what other people are doing to earn money independently
> using Racket.

I think there are only a few people making any money at all with Racket,
outside of academia.  (We're still waiting for a dotcom startup to
strike it rich, and then say that Racket was the best tool for getting
to launch.  Then more people will be willing to bet on it.)

BTW, because some discussions about startups and such can be sensitive,
for various reasons, there's also a smaller, ephemeral email list:
https://linki.tools/racket-money/  By default, `racket-users` should be
used, but `racket-money` is there for some of the times `racket-users`
won't work.


Sage Gerard wrote on 8/23/19 3:42 PM:
> I wonder if I should just pick LGPL for safety and then move to
> multilicense if an opportunity presents itself. To add context, I aim
> to use a custom license.

Of course, once you LGPL a release, that particular release is LGPL
forever.  If you intend to later institute licensing that "enforces paid
commercial use", the earlier LGPL release might be a practical threat to
that.  (That's happened.)

Also, you don't want to inadvertently bait&switch users, by starting out
as LGPL and then changing the license on them.  (That happens with some
other projects, including some noteworthy ones in recent months, and
many people react negatively to that.)

There have been a variety of ideas about how to do this, nothing
specific to Racket.

If you *really* want to altruistically open source something, before
you've figured out the paid commercial licensing you want to do, and
some of your software is well-modularized... then consider polishing up
some of the more-generic, low-tech pieces you had to write (e.g., module
for routing HTTP requests), and releasing those as LGPL'd Racket
packages.  Keep your less-generic, more-IP code closed, until you figure
out the licensing for that.

> When it comes to finding that opportunity; Does this thread provide
> enough information for me to retain an attorney and get candid advice
> on how to proceed, or would (s)he be unable to answer given the state
> of ownership?

I suspect that an attorney very familiar with open source licensing
probably already has enough information to get started -- based on the
standard licenses you see people putting on core Racket and any
third-party packages you're using.

The attorney might then ask you technical questions about the nature of
the use/integration (e.g., for all the separately licensed stuff are you
using in some way, did you copy or modify any source code, and what is
the technical nature of using these in Racket).

Then, if some of the important distinctions still seem muddy to the
attorney (e.g., "linking" in the sense the license might use it, is
syntax expansion different than function call, compiler output, runtime,
etc.), then I suppose the attorney might want to discuss with a
representative of core Racket (and maybe other copyright holders),
and/or carefully craft questions for them.  That might be more
productive than people trying to guess what's the attorney will consider
muddy.

I'm going to guess, as a non-lawyer, that what's going to cost you the
most billable hours of attorney time is figuring out a custom license,
if you end up going that route.

The Racket side seems pretty straightforward (e.g., if you'll use things
under their current LGPL license), once the attorney understands the
nature of use/integration.

Aside: One thing I don't want is anyone new to Racket and open source
licensing to get a chance drive-by impression that Racket has unusual
"licensing problems".  I saw this concern multiple times recently.  I'd
say Racket's standard licensing (for using it as a
compiler/runtime/libraries) is pretty commercial-friendly, especially
given the willingness (perhaps, desperation) of a lot of Racketeers to
encourage commercial adoption.  Worst case might be that a particular
attorney will just need some clarifications that people are happy to
help with.


Hendrik Boom

unread,
Aug 24, 2019, 8:48:41 AM8/24/19
to Racket-Users List
On Fri, Aug 23, 2019 at 07:20:31PM -0400, Neil Van Dyke wrote:

>
> Aside: One thing I don't want is anyone new to Racket and open source
> licensing to get a chance drive-by impression that Racket has unusual
> "licensing problems".  I saw this concern multiple times recently.  I'd say
> Racket's standard licensing (for using it as a compiler/runtime/libraries)
> is pretty commercial-friendly, especially given the willingness (perhaps,
> desperation) of a lot of Racketeers to encourage commercial adoption.  Worst
> case might be that a particular attorney will just need some clarifications
> that people are happy to help with.

The only problem I see is with the ue of macros in the propietary part
of your software. They make it difficult to take your object code and
link it with revised versions of the LGPL'd Racket code.

It seems to me that the LGPL does not require you to be able to link
with incompatible versions of LGPL'd code, so this should not be a
*legal* problem, but would be a severe practical problem for your
customers.

Anyone know for sure?

In any case you should be able to release your proprietary source code
to your customers. They they could install it on their working Racket
systems.

-- hendrik

>
>
> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7f441387-cb9c-5cd5-0d7b-c6d8f8919409%40neilvandyke.org.

Neil Van Dyke

unread,
Aug 24, 2019, 11:12:43 PM8/24/19
to Racket-Users List
Hendrik Boom wrote on 8/24/19 8:48 AM:
> The only problem I see is with the ue of macros in the propietary part
> of your software. They make it difficult to take your object code and
> link it with revised versions of the LGPL'd Racket code.

This seems much the same problem as doing the analogous thing with C
libraries, not unique to Racket.

Racket macros in practice tend to do than C macros do, but the
sensitivity of the mechanism seems much the same.

For example, if a C header changes even a single simple cpp-based
`#define SOME_VALUE 7` "constant" between versions, that would probably
get baked into compiled code, and one would probably be incorrect to
relink (without recompiling) a new version of the library that changed that.

(Incidentally, the drawbacks of mixing in closed binary libraries and
kernel modules with open source software are well-known in C and C++. 
This might plague you, for example, if you're trying to bring up new
Linux on an old Linux-based device that used closed drivers, or are
dependent on Nvidia closed drivers for your video display or your GPU
compute engines.  Separate from not being able to inspect and improve
the closed stuff, they tend to eventually stop working with newer
software with which they link, with no practical recourse.)

Joel Dueck

unread,
Aug 27, 2019, 12:17:46 PM8/27/19
to Racket Users
On Friday, August 23, 2019 at 10:40:13 AM UTC-5, Alexis King wrote:
Distributing a closed-source, non-LGPL Racket application without violating Racket’s licensing terms is likely to be very difficult or impossible, pending the still-ongoing MIT + Apache 2 relicensing effort.


This was startling for me to read, as I have been contemplating doing that very thing.

After some consideration, I hereby announce my intent to distribute a closed source non-LGPL Racket application sometime within the next year. If anyone with standing has a problem with that, please let me know.

Matthew Butterick

unread,
Aug 27, 2019, 8:37:16 PM8/27/19
to Sam Tobin-Hochstadt, Racket list


On 27 Aug 19, at 9:27 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:

4. The interpretation of the LGPL as it relates to Racket that appears
on the download page is our (the Racket leadership) interepretation,
not the SFCs. None of us are lawyers, but that remains our
interpretation.

So Racket's licensing is, or is not, supervised by an actual lawyer? In the past, I've gathered that Racket management has consulted with a lawyer on certain issues. But your comment suggests that maybe this isn't so. Or at least not for licensing.


3. The license of Racket has not changed as a result of joining the SFC.

6. The relicensing is something we hope to complete, but as the SFC is
now the fiscal sponsor of the Racket project they are working to make
sure it's done to their standards, which may require more time.

These statements seem somewhat at odds — how should they be reconciled? Do you mean that if & when the relicensing is completed, Racket's licensing will be thereafter be supervised by the SFC and its lawyers (because the relicensing needs to be "done to their standards")? As I understand it, though SFC's term-of-art legal designation is "fiscal sponsor", their relationship with member projects encompasses more than just fiscal matters. [1]




Neil Van Dyke

unread,
Aug 27, 2019, 10:49:59 PM8/27/19
to Racket Users
'Joel Dueck' via Racket Users wrote on 8/27/19 12:17 PM:
> On Friday, August 23, 2019 at 10:40:13 AM UTC-5, Alexis King wrote:
>
> Distributing a closed-source, non-LGPL Racket application without
> violating Racket’s licensing terms is likely to be very difficult
> or impossible,
>
>
> This was startling for me to read, as I have been contemplating doing
> that very thing.

Questions and confusion about software licensing come up all the time,
when a conscientious person tries to interpret software licenses.

Open source licenses don't seem as adversarial as many closed software
licenses do, but are still confusing. I think one needs the background
of a lawyer to even have a credible sense of whether one understands it
sufficiently.

If one is doing open source, the open source licenses are so well-worn,
with so much precedent, it doesn't appear to be stopping massive amounts
of open source work out there.

On the other hand, if one is doing closed software, again, there's a lot
of precedent of this working out well, and also, presumably, one is
going to be paying a lawyer to draft/vet their own licenses, in any case
(regardless of whether one uses Racket, or anything else), which I
imagine requires taking a look at licenses of the software one's own
software uses.  (And that lawyer will be vastly better qualified than
myself and most of us to say (I imagine), "OK, this, that, and the other
open source license thing are well-accepted, and you're not doing the
sneaky thing that causes most problems, so I just have a question about
whether this other thing over here is the same thing as what already has
a common interpretation".  Then, there might be a lawyerly question,
that can then be answered in a lawyerly way.  But if I tried to ask a
lawyerly question, it would be the wrong question, and how I asked it
would be wrong 10 different ways.)

> After some consideration, I hereby announce my intent to distribute a
> closed source non-LGPL Racket application sometime within the next
> year. If anyone with standing has a problem with that, please let me know.

I agree with what I think you're implying: that licensing is unlikely to
be a problem.  The informality reminds me of a funny bit from "The
Office": https://www.youtube.com/watch?v=EuZeff2y32M

Alex Harsanyi

unread,
Aug 28, 2019, 1:10:56 AM8/28/19
to Racket Users


On Wednesday, August 28, 2019 at 12:17:46 AM UTC+8, Joel Dueck wrote:
On Friday, August 23, 2019 at 10:40:13 AM UTC-5, Alexis King wrote:
Distributing a closed-source, non-LGPL Racket application without violating Racket’s licensing terms is likely to be very difficult or impossible, pending the still-ongoing MIT + Apache 2 relicensing effort.


This was startling for me to read, as I have been contemplating doing that very thing.

I am curious to know how you plan to comply with section 4.d of the LGPL, which states that the users of your application must be able to replace the LGPL "library" with a modified version of their own -- this means all the racket packages that you use in your application (even the ones shipped with Racket):

Option 4.d.1 is not possible, since racket packages are not shared libraries.  

Option 4.d.0 would essentially require you to provide your customers with all the compiled object code (.zo files), along with instructions on how the user can reconstruct your application using a different Racket version -- I am not sure if this is even possible.  I guess, you could provide your customers with the source code for your application (along with a license which prevents them from re-distributing it), in this case they would be able to "link in" another version of Racket.  Perhaps there are other ways?

I like the intent of LGPL, but I think this detail makes it a poor fit for an environment like Racket.

Also, I am not a lawyer.

Alex.

Joel Dueck

unread,
Aug 28, 2019, 11:45:10 AM8/28/19
to Racket Users
On Wednesday, August 28, 2019 at 12:10:56 AM UTC-5, Alex Harsanyi wrote:
I am curious to know how you plan to comply with section 4.d of the LGPL, which states that the users of your application must be able to replace the LGPL "library" with a modified version of their own -- this means all the racket packages that you use in your application (even the ones shipped with Racket):

Excellent question. I don’t intend to comply with the LGPL.

My reasoning is as follows:

We know that a couple of years ago, Racket’s caretakers took steps to try to change Racket from LGPL to MIT+Apache.
We know that effort has effectively stalled out, with no definite explanation given as to why (as far as I know).

So either
  a) Racket's caretakers have changed their minds and no longer agree that the license should be changed, OR
  b) Racket's caretakers have been unable to get all of the original copyright-holding contributors to sign off on the change, because of an inability to get a response or because some contributors have refused, or because the caretakers themselves haven't had time to finish the process, OR
  c) The whole process has been placed on hold because of external factors (such as deference to SFC standards/timing), OR
  d) The process is on track but we haven't been told yet. (Perhaps it’s very nearly done, perhaps it's being worked on mostly by people who don’t know we’re having this discussion, etc.)

I have ruled out (a) since in that case we would expect them to say the change is off and put the matter to rest.

If (b) or (c) or (d) is the case, then it remains that *most* of Racket’s key contributors still believe in, and fully intend to effect, a switch to a more permissive license. Which in turn means that an enforcement action (against a developer doing something that would be allowed under those more permissive terms) is vanishingly unlikely. The worst case would be a (b) situation where some contributors are refusing; even in that case, unless the contributors are themselves lawyers, the practical threat of an action would (I think?) be small.

Perhaps naively (IANAL), I am willing to be the guinea pig who will put these assumptions to the test by violating the terms of Racket’s current license. I’ve decided to make the test more interesting by announcing my intent here. I will let you all know if I receive any lawyer letters after release day. Any such letters would flush out who the recalcitrant contributors are and help us identify which portions of Racket need to be rewritten to allow the license change to proceed.

Neil Van Dyke

unread,
Aug 28, 2019, 12:54:42 PM8/28/19
to Joel Dueck, Racket Users
wrote on 8/28/19 11:45 AM:
> Perhaps naively (IANAL), I am willing to be the guinea pig who [...]

I really would've expected the applied game theory civil disobedience /
anarchism to kick in on a *different* Racket issue. :)

If someone violates (their non-lawyer interpretation of) the Racket
license, in a conspicuous manner like you suggest, would they not expect
the SFC to send them a nastygram -- perhaps if only for the SFC to show
that they defend the copyright, if not for other reasons?

Racket core doesn't necessarily even have to be in the loop:
https://www.itworld.com/article/2732025/gpl-enforcement-sparks-community-flames.html

That seems like it would be bad for Racket.

I look forward to a few different things getting straightened out in
September, and then we all can look back, and blame The Racket Fugue on
this summer's record heat, when no one knew what they were doing.

Alexis King

unread,
Aug 28, 2019, 1:22:03 PM8/28/19
to Neil Van Dyke, Joel Dueck, Racket Users
> On Aug 28, 2019, at 11:54, Neil Van Dyke <ne...@neilvandyke.org> wrote:
>
> If someone violates (their non-lawyer interpretation of) the Racket license, in a conspicuous manner like you suggest, would they not expect the SFC to send them a nastygram -- perhaps if only for the SFC to show that they defend the copyright, if not for other reasons?

You don’t have any risk of losing a copyright just because you don’t choose to enforce it; you’re thinking of trademark law. If a copyright holder chooses not to pursue legal action against a violator, they may do so, and it does not in any way prevent them pursuing action against them or someone else in the future.

That said, your following sentence is absolutely right: it doesn’t matter if the Racket core team chooses not to enforce their copyright if they are not the exclusive copyright holders, and as I have already opined, I believe they are not. Any copyright holder may pursue legal action against violations of their copyright if they so choose, whether they are members of the Racket core team, the SFC, or independent Racket contributors.

On the other hand, if I were Joel, I probably wouldn’t be losing sleep over the potentiality of a Racket contributor taking me to court over my infringement. As I said previously, I don’t know how much Racket code is still exclusively licensed under the LGPL, but I’d bet the large majority is now licensed under the MIT and Apache licenses as well. Unless Joel starts making millions off his project and some contributors come out of the woodwork to try and get a piece of that action, I doubt his assessment is incorrect… and if that happens, well, he can probably afford to pay them enough to negotiate a license with them.

Still, a calculated risk is still a risk. YMMV, IANAL, and obviously this is not qualified legal advice.

Joel Dueck

unread,
Aug 28, 2019, 1:23:14 PM8/28/19
to Racket Users
On Wednesday, August 28, 2019 at 11:54:42 AM UTC-5, Neil Van Dyke wrote:
If someone violates (their non-lawyer interpretation of) the Racket
license, in a conspicuous manner like you suggest, would they not expect
the SFC to send them a nastygram -- perhaps if only for the SFC to show
that they defend the copyright, if not for other reasons?

Racket core doesn't necessarily even have to be in the loop:
https://www.itworld.com/article/2732025/gpl-enforcement-sparks-community-flames.html


Here’s Karen Sandler, Executive Director of the SFC, responding to Matthew Butterick on racket-dev last year[1]:

Apparently, much of the SFC's advocacy and energy goes into GPL /
copyleft issues. But last I checked, Racket is migrating away from GPL
/ copyleft. [3] What is the SFC's position on the MIT license? Do
member projects that are not GPL / copyleft have the same standing
 within SFC?

Conservancy is license agnostic as an organization. We have many
projects that are non-copyleft, and they are just as important to us. We
only undertake copyleft enforcement for our member projects that ask us
to do it.
The vast majority of our work is not related to copyleft at
all - it's sending developers to conferences, hiring contractors to work
on free software, helping to run conferences and helping with various
random things that projects need.

This seems consistent with the twisty maze of events described in the article you linked to. I suppose that, taken together, this means that any single contributor/copyright holder might be able to have SFC sick their lawyers on me.

There’s also, as Matthew Butterick mentioned earlier [2], the open question of whether the SFC itself now has ownership of Racket’s trademark and copyrights.

Neil Van Dyke

unread,
Aug 28, 2019, 1:46:55 PM8/28/19
to Racket Users
Showing that you defend a copyright is not just for any legal status of
it, but so that others take it seriously (e.g., are less likely to see
what they can get away with, which was a significant problem for a while).

Also, intentionally violating (as far as you know) a popular open source
license, in some maneuver, seems disrespectful of a foundation of all
open source projects.  In play are both legal constructs and social
contracts -- what terms people buy into, when they participate in an
open source project.  We compromise these at our peril.  Process is our
friend.

Alex Harsanyi

unread,
Aug 28, 2019, 9:39:05 PM8/28/19
to Racket Users


On Wednesday, August 28, 2019 at 11:45:10 PM UTC+8, Joel Dueck wrote:
On Wednesday, August 28, 2019 at 12:10:56 AM UTC-5, Alex Harsanyi wrote:
I am curious to know how you plan to comply with section 4.d of the LGPL, which states that the users of your application must be able to replace the LGPL "library" with a modified version of their own -- this means all the racket packages that you use in your application (even the ones shipped with Racket):

Excellent question. I don’t intend to comply with the LGPL.


I was really hoping that you actually had a solution to the problem I
mentioned...

The LGPL clarification on https://download.racket-lang.org/license.html states
that we need to be able to re-link the software with modified versions of
Racket.  I am not sure how to achieve that, so here are my technical
questions, directed to anyone on this list who can answer them:

0) To simplify things, the same Racket version and OS can be used for both
   "raco make" to produce the bytecode files as well as the "raco exe" part to
   "link" the executable.

1) Given a set of ZO files compiled using "raco make", is it possible to
   create an executable from these ZO files using "raco exe", or a call to
   `create-embedded-executable`, without having access to the source files
   themselves?  If it is possible, how?

2) Is it possible to distribute a Racket package as ZO files only and actually
   be able to use it from Racket? If it is possible, how?

Alex.

Matthew Flatt

unread,
Aug 29, 2019, 10:01:51 AM8/29/19
to Matthew Butterick, Racket list
At Fri, 23 Aug 2019 11:03:42 -0700, Matthew Butterick wrote:
> Did SFC do so in this case? No idea. Before the switch, Karen Sandler
> from SFC circulated [2] a template agreement [3] but AFAIK the actual
> agreement that Racket's core team signed, and the details thereof,
> has never been shared with the community. (Can it? Should it? Not my
> call. Or did I miss it?)

It was the same, with the "Self-Perpetuating Committee" option for 6:

https://drive.google.com/open?id=17mrcnMLVMYBCp3fb71gY1a7lYwvIyApR


> Furthermore, the original SFC/Racket press release mentioned a "newly
> formed Project Leadership Committee" [4] — there's never been any
> mention of who's on this committee, or whether their responsibilities
> involve licensing.

It's Matthias, Robby, Sam, Jay, and me --- the same as Racket
leadership before joining the Conservancy.

Leadership's job includes licensing in the sense that if we want to
change the Racket license, then leadership has to move it along, either
by doing the work directly or finding people to help. The Conservancy
can provide legal support and advice, and it obviously has a say in
whether a license choice is compatible with the Conservancy's goals and
membership (which, in the case of the relicensing that we're trying to
accomplish, it is).


> Lingering elsewhere: the relicensing project that commenced more than
> 2.5 years ago [5] — not clear whether under the SFC this effort is
> alive, dead, or what. Of course, Galaxy's Edge took 3 yrs to build,
> so maybe I'm being unreasonably impatient.

Clearly, we could use some help.

Joel Dueck

unread,
Aug 29, 2019, 11:14:20 AM8/29/19
to Racket Users


On Thursday, August 29, 2019 at 9:01:51 AM UTC-5, Matthew Flatt wrote:
> Lingering elsewhere: the relicensing project that commenced more than
> 2.5 years ago [5] — not clear whether under the SFC this effort is
> alive, dead, or what. Of course, Galaxy's Edge took 3 yrs to build,
> so maybe I'm being unreasonably impatient.

Clearly, we could use some help.


 What are the tasks that we could take off your hands? Are there requirements for doing these tasks besides having a pulse and a keyboard?

Matthew Flatt

unread,
Aug 29, 2019, 11:45:33 AM8/29/19
to Joel Dueck, Racket Users
A pulse and keyboard is a good start, but the task requires significant
initiative to work with the Conservancy to get guidance and make sure
things move along. The process may possibly involve contacting
individual contributors (again) and helping them figure out who needs
to be contacted at their respective institutions, and then making sure
that communication actually happens. It's not rocket science, but it's
actual work.

Joel Dueck

unread,
Aug 29, 2019, 12:14:05 PM8/29/19
to Racket Users
On Thursday, August 29, 2019 at 10:45:33 AM UTC-5, Matthew Flatt wrote:

A pulse and keyboard is a good start, but the task requires significant
initiative to work with the Conservancy to get guidance and make sure
things move along. The process may possibly involve contacting
individual contributors (again) and helping them figure out who needs
to be contacted at their respective institutions, and then making sure
that communication actually happens. It's not rocket science, but it's
actual work.


Understood. If you or someone can get me up to speed — perhaps some
email introductions, a list of contributors, a rough indication of the current
state, I can commit to pushing this cart consistently, say through the end
of the year. Then we can review and go from there. If anyone else would
rather do it, or would prefer it be someone else, that’s obviously fine too.

(To clarify, I didn't mean by “pulse and keyboard” to imply anything
derisive about the work that needs to be done or the people who
had been doing it. I just wanted to know if any special domain
expertise was needed or if a prole like me could do it. I'm pretty familiar
with software licensing issues, but have only been in Racket’s orbit
for the past few years or so.)

Sam Tobin-Hochstadt

unread,
Aug 29, 2019, 12:27:41 PM8/29/19
to Joel Dueck, Racket Users
Thanks for volunteering! I'll follow-up off-list.

Sam
> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a42134cc-888b-48e3-a2b8-c6aef42933bf%40googlegroups.com.

Joel Dueck

unread,
Aug 29, 2019, 12:31:25 PM8/29/19
to Racket Users
On Thursday, August 29, 2019 at 11:27:41 AM UTC-5, Sam Tobin-Hochstadt wrote:
Thanks for volunteering! I'll follow-up off-list.

Sam

Sure thing. Just minutes ago I dug up the Relicensing Permission issue on GitHub
and found you have made significant progress. Not looking to wrest this out of any-
one's hands, just to donate a chunk of spare cycles if it will help push this thing over
the top.

Sage Gerard

unread,
Aug 29, 2019, 1:41:06 PM8/29/19
to jo...@protonmail.com, racket...@googlegroups.com
Joining in. I want to be part of this.


-slg




-------- Original Message --------
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/32e751d1-5ef8-4011-b007-fb4e099e1682%40googlegroups.com.

Alex Harsanyi

unread,
Sep 18, 2019, 8:43:05 AM9/18/19
to Racket Users
I did some investigations and it it turns out that the answer to both questions is YES, one can create and distribute the bytecode for a package or application and allow the user to link them with a, possibly modified, Racket runtime.  The trick is to use "raco pkg create", which allows creating binary only packages and works for regular applications too.  Since no one responded to my message, it seems this is not common knowledge, so I wrote some notes about it, in case others find it useful: https://alex-hhh.github.io/2019/09/racket-binary-packages.html

Alex.
 

Alex.
Reply all
Reply to author
Forward
0 new messages