Fossil Forum

GPL vs BSD in "Fossil vs Git" article
Login

GPL vs BSD in "Fossil vs Git" article

GPL vs BSD in "Fossil vs Git" article

(1) By Warren Young (wyoung) on 2019-07-12 04:56:46 [link] [source]

I believe the current "GPL vs BSD" section in the Fossil versus Git article is wrong on several counts:

  1. Nothing stops you from reading GPL code. Copyright law stops you from writing it back down from memory, and the GPL stops you from distributing binaries based on that regurgitation, but this is not a serious consideration in the question of GPL vs BSD, especially not if our actual focus is "Fossil vs Git."

    The bit about making GPL code easier to write is also not correct. The actual focus should be on re-distribution, not writing.

    Even with that nit set aside, the "harder to read" bit remains fully undermined, so I don't see a good reason to continue couching the comparison in terms of reading vs writing. It's a specious comparison.

  2. Nothing requires you to give back enhancements to GPL code if you don't distribute the binaries. This is why the AGPL was created: to close the hosted web service loophole.

  3. The correlation between CLAs and BSD licensing is extremely loose. Many GPL-based projects require CLAs (e.g. MySQL) and many BSD-based projects do fine without them (e.g SIMH). There's even a CLA of sorts in the Git project's "submitting patches" document!

Therefore, I've rewritten this section from an entirely different basis, which I think is clearer and gives a fairer comparison of the two licenses while keeping a focus on how this affects Fossil vs. Git. We don't need to make an extended contract law course here, and we don't need to re-fight the GPL vs BSD holy wars. We just need to explain why we think the license difference affects the design, behavior, and use of Fossil.

This is on a branch so we can discuss this and polish it before merging it down to trunk.

Comments, complaints, contributions?

(2) By Stephan Beal (stephan) on 2019-07-12 05:42:54 in reply to 1 [link] [source]

Designed for Linux kernel development vs Designed for SQLite development

i know that's not a change of yours, but i think that should more explicitly note that the difference between those (for purposes of this comparison) is essentially one of scope/scale.

so that it can legally relicense them to those who do not wish to be subject to the GPL, usually for a hefty fee

The "usually for a hefty fee" comes across as speculative, and somewhat bitter, to me. A company's justification for a CLA isn't in question, is it?

Such projects often require a CLA even when there is no corporate overlord or commercial-use relicensing option.

Do you mean "often require" as in:

  • It's a common that "such projects" require a CLA as a consequence of using BSD. Or...
  • It's a common occurrence for reasons unrelated to the use of the BSD license.

?

The greater necesity for having a CLA in a BSD-licensed project makes signing up new contributors harder.

i recommend making that a bit less absolute:

The greater necesity (sic.) for having a CLA in a BSD-licensed project tends to make signing up new contributors harder.

Though i agree entirely with your characterization, i don't think we have any hard facts which can back that up. My rule of thumb is: "when unable to provide hard proof/citations, word it like someone from the Marketing or Sales Departments would." i.e. as vague and non-committal as possible while still sounding like it says something.

whereas Fossil encourages a more tightly collaborative, cliquish, cathedral-style approach more typical of BSD-licensed projects.

LOL! i don't disagree with that, but use of the word "cliquish" is funny. (That's from the original copy, apparently.)

(3) By Warren Young (wyoung) on 2019-07-12 14:22:30 in reply to 2 [link] [source]

i think that should more explicitly note that the difference between those (for purposes of this comparison) is essentially one of scope/scale.

That's done now. I don't think this change is controversial, so I did it on trunk and then merged it up into the branch. The most controversial bit is the analogy I added at the end; I think it helps, but maybe it's a reference some just won't get. If someone has a better analogy, let's hear it.

A company's justification for a CLA isn't in question, is it?

It is in question when the GPL is being used as a prod to push other companies towards the commercially-licensed version of the product. The subtext of these commercial license buyout pages are often quite clear: "You don't want your company tainted by that nasty viral GPL, do you? Better buy our non-FOSS version!"

I've toned the language in this section down a bit, but since I'm coming up dry on alternative reasons why a for-profit company would choose the GPL and then require a CLA before accepting contributions to its code repo, this is the only thing I can offer here at the moment. Give me other reasons why GPL + CLA would make sense, and we can talk about how that affects the section.

The GPL alone says, "No one can take your free software contributions and make them proprietary." A company that requires you to sign a CLA before contributing to a GPL-based product is saying, "Yeah, we're totally going to do that."

Contrast a BSD style license, where there's no promise to the contributor that someone won't make a proprietary product out of their freely-given work in the first place. If such a project requires a CLA, they didn't do it in order to allow them to make a proprietary version of your work.

I went through the list of projects given on the Wikipedia page for CLAs as examples, and all but one are either using non-GPL licenses or they have a commercial version that isn't GPL-licensed. That lone exception is openmediavault, but among the reasons given on their CLA page for why they require it, it is to "...enable alternative licensing models." In other words, "Yeah, we're totally trying to make this a commercial product, we just haven't worked out the business details yet."

A close second behind that is Cyanogenmod, which was also trying to go proprietary before the project imploded.

Do you mean "often require" as in...

The next sentence gives the justification, but since it must not be communicating its point clearly, I've joined the two sentences.

i recommend making that a bit less absolute:

Done.

i don't think we have any hard facts which can back that up.

See the new text. The analogy with physical friction is apt, I think.

I considered another analogy to activation energy, but I decided that would be less clear.

use of the word "cliquish" is funny

...and probably inaccurate. I don't feel like I'm in a clique here. I think software developers tend to be too idiosyncratic to be in any clique. A better way to word it isn't coming to me immediately, and I'm running out of time here, so I think I'll just let it sit. Maybe I'll come up with something later, or maybe someone here will rewrite it for me.

(4) By Stephan Beal (stephan) on 2019-07-12 14:36:58 in reply to 3 [link] [source]

The most controversial bit is the analogy I added at the end; I think it helps, but maybe it's a reference some just won't get. If someone has a better analogy, let's hear it.

Sounds fine to me. It brings to mind MTV's old "Celebrity Deathmatch" show :). In this match: D. "Richard" Hipp vs Linus "2.0" Torvalds! i'd buy a ticket.

Give me other reasons why GPL + CLA would make sense, and we can talk about how that affects the section.

i agree entirely with what you're saying here (also regarding the "hefty fees"), i just don't think it's our business to come across as judging them for it. "We all know" why they do it, certainly, but "that's neither here nor there" for purposes of that particular page. It would be, IMO, in straight-out GPL vs BSD discussion, but that's a religious topic possibly better left for a different wiki page, to avoid diluting the fossil-vs-git debate into a licensing debate (that section is now the longest in the document, surpassing even the "Database" section).

The analogy with physical friction is apt, I think.

Absolutely.

i think the only nitpick i'd offer now is:

Such projects often require a CLA even when there is no corporate overlord or commercial-use relicensing option

"is no corporate overlord" ==> "are no corporate interests"

Simply to keep the language more neutral.

:)

(5) By Stephan Beal (stephan) on 2019-07-12 14:49:03 in reply to 4 [source]

i think the only nitpick i'd offer now is:

Okay, i found one more but it's admitted 100% a personal style thing, and not necessarily something which needs changing:

You don't use a pneumatic ratchet wrench to hang a picture on the living room wall.

When article authors write "you", i often take offense at what they say: "you'd be surprised at how often so-and-so happens...", "what you don't know is...", or "you've never experienced anything like it!"

They have no business presuming to know what my level of surprise, knowledge, or experience may or may not be. Statements from 3rd parties starting with "you will/are/should/shouldn't/have/haven't..." almost always come across as suspect to me, and in my own writing strive to reword them to avoid any presumption of any "absolute knowledge" about the "you" at the other end of the document (going so far as to go out of my way to avoid that word entirely).

With that in mind, my personal preference (and only a personal style preference) would be something along the lines of...

A pneumatic ratchet wrench is arguably not the best tool to hang a picture on the living room wall.

Again: that's just a point of personal preference, not a need-to-change.

(6.2) By Warren Young (wyoung) on 2019-07-12 14:56:35 edited from 6.1 in reply to 4 [link] [source]

D. "Richard" Hipp vs Linus "2.0" Torvalds!

I was talking about the reference to rattle wrenches. Even with the just-added Wikipedia link, I don't have a clear sense of whether that analogy helps or confuses. I know it's a very bad plan to hang a picture with a rattle wrench, but is that clear to most other readers? Does everyone else imagine a big old air tank, a few dozen feet of hose, hundreds of dollars of equipment, and a lot of noise when they read that analogy? Are they mentally cringing at the imminent prospect of cracked plaster from an M8 socket-cap screw being driven in 4 inches in a quarter second when it would have been better to take 10 seconds and several gentle taps to drive a finishing nail in 3/4 of an inch instead?

i just don't think it's our business to come across as judging them for it.

All right, I'll rethink this. Out of time now.

no corporate overlord

Done.

A pneumatic ratchet wrench is arguably not the best tool to hang a picture on the living room wall.

I've applied that, more or less. The underlying text had change since you composed that alternative, and I don't see the need to say "arguably" here; no one does this, even if they do have a rattle wrench.

(7) By Warren Young (wyoung) on 2019-07-12 15:31:00 in reply to 6.2 [link] [source]

I think I've distilled the GPL + CLA issue down to the essentials needed to support the "Fossil vs Git" argument now.

(28) By John Rouillard (rouilj) on 2022-03-20 18:20:09 in reply to 7 [link] [source]

I realize this is late. IANAL, but I thought one reason for the CLA is to have a single entity that owns the entire product's code and can represent the code in court. Without this asserting a GPL violation as the aggrieved party is more difficult.

Assume lines 20-45 in file foo.c were written by me and given to the project. As I understand it, they have no standing to sue if those lines of code are not made available. With a CLA where I turn over ownership/defense of the code I wrote to the project that hurdle is cleared.

(The hypothetical above is meant to be illustrative and will probably make a lawyer cringe.)

(30) By aue oiae (cregox) on 2022-03-24 04:41:25 in reply to 28 [link] [source]

seems to me like a trivial issue for agpl/full. 🤣

then again, i can always fool myself and pardon myself later on. 🤤

(8) By Richard Hipp (drh) on 2019-07-12 16:11:50 in reply to 1 [link] [source]

Since the GPL vs BSD section of the document is controversial, why not just delete that whole section. It is not essential to the overall text. It is a bit of an afterthought. We can do without it.

(9) By Warren Young (wyoung) on 2019-07-12 16:22:33 in reply to 8 [link] [source]

Although "GPL vs BSD" is controversial, I think that section is trying to get at a relevant point: because you chose a 2-clause BSD license, and because you decided a CLA was a good idea for this project, there are knock-on effects that affect the way the projects are implemented, which in turn affects one's choice of which DVCS they'd rather use.

As I said in the first post, I don't think we should get into the merits of the two licenses in our "Fossil vs Git" argument. Stephan's comments about being less judgemental are correct, and they've resulted in changes to the text which improve it and keep it sharply on-point.

We should probably all sleep on this at least one more night before it gets pushed to trunk.

(10) By Warren Young (wyoung) on 2019-07-12 16:34:11 in reply to 9 [link] [source]

I've tightened this up some more. Give it another look, please.

(11) By Warren Young (wyoung) on 2019-07-12 16:47:17 in reply to 10 [link] [source]

What if we merge the "GPL vs BSD" and "Cathedral vs Bazaar" sections? They're mutually repetitive.

If we do this, does the license stuff move up, or the CatB stuff move down?

(15) By Warren Young (wyoung) on 2019-07-14 11:08:41 in reply to 11 [link] [source]

I've decided that what we need is actually a broader idea: Both the licensing issue and the development organization style are really sub-parts of the "Linux vs SQLite" issue. That new section also contains a new "Scale" section holding what remains of the old "Linux vs SQLite" section after removing the bits that are already covered in the other two.

This leaves the development organization as the first and most important sub-section, since it has the greatest effect on the design and low-friction usage path of Fossil. This is followed by the scale issue, which is also an important consideration. That is then followed dead last by the licensing issue, which I still believe to be important, but the least of these sections.

Because the first two sections are important, I decided that this requires the licensing stuff to move up, rather than push this important stuff down so that the licensing stuff can remain near the end of the doc.

I've cut more fat out of the licensing section in this checkin. I don't see anything else I can cut without hurting the message.

(16) By Stephan Beal (stephan) on 2019-07-14 11:28:24 in reply to 15 [link] [source]

i like it :).

i'm not asking you to change this one sentence:

When deciding between these two DVCSes, you should ask yourself, "Is my project more like Linux or more like SQLite?"

but, just for demonstration's sake, am showing how one can often get rid of personal pronouns through reformulation:

A significant consideration when deciding between these two DVCSes is, "Is my project more like Linux or more like SQLite?"

Some authors use "you" to good effect (Scott Meyers (the C++ guru) comes to mind), providing a sense of engagement with the reader, but i'm not someone who can pull that off.

(Really: don't change it.)

(14) By Stephan Beal (stephan) on 2019-07-12 21:04:44 in reply to 10 [link] [source]

I've tightened this up some more. Give it another look, please.

i haven't looked into the merging of sections, but like what you've done with the license section.

(12) By sean (jungleboogie) on 2019-07-12 17:22:48 in reply to 8 [link] [source]

I agree with this.

It was not too long ago when the Internet was on fire with your sqlite CoC stance. Because of who you are, your philosophy and religion, you listened to the critics and updated your CoC and put in place some ethics. I don't think we need another fire over a software license.

Unless you're brand new to software licenses, the BSD vs. GPL vs. AGPL vs. Apache, etc debate is pretty much settled. It's no mistake why a particular project chooses a certain software license. I don't know of another project that would have an entire page discussing their reasons for a software license. (though they may exist).

Maybe the whole page can be replaced with something like this: Fossil is licensed under the BSD software license. Learn more about it here: https://tldrlegal.com/license/bsd-3-clause-license-(revised)

(13) By Warren Young (wyetr) on 2019-07-12 17:48:55 in reply to 12 [link] [source]

It's not a whole page, it's one section in a document with about a dozen different points, all pushing towards a higher level point: Fossil vs Git.

If you read the current text, it's clearly not trying to defend our choice or persuade you to make the same choice. It's just explaining some of the consequences of our choice, which may affect which DVCS you want to use.

(17) By Warren Young (wyoung) on 2019-07-14 12:15:12 in reply to 8 [link] [source]

Since the GPL vs BSD section of the document is controversial, why not just delete that whole section. It is not essential to the overall text. It is a bit of an afterthought. We can do without it.

I've found a path around the problem: I've re-cast this section as "Accepting Contributions," which discusses the licensing only as a run-up to our actual point, which hadn't been made yet in the trunk version of the document. There's even a link that takes the reader past the discussion and to our point, for those irritated by licensing discussions.

(18) By Warren Young (wyoung) on 2019-07-14 12:41:38 in reply to 17 [link] [source]

I've just realized that this change allows us to drop all discussion of licensing. Instead of leading into the main point via a discussion of the license differences, the lead-up can simply be:

"For several reasons, the Fossil DVCS project has received many fewer commits than Git has. [quantify that] We think there's an upside to this, in Fossil's favor." Then continue with the point on community cohesion and a smaller, more focused feature set.

I still like the new licensing discussion, but brevity is also good. I'll open discussion on this to the forum.

(19) By Warren Young (wyoung) on 2019-07-14 12:53:30 in reply to 18 [link] [source]

That's not quite right. Worded so vaguely, it becomes unclear that this is is part of "Linux vs SQLite". Replace "For several reasons" with something more concrete, like:

"Because of differences in the development community size and contribution model between the Linux kernel and SQLite..."

Should we then mention Git's first-mover advantage?

(20) By Warren Young (wyoung) on 2019-07-16 15:07:54 in reply to 19 [link] [source]

All right, with a day or so of silence from the masses, the wishes of the two village elders carry the day. That section is now almost entirely devoid of licensing talk, focusing instead on community structure, SLOC, feature sets, etc.

I'm ready for this to be merged to trunk now, if there are no more objections.

(21) By Stephan Beal (stephan) on 2019-07-16 18:05:31 in reply to 20 [link] [source]

I'm ready for this to be merged to trunk now, if there are no more objections.

Assuming that i'm one of the two aforementioned elders, i've got no objections. (If that assumption is wrong, i'll just go back to my corner and put my foot back in my mouth.)

(22) By ravbc on 2019-07-17 07:21:16 in reply to 20 [link] [source]

In point 3.1, I would add fossil undo command. Even not because of it's uniqueness and usefulness in fossil, but because of its lack in git and at the same time a very common cases where it would be very useful. ;-)

(23) By Warren Young (wyoung) on 2019-07-17 14:54:09 in reply to 22 [link] [source]

It's done, along with info on amend and shunning.

(24) By aue oiae (cregox) on 2021-12-26 01:26:22 in reply to 8 [link] [source]

was it deleted, after all?

i am currently with an agpl+promoter agenda... if anyone care to read more and move the debate elsewhere, to the fediverse. yes, the license debate is actually far from settled... but i agree this forum is not the right place to debate it.

instead...

am i right to assume the choice was made, above all, because you all consider versioning so important and fundamental that it should be "free for everyone to use", like a fundamental right?!

i would love to read more on why fossil decided to go "permissive".

cheers! 😘

(25) By Stephan Beal (stephan) on 2021-12-26 12:22:17 in reply to 24 [link] [source]

am i right to assume the choice was made, above all, because you all consider versioning so important and fundamental ...

The license decision was made entirely by the project's creator, Richard. If you look over his past works, though, most notably sqlite, it's clear that he prefers to release his software under extremely permissive terms.

Richard has been known, in interviews, to equate freedom with being able to take care of oneself. He's also known to be a philanthropist by nature. Those ideals intersect with him releasing tools with which people can better take care of themselves (e.g. source control which is trivial to self-host). Any sort of restrictive licensing would stand firmly in conflict with both of those ideals. As the fable of the scorpion and the frog demonstrates, a scorpion is going to scorpion and a frog is going to frog. It's just their nature, as it is Richard's nature to give away what he creates without applying undue restrictions on those who choose to make use of his offerings.

i'll opine that the reason fossil itself isn't public domain is because public domain is not recognized in all jurisdictions and has caused the sqlite project some degree of stress.

(26) By aue oiae (cregox) on 2022-03-20 05:06:55 in reply to 25 [link] [source]

thanks for your reply, stephan.

i hope richard will reconsider it, though.

and if he doesn't, that might signal to me that i should, indeed, work on the fupl! 🤣

for now, i continue with agpl, though. and hoping this discussion to happen elsewhere. 😘

https://talk.ahoxus.org/notice/AHakBaBcER1CBvN7j6#fpl#freepl#fupl

(27) By Stephan Beal (stephan) on 2022-03-20 11:29:29 in reply to 26 [link] [source]

i hope richard will reconsider it, though.

It seems safe to say that the chances of Fossil being re-licensed approach zero, in particular if the license is less permissive than the current BSD license.

Beyond fossil's initial relicensing, very early on, from GPL to BSD, there has never been any discussion of a license change within the project, nor have there been any circumstances which might prompt such a need. "If it ain't broke, don't fix it."

and if he doesn't, that might signal to me that i should, indeed, work on the fupl! 🤣

If the current license is a hindrance for you then that would be your best bet.

(29) By aue oiae (cregox) on 2022-03-24 04:39:01 in reply to 27 [link] [source]

done.

version "public pre alpha" is on!

i remembered to come here today because i got this update, and...:

This is an automated email sent by the Fossil repository at https://fossil-scm.org/home to report changes.

== 2022-03-22 15:57:26 Wiki Edit == To Do List (user: drh) https://fossil-scm.org/home/info/439fcf97170cc05f713b

Subscription info: https://fossil-scm.org/home/alerts/B09560C9FAFBF2939CDF28E9194D05DAC04560EE6C46689C5D30F8C290579406

... i decided i will stop coming back here until he/fossil-scm reconsiders, as i think the mindset needed for this to happen will bring a lot of well aligned improvements (such as using the fediverse, which would even eventually ease up everything for #mobileonly people such as myself).

scanning over the to-do and finding only technical aspects signal to me that he indeed may never ever want to pay the attention needed to this little "war" i've engaged.

plus my mind got blown away by the fediverse, and i also rather move away from forums in general. i decided to even quit sen, github, and other alikes (on top of discourse and reddit i had already quit before).

too much wheel reinventions for me.

i still think fossil have better potential than git though, so i leave with some hope left in my heart.

#allaboutmyself #dramaqueen #annoyingbrat #selfdepreciation (for clarity: all tags here refer to me 🤣)

farewell! 🤗