
Completing Racket's relicensing effort - samth
https://blog.racket-lang.org/2019/11/completing-racket-s-relicensing-effort.html
======
anaphor
It's not clear from the title I think, but this actually was a multi-year
undertaking, "This has been a long process, beginning in 2017".

I made some small contributions to Racket's SSH library personally, and I was
happy to consent to relicensing. I think most people who contribute docs/code
to projects like this did it because it was something _they_ needed
implemented, so it would be counter-productive to ask for it to be removed,
IMO.

------
dumbmatter
_Two people declined to re-license their contributions to Racket. We therefore
removed their contributions and, where appropriate, replaced them with new
code and /or documentation._

Is that actually allowed by the GPL? I thought it was more like the "Ship of
Theseus" \- that even if you eventually replace all the original GPL code, the
entire work remains GPLed.
[https://softwareengineering.stackexchange.com/questions/2603...](https://softwareengineering.stackexchange.com/questions/260347/ship-
of-theseus-applied-to-gpl-can-i-relicense-my-program-if-i-replace-all-of)

~~~
chubot
The GPL relies on copyright as far as I understand.

The two declining authors don't have copyright on the new replacement code,
because they didn't write it. So their choice of license can't possibly have
any bearing on the license of the rest of the project.

A similar thing happened when the busybox maintainer forked the project to
toybox.

busybox is a GPLv2 project (not LPGL), and so all his contributions were
licensed as such. But he forked his own code to a Apache 2 License. He is able
to do that because he owns the copyright. But of course he can't relicense
code to which he doesn't own the copyright.

toybox isn't a derivative work of busybox in that sense. It's just a bunch of
code that someone wrote (and automatically gets copyright for), and chose to
license in a certain way.

Basically you get the copyright first, then you decide to license it. If it's
clearer to think about, the authors could have started a new project called
"Zacket" that's not a derivative work of Racket, as long as they own all the
copyrights. But the name doesn't matter here, and they can keep using
"Racket".

That's my understanding anyway.

~~~
kd5bjo
Does Racket use a DVCS? A git checkout involves making a copy of every
historical version in addition to the current one, so their code is still
being distributed. If a lawyer wanted to make trouble, they could argue that
the repository as a whole is a single work and thus must remain on the GPL.

~~~
zaarn
Each version presented by the VCS contains a copy of the GPL.

The GPL for Version 1 (example) would be presented if you checked it out and
if you check out Version 2 it's now an Apache 2 license. The license in each
case applies to the files in the VCS, a the GPL contains no special case for
access to previous or future versions of the same file under it's license
under the GPL license, neither does the Apache license and I doubt such a
clause would hold water.

------
giancarlostoro
>Did anyone say no?

>Two people declined to re-license their contributions to Racket.

Although it is entirely within their right, it baffles me why anyone would say
no. At the end of the day, it's still open source, and the more important bits
are still LGPL. I'm personally within that camp that prefers MIT licensed
code. I don't think forced freedom is truly freedom (thinking of the GPL
here).

Edit: I much rather have the right to allow others to copy over being forced
to allow everyone to copy even if I rework an entire project.

~~~
INGELRII
MIT style licenses provide 'snapshot freedom'. The code is a collection of
text files at one point of time.

GPL license is additionally a share agreement. If the code is also an valuable
asset that requires constant development, update and contributions to stay
alive, GPL can help with that.

I would personally would prefer GPL-license under organization that can sell
different licenses. If a company don't want to use GPL, they can buy
commercial license and developers get money.

~~~
mumblemumble
> I would personally would prefer GPL-license under organization that can sell
> different licenses. If a company don't want to use GPL, they can buy
> commercial license and developers get money.

At first blush that idea makes sense, but the problem there is that we've
already tried that, and it failed miserably.

I think that one fundamental problem that would need addressing is how to make
it not a PITA to administer, and a hassle for everyone involved: Maintainers
of small projects aren't necessarily looking to embark on a proper business
enterprise, contributors don't necessarily want to have to digest the
implications of the license, _nobody_ wants to figure out how royalties for
contributors would work - and with people potentially getting paid directly
for the software, that's going to be a much thornier issue to negotiate than
it is with the "closed source derivative works" thing that you get with
permissive licenses - and licensees don't necessarily want to deal with an
explosion of payments to manage.

I also suspect there's a sort of prisoner's dilemma from the business
perspective. If we all share some permissively licensed open source projects,
we can all come out ahead and achieve a very efficient pooling of development
resources. If someone wants to go dual GPL/commercial, though, it may well be
cheaper for me to implement my own version of the, say, 5% of some library
that I actually need, than it is for me to pay a commercial license fee for
the whole thing.

~~~
appleflaxen
you are building a straw-man version of an unworkable payment system.

it would be totally doable for the project to say

1) we are GPL licensed

2) if you can't use GPL we will sell you a license for $X

3) all proceeds go to the project.

4) if you contribute, you give us the right to do this, and retain the funds
that are generated.

Dual licensing really could be a silver bullet, but because nobody has done it
well (for some reason people want to use MIT + commercial), nobody understands
how powerful it could be.

~~~
mumblemumble
> 3) all proceeds go to the project.

This is the spot where I see it becoming a sticking point. What is "the
project"? For it to be an independent entity, you need to incorporate, which,
at the very least, costs money, and is therefore a huge barrier to taking this
route for a small project. And it's almost by definition a small project if
it's in a position to be making this decision. And if it's not an independent
entity, then "the project" is probably just a euphemism for one person's
pocketbook. Maybe with some pinky swearing layered on top. In any case, you've
also got an image problem, because a lot of people are going to be skittish
about a GPL/commercial model after what happened with MySQL and some of the
other open source projects that fell into Oracle's hands.

You could instead set up a legal entity that pools the resources of several
projects, and let it be the commercial vendor. That might even, in a parallel
universe, have been a plausible funding model for the FSF. But even there it's
probably tricky, because you still need to have some way of deciding what to
do with the surplus. Having once served on the board of a nonprofit, I can say
that that's tricky at the best of times, and it's probably only worse if
you're talking some sort of open source foundation, because open source
community members tend to get along like cats in a sack.

Long story short: While I never said that something like this was unworkable,
I do think that, given how badly it tended to work out when people were trying
to figure out how to make it work a couple decades ago, it would seem to be
much harder to get right than it initially seems.

~~~
afiori
> you need to incorporate, which, at the very least, costs money

A nice (maybe impossible or impractical) idea would be to sell commercial
licenses with eventual future payments.

As in the commercial license states an estimated price and a clause saying
that at any time (with some months of notice) the price will be set to
somewhere up to the estimated price. If the project chooses an higher price
then the licensee is free to not pay. This would also allow prospective
licensee to estimate future expenses and the project to estimate eventual
revenue.

------
wtetzner
_First, it is unclear how to apply the LGPL’s statement about dynamic linking
to a language like Racket, where macro expansion can copy code from libraries
to applications, and where applications are typically bundled with the Racket
runtime and libraries. Second, some organizations unfortunately are unwilling
to use software licensed under any variant of the GPL._

I wonder if this simplifies the Racket-on-Chez effort in any way as well.

~~~
samth
Racket CS works similarly to traditional Racket in this respect -- compiled
libraries still contain the results of macro-expansion and inlining from their
dependencies, and generated executables still bundle everything together in a
way that's not easy to re-link.

It's more the other direction that's a benefit -- traditional Racket makes
fundamental use of several pieces of LGPL software, such as GNU Lightning and
libgmp, but Racket CS does not use them and Chez Scheme is Apache-licensed.

------
CalChris
TL;DR

 _Why relicense?_

 _... First, it is unclear how to apply the LGPL’s statement about dynamic
linking to a language like Racket, where macro expansion can copy code from
libraries to applications, and where applications are typically bundled with
the Racket runtime and libraries. Second, some organizations unfortunately are
unwilling to use software licensed under any variant of the GPL._

The first, dynamic linking exception, could maybe be patched up with some
effort by FSF resulting in a new LGPL license. The second is more of a
developers voting with their feet thing.

~~~
pritambaral
> The first, dynamic linking exception, could maybe be patched up with some
> effort by FSF resulting in a new LGPL license.

The Common Lisp world already has something like this, the "LLGPL"[1], but
it's use is discouraged[1] because (among other reasons):

> 2\. In 2004, the Free Software foundation affirmed that "the LGPL works as
> intended with all known programming languages" and that "LGPL contains no
> special provisions for inheritance, because none are needed." There is no
> need for the linking and inheritance provisions that are in the [LLGPL].

1: [https://www.cliki.net/LLGPL](https://www.cliki.net/LLGPL)

------
nwellnhof
Why do projects dual-license under MIT and APLv2? All the additional clauses
of the APLv2 like patent protection are useless if you also license under MIT.

~~~
JoshTriplett
Consumers of the project can use either MIT or Apache-2.0, which means the
project is compatible with GPLv2 code.

Contributors contribute their code granting permission to use under both
licenses, which means they're granting the patent grant in Apache-2.0.

So, dual-licensing MIT/Apache-2.0 gives you a permissive license with a patent
grant and GPLv2-compatibility.

That said, if you want a permissive license with a patent grant and
GPLv2-compatibility, a simpler choice is the "BSD+Patent"
[https://opensource.org/licenses/BSDplusPatent](https://opensource.org/licenses/BSDplusPatent)
license, which is just 2-clause BSD plus the Apache-2.0 patent grant.

~~~
Conan_Kudo
It's a pretty bad licensing arrangement, actually. I'm honestly surprised the
Racket community didn't consider just adding a license exception to the LGPL.

Alternatively, ASL 2.0 with exceptions could have worked to make it compatible
with the full assortment of GNU licenses. That's the strategy that CUPS and
LLVM chose.

This weird MIT/ASL 2.0 thing (which clearly was stolen from Rust) is a
completely asinine idea, because it forces a situation where it's impossible
to verify a patent license grant to users and contributors.

