Forgejo changes license to GPLv3+ [LWN.net]

The Forgejo project has announced that, starting from version 9.0, Forgejo will be released under the GPLv3 license (or a later version). Older versions of the software forge remain MIT-licensed.

A copyleft license makes reusing other copyleft software easier. Recently, we discovered that some of the dependencies we used were incompatible with the license Forgejo was distributed with, and they had to be removed for now. Choosing copyleft licenses enables us to reuse more work, and saves us precious time to focus on improving Forgejo itself.

to post comments

Mit is incompatible with GPL? That's news to me!

Posted Aug 23, 2024 16:58 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

Surely they've got things arse about face? A permissively licenced project can include copyleft licenced dependencies!

Okay, you really should have a warning that copylefted code is included, but that's no reason to change a permissive project to a copyleft one. Provided the dependencies are built separately, and create separate binaries, there's no problem in any direction.

And using a copyleft licence does NOT make using other copyleft software easier. After all, you can't mix GPL2 and GPL3, MPL had to fix its problems combining with GPL (there's a special clause in v2 that explicitly permits using the GPL2+ instead ...). I'm sure there's plenty more examples (the licence of ZFS, for example). This whole thing seems symptomatic to me of people who don't actually understand copyright, and are fixing one problem by creating another.

Cheers,
Wol

Mit is incompatible with GPL? That's news to me!

Posted Aug 23, 2024 17:38 UTC (Fri) by pizza (subscriber, #46) [Link]

> Surely they've got things arse about face? A permissively licenced project can include copyleft licenced dependencies!

Um, from TFA (which I'm sure you read before commenting) there were three problematic dependencies identified:

* vue-bar-graph, which depends on GSAP, which isn't Free _or_ OpenSource(tm) due to field-of-use restrictions.
* citeproc-js, under the CPAL (a MPL derivative) or AGPL
* elkjs, under the Eclipse license.

Even before their switch to the GPLv3, the latter two were problematic as the combination effectively made the entire project AGPL.

> This whole thing seems symptomatic to me of people who don't actually understand copyright, and are fixing one problem by creating another.

On the contrary, it shows they're (now) paying attention to their bill of materials, and that they're aware of the problems inherent in mixing licenses that are overtly (or merely subtly) incompatible.

Meanwhile, TFA also explained their reasons to switching to GPLv3 going forward, and why it matters (to them).

Mit is incompatible with GPL? That's news to me!

Posted Aug 23, 2024 20:51 UTC (Fri) by randomguy3 (subscriber, #71063) [Link] (1 responses)

I think this is confusing the license of the individual source files / contributions to the project with the license the software as a whole is distributed under - this change is about the latter.

It's worth noting that neither the linked article nor the LWN summary at any point say that the MIT and GPL licenses are incompatible. The only use of the word "incompatible", in fact, is in the pull-quote: "some of the dependencies we used were incompatible with the license Forgejo was distributed with". If you follow that link, you'll find that the dependencies mentioned were a non-free license that prevented charging, the AGPL and the EPL.

Admittedly, both the pull quote and older article about those dependencies describes those licenses as "incompatible with the license Forgejo was distributed with" - that's perhaps confusing wording if you're used to how "license compatibility" tends to be used (ie: is it possible to distribute code that contains components with these two licenses at all?). In this case, they mean something subtly different: is it possible to distribute code that contains components with these licenses under the stated license of Forgejo (ie: MIT at the time)? And the answer is clearly "no" - the distributed project as a whole would no longer be "MIT".

Hence the change to GPL3, which is a viable distribution license for a project that contains both MIT and GPL3 code.

Mit is incompatible with GPL? That's news to me!

Posted Aug 23, 2024 20:55 UTC (Fri) by randomguy3 (subscriber, #71063) [Link]

It's also worth noting that Forgejo, as a web application, is in a very different situation wrt copyleft vs permissive licenses than a library or other project that is intended to be integrated into a large piece of software (like ZFS). Forgejo moving to GPL3 opens up using GPL3 contributions and dependencies, but it will not end up imposing constraints on downstream projects in the same way (in the normal expected use of Forgejo, unless those downstream projects are just modified versions of Forgejo).

Stick to gitea

Posted Aug 24, 2024 9:19 UTC (Sat) by domdfcoding (guest, #159754) [Link] (12 responses)

Yet another reason not to use it. Not that I switched from gitea to begin with.

I suppose the saving grace is it hasn't gone the way of Elasticsearch.

Stick to gitea

Posted Aug 24, 2024 9:51 UTC (Sat) by intelfx (subscriber, #130118) [Link] (8 responses)

> Yet another reason not to use it.

Huh?

Stick to gitea

Posted Aug 25, 2024 21:23 UTC (Sun) by misc (subscriber, #73730) [Link] (7 responses)

Well, the main reason behind the license change was to make sure the code do not flow back to Gitea. The Forgejo project was forked after one contributor got rejected when he tried to start a company for hosting gitea instance, so I do think he is holding a grudge.

Let's see the history:

He proposed that on feb 2022:
https://forum.gitea.com/t/a-gitea-hosting-service-under-t...

No one followed the idea after proposing to 4 people:
https://blog.dachary.org/2022/03/11/the-inconclusive-stor...

So he decided to start his own hosting company in July, which is fair:
https://blog.dachary.org/2022/07/21/hostea-a-seed-to-crea...

Then Gitea Inc. happened in October:
https://blog.gitea.com/open-source-sustainment/

Then drama erupted with another contributor just after:
https://forum.gitea.com/t/gitea-contributor-feedback/4630

At the time, he started to be suddenly annoyed (and that's the tame version of the blog post, there was one much harsher that got removed IIRC):
https://blog.dachary.org/2022/10/31/the-gitea-ltd-sustain...

He was also very unhappy because his wikipedia page was removed: https://blog.dachary.org/2022/10/22/please-remove-my-wiki...

Then forgejo was created, slowly moving to be a full fork while saying the contrary, under the pretense of "we do that for the federation":
https://lwn.net/Articles/963095/

first "soft fork", then "hard fork", then adding a random GPL v3 so the code no longer flow in the other side, the setup is complete. Of course, Federation is not here, even after working on it since 3 years. (and spending 50k from NGI without any tangible results).

The commit that add GPL v3 was pushed by a account of the name "earl warren", obviously a fake name. Looking more closely, you can see the account was mainly relaying commits from one person to github, and that the account also followed the coder who forked Gitea. It doesn't take too much research to see who is behind the nickname. I mean, if you try to hide your identity with a new domain and a new email, maybe you should make sure to mask the right info on whois:

$ whois earl-warren.org | grep -i Dachar
Registrant Organization: Dachary

That's not the 1st time it happened, because if you look closely, there was the same setup on the gitea github org, with silentcodeg on github using a obscure domain that is linked to the same coder. You can get the email here
https://github.com/go-gitea/gitea/pull/19883 and search the domain on http://ftp.proxad.net/mirrors/CPAN/modules/by-authors/00w... , some pattern start to emerge.

This account added themself to the maintainer list (and so had access to vote, etc) just before another suspect account started to complain about issue with the same designer as in October 2022:
https://github.com/go-gitea/gitea/pull/19771

(I let as a exercice people the treasure hunt to find the link between this account and the main forker, but as a hint, if you craete a sockpuppet mastodon account, you shouldn't create it on your personal server unless you want people to link it trivially to you , cf https://stackoverflow.com/users/10893885/singuliere )

So yeah, plenty of reasons to find suspect stuff when you know the history. I am not super thrilled by the risk of opencore with gitea inc as a user and occasional contributors, but at least, I know that the company and the project are sustainable. I can't say the same about a community built on lies and revenge.

Stick to Gitea?

Posted Aug 25, 2024 23:40 UTC (Sun) by fnetX (guest, #173087) [Link] (2 responses)

Hi there! I respect your decision to stay with Gitea, and I do believe that there are valid reasons to do so – including disagreement with our license change.

However, I disagree to your analysis of Forgejo being built on "lies and revenge".

I'm the executive director of Codeberg e.V. and was involved with Gitea before and with Forgejo since the fork, investing my free time almost daily to improve it. I cannot comment on the claims and suspicions you share, and I'm not interested to think about them further.

And it is not even necessary, because neither the problems we had with Gitea, nor the success stories of Forgejo are invalidated by them. We are a community of people, most of them unhappy about something with Gitea in one way or the other, and so we have established a transparent and open decision-making process at Forgejo that I believe few projects have: https://codeberg.org/forgejo/governance/

The move to a copyleft license was not motivated by preventing Gitea to take our commits. But since our efforts to upstream some of our changes got more difficult over time anyway, it stopped being a blocker to stay MIT-licensed. To my knowledge, Gitea never took patches from Forgejo on their own, it was always coupled with an effort on our end (which can be fine, but the commitment to do this ceased over time due to the different nature of the collaboration). Also note that the license change does not prevent upstreaming of patches in many cases (because not all the work is copyrightable, and contributors can often choose to submit the work under a different license unless the change builds on copyrighted GPL changes).

Forgejo delivers a very high release quality and we do things like browser and accessibility testing as well as user research that few free/libre software projects do (please tell me if you know of any, I'm looking for inspiring examples in these areas). This is possible because there is a community of people (see https://forgejo.org/2024-07-monthly-update/#we-forge for an impression), supported by more than 500 members of the non-profit Codeberg e.V.

If you want to keep thinking that this is one person doing all the work ... feel free to. Be careful not to get envious at what a single person can be allegedly capable of ;')

Stick to Gitea?

Posted Aug 26, 2024 14:28 UTC (Mon) by mattdm (subscriber, #18) [Link] (1 responses)

Do you intend to use or require a CLA, now or at any point in the future? If so, will that CLA reserve certain rights only for the corporate entity and not other contributors?

Stick to Gitea?

Posted Aug 26, 2024 18:58 UTC (Mon) by fnetX (guest, #173087) [Link]

Regarding CLA in Forgejo, there are no such plans (as in: I do not think anyone talked about such a thing at all), and I believe it would be very hard to find consensus for among all contributors (as per the decision-making process).

I do not know what you mean by "corporate entity", but probably Codeberg e.V. This sounds a little weird, because it is a non-profit and does not control the Forgejo project actively. Codeberg acts as an umbrella organization to ensure that crucial assets like the domain are not controlled by individuals, but are managed according to the decision-making process of Forgejo.

Stick to gitea

Posted Aug 26, 2024 4:12 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

… oh, wow. Thanks for sharing.

I’ll personally stick with gitweb, though, but… this is sufficient to make me discourage others from using Forgejo.

Stick to gitea

Posted Aug 26, 2024 6:06 UTC (Mon) by algernon (guest, #11573) [Link] (2 responses)

Hi! I am the person who submitted the first copyleft contribution to Forgejo (#4212, but relicensed to MIT due to time constraints and not wishing to wait until the copyleft discussion is resolved), and I was the one who revived the whole copyleft thing. It had nothing to do with code flowing back to Gitea (which stopped happening a long time ago, because prominent Gitea contributors explicitly declared they'll never approve anything originating from Forgejo), and nothing to do with Dachary, nor any grudge or revenge.

Stick to gitea

Posted Aug 27, 2024 22:21 UTC (Tue) by ohsnap (guest, #173127) [Link] (1 responses)

> prominent Gitea contributors explicitly declared they'll never approve anything originating from Forgejo

Was that a public discussion? I'd appreciate a link. Thanks!

Stick to gitea

Posted Sep 2, 2024 8:01 UTC (Mon) by algernon (guest, #11573) [Link]

There are no links I can provide by now, nor would I wish to. That ship has sailed, and we moved on.

Stick to gitea

Posted Aug 24, 2024 9:56 UTC (Sat) by yeltsin (guest, #171611) [Link] (1 responses)

As a long time Gitea user, I welcome this change, and it might finally push me towards it. With GPL and no copyright assignment, it has a much higher chance of staying truly open. Remember the reason for why this fork was created, the danger of Gitea becoming proprietary (or "open core") is still with is, and its license doesn't do anything to prevent that.

I'll be looking a both and will probably stick on 1.22 for some time because it's the last supported release which you can easily migrate to Forgejo. Right now it's really not obvious which one is gonna "win": judging purely by the number of commits, Forgejo is way more active, but a good third of them are merges, which Gitea doesn't use.

Stick to gitea

Posted Aug 24, 2024 12:35 UTC (Sat) by laf0rge (subscriber, #6469) [Link]

When the strange sale of gitea trademark/domains and the announcement of "open core" happened, I was rather disappointed, but luckily forgejo happened to continue as a true FOSS project, in collaborative fashion, without a commercial entity owning it.

I've been pondering to switch three gitea instances to forgejo basically ever since the fork, and mostly postponed due to not having the time to deal with potential fallout. I switched a few weeks ago, and luckily everything went smooth.

I personally am almost always in favour of copyleft licenses without centralized copyright (no CLA, no assignment) as that means the project has a robust defence against "open core" models as well as against proprietary forks.

So all the best to forgejo for their decision to go for GPLv3. Keep up the good work!

Stick to gitea

Posted Aug 26, 2024 14:23 UTC (Mon) by mario-campos (subscriber, #152845) [Link]

I quite like sourcehut (https://sourcehut.org/) for its minimal take on source-code hosting.

No background

Posted Aug 24, 2024 12:49 UTC (Sat) by alfille (subscriber, #1631) [Link] (7 responses)

The LWN announcement doesn't explain what Forgejo is, which would be helpful for the uninitiated.

To be fair, the Forgejo website is pretty, but rather uninformative as well. No screen shots, no architecture, no description of workflow or really features.

No background

Posted Aug 24, 2024 19:52 UTC (Sat) by laf0rge (subscriber, #6469) [Link] (6 responses)

https://lwn.net/Articles/963095/ should provide some background?

No background

Posted Aug 24, 2024 19:55 UTC (Sat) by laf0rge (subscriber, #6469) [Link] (5 responses)

Also, the fogejo website has a demo instance linked that you can use. I guess that's more illustrative than screenshots? https://v8.next.forgejo.org/

But yes, I agree, I guess their focus has primarily been on documenting differences to gitea, and assuming that most people who end up looking at forgejo have seen gitea before.

No background

Posted Aug 24, 2024 22:21 UTC (Sat) by alfille (subscriber, #1631) [Link] (4 responses)

Thank you. Very helpful links.

My point was more that these announcements with opaque project names and no context could be improved.

No background

Posted Aug 25, 2024 6:33 UTC (Sun) by vasvir (subscriber, #92389) [Link] (3 responses)

I also think that 4-5 parenthesized words about the project in question would be helpful.

I have completed a transition from subversion/trac to gitea 18 months ago. Naturally I spent some time evaluating the landscape. At the time the Forgejo fork was new so I finally selected gitea. I track gitea releases and updates from then.

Maybe 6 months earlier I met Forgejo again (probably in LWN). Having forgotten completely what it was I read about it until I remembered. !!!Oh that fork!!! OMG should I move again?

Now I saw the Forgejo in this post again and I still had to look it up again.

So if somebody heavily invested in gitea keeps forgetting what Forgejo is I believe other people would benefit too.

PS: I believe the problem is the name. My scanners do not pickup Forge inside Forgejo. It should have been named ForgeGo since it is a forge written in go. But then again I am coming from simpler times...

No background

Posted Aug 25, 2024 8:24 UTC (Sun) by intelfx (subscriber, #130118) [Link]

> I believe the problem is the name. My scanners do not pickup Forge inside Forgejo. It should have been named ForgeGo since it is a forge written in go. But then again I am coming from simpler times...

Forgejo is Esperanto word for "forge". It's not a typo, there was no intention to include "go" in the name.

No background

Posted Aug 25, 2024 9:00 UTC (Sun) by yeltsin (guest, #171611) [Link] (1 responses)

This has been discussed before, but I'm with you. The name is unpronounceable and meaningless to (at least some) speakers of non-Romance and non-Germanic languages. It's probably no coincidence that both Gogs and Gitea have short and simple names, and were led by several Mandarin speakers.

If I move the $DAYJOB server to it, I'll have to come up with a generic name for it, because no one will remember or be able to say "Forgejo", and the word "forge" has not yet been borrowed. It's not really a big problem, just an observation.

At least it's not something boring and sterile like GitHub or GitLab...

No background

Posted Aug 25, 2024 12:35 UTC (Sun) by dskoll (subscriber, #1630) [Link]

Here's a mnemonic: "I always ForgeGit what Forgejo is!"

Utter FUD

Posted Aug 26, 2024 4:09 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (18 responses)

> A copyleft license makes reusing other copyleft software easier.

This is utter FUD and nōnsense.

If they have a licence incompatibility between different dependencies, they can solve that at that level while sticking to a Ⓕ copyfree licence themselves.

This is a hostile move.

Utter FUD

Posted Aug 26, 2024 8:37 UTC (Mon) by zorro (subscriber, #45643) [Link] (15 responses)

How can they incorporate GPL software without themselves being GPL?

Utter FUD

Posted Aug 26, 2024 9:35 UTC (Mon) by mb (subscriber, #50428) [Link] (1 responses)

Permissively licensed code doesn't automatically become GPL'ed, if you add GPL code to the codebase.

Of course, if you want to distribute the whole thing, you can effectively only do that under GPL terms.
But the permissively licensed parts can be distributed separately under permissive license.

Utter FUD

Posted Aug 26, 2024 15:24 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Yes. This, exactly.

And (I had a conversation with algernon on Fedi about this) this is apparently exactly what happened, the LWN article was misleading because the blog post was unclear.

Utter FUD

Posted Aug 26, 2024 11:10 UTC (Mon) by Wol (subscriber, #4433) [Link] (12 responses)

To rephrase mb and the GPL ...

You are not allowed - by law - to change someone else's grant of licence. So if you re-use someone else's liberally licenced code, that code STAYS liberally licenced.

If you write some code and GPL it, and mix it with liberally licenced code, your code is GPL'd, the other code is still liberal.

The GPL provides a guarantee that any code that is mixed with it, MUST have its conditions satisfied if you comply with the GPL. So anybody who distributes your project (that has mixed those codebases) can ONLY distribute it, if the liberal conditions are a subset of the GPL conditions (or is it the other way round? never mind...).

The ONLY licence I know of, that gives you permission to actually change the licence, is the MPLv2, which says "you can relicense this code as GPL2+". Even then I'm not sure if it's actually letting you relicense it, or it's more the equivalent of the GPL grant of licence which - in the "+" versions - doesn't actually allow you to relicense it, it just allows you to choose a licence from a restricted list.

So in this sort of scenario, the compiled executable would be GPL, because that's the only way to comply with the relevant licence conditions on the executable work, but all the source files can be a complete mix of (GPL compatible) licences, because they are separate works covered by their own licences.

Cheers,
Wol

Utter FUD

Posted Aug 26, 2024 12:13 UTC (Mon) by intelfx (subscriber, #130118) [Link]

> but all the source files can be a complete mix of (GPL compatible) licences, because they are separate works covered by their own licences.

That is, _if_ they are separate works.

Utter FUD

Posted Aug 26, 2024 14:04 UTC (Mon) by paulj (subscriber, #341) [Link] (9 responses)

What if you take permissively licensed code, and adapt that code so it depends on the APIs of a GPL library? Such that it can not compile, never mind run, without the GPL library?

Utter FUD

Posted Aug 26, 2024 15:27 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (8 responses)

@intelfx: it’s common courtesy and generally accepted that, in a codebase mixing permissive and copyleft, that the files bearing *only* the permissive licence may be reused under just that, and that people normally put the copylefted code into separate files, or clearly separate regions of the file for languages like Java that require things to be in one file, or licencing the parts that touch these files permissively (as well), instead of mixing it in and adding a copleft licence header that then applies to the entire file (replacing is not permitted anyway… unless you’re the rights holder, in which case anything goes in theory).

@paulj: then someone writes a libedit to your libreadline. APIs are a licence barrier even for strong copyleft.

Utter FUD

Posted Aug 26, 2024 15:35 UTC (Mon) by paulj (subscriber, #341) [Link] (7 responses)

What if the library is a lot more complex than readline, and there are no clones? Indeed, the library has no stable interface, and details regularly change?

APIs are not a concept in law, and I don't think they are of - of themselves - of significance legally (either way). Even in technical terms, the term API is hard to define precisely - does an .so that deliberately is kept unstable to avoid giving applications the idea they have an interface to rely even have an API?

Utter FUD

Posted Aug 26, 2024 16:37 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (6 responses)

APIs are indeed recognized as having special properties in law. See Google v. Oracle, the amicus brief that the FSF itself wrote in that case, and the ultimate decision of the court.

(Obviously, this is US-specific. But the big tech companies are American, so in practice, we all need to care what the US thinks of software copyright in addition to our local laws.)

Disclaimer: I work for Google, but my job has nothing to do with Android or any other part of that case.

Utter FUD

Posted Aug 27, 2024 9:35 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

That's not the same thing though is it?

The case you cite is where there were 2 entirely separate implementations: The original Sun JDK, and the Apache Harmony derived code in Android. The code at issue was 0.4% of the entire code-base, and largely not copyrightable cause it was declaring facts.

Again, if a permissively licensed work is written to rely extensively on a GPL work for its compilation, comprehension and function, can that still be a permissively licensed work? What about if the GPL work is an .so, and if the declarations of its function calls are deliberately regularly changed - they are unstable? That a small portion of the GPL work could be considered an organisational, or declarative of facts about the interface to the GPL work (i.e. the API) does not make the rest of the GPL work lack creativity or copyright, does it?

A case where 1 work does /not/ (in any substance) rely on the code of another work, hardly speaks to the case where 1 work /does/ rely in substance on the code of another work, does it?

Utter FUD

Posted Aug 27, 2024 10:17 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (4 responses)

It’s not a function of something being in a .so or whatever, it’s a function of whether it’s a derivative work. Don’t look at lawyer problems with a technician mindset, it’ll just make you crazy.

Writing to an API boundary is normally sufficient, at least in Europe. If you muddy this up (no stable API, or whatever), things get interesting for the lawpeople. Don’t bother with it ahead of time, and avoid doing it.

Utter FUD

Posted Aug 27, 2024 10:49 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

> It’s not a function of something being in a .so or whatever, it’s a function of whether it’s a derivative work. Don’t look at lawyer problems with a technician mindset, it’ll just make you crazy.

Well exactly. That is my point that I've been trying to lay out.

These technical details do not matter in the way technical people think they do. They do not transpose to how the lawyers and judges look at things. The latter 2 look at stuff in terms of creativity and what /is/ copied, and fair use and transformation, etc. (I don't claim to know how those concepts work - only that these are things clearly most technical people don't understand).

The technical person looks at Oracle v Google and sees judges considered declaration files to be not copyrightable in that case, thinks "declaration files? Oh, so API? So that's a 'barrier'!" and has just invented a concept in their head based on their technical view, that simply never existed in those legal minds.

Utter FUD

Posted Aug 27, 2024 11:11 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (2 responses)

Right… with the exception of the EU interoperability directive, which is a copyright barrier, and “fair use” being a purely american concept.

Utter FUD

Posted Aug 27, 2024 11:27 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

"Fair dealing" exists in a number of legal systems derived from the English system.

Utter FUD

Posted Aug 27, 2024 17:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Unlike fair use, fair dealing is an enumerated set of ways you're allowed to use copyrighted works without explicit permission of the rights holder. In the UK, at least, it provides no additional freedoms around software other than arguably under some limited cases for research and study.

Utter FUD

Posted Aug 26, 2024 16:34 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> So if you re-use someone else's liberally licenced code, that code STAYS liberally licenced.

This is true, but it is also misleading. The MIT license explicitly authorizes recipients to "sublicense" the software. Sublicensing, in this context, means (in simple terms) slapping your own license on top that offers the recipient a subset of the rights you received from upstream. You do not need to modify the software at all in order to do this, so you don't have to e.g. add a GPL component. You (presumably) do need to preserve the MIT license itself, but you can put terms on top of it that say it is provided for information purposes only and does not apply to your downstream recipients.

Of course, your downstreams can always bypass you and get the original straight from the source, if such a source still exists anywhere on the internet.

Utter FUD

Posted Aug 28, 2024 11:38 UTC (Wed) by gmgod (guest, #143864) [Link] (1 responses)

> This is a hostile move.

Nope. The only people who are affected are contributors and people who want to fork the project.
So yeah, if you had a GPL-dependency-free fork you wanted to release with your closed-source modifications, this move is detrimental to you... The one and a half of you in the whole world!

Utter FUD

Posted Aug 28, 2024 22:01 UTC (Wed) by mirabilos (subscriber, #84359) [Link]

Moving an existing codebase to a more restrictive licence is always a red flag.

But, see the other replies in the thread, this is apparently not what happened, the blogpost was vague enough to mislead the LWN article author.