Ungoogled-chromium: Licensing between GPLv3 and BSD 3-Clause

[wchen342]

So I realized this when clearing out some documentations. ungoogled-chromium uses a BSD 3-Clause license, but Bromite uses GPLv3. AFAIK if you use GPL works in a BSD work you need to convert that work into GPL. Won't that be a problem for the current license of UC? Is it no one noticed that so far, or am I missing something?
@Eloston @csagan5

[csagan5]

Chromium itself uses a mix of licenses for the different software components and its source code cannot be licensed under a single license; the license of ungoogled-chromium or Bromite applies only to the the additional patches.

The best would probably be to keep a reference to the license in the patches themselves.

I did not pick BSD because it allows re-packaging and selling.

[wchen342]

Does it mean each patch is considered a separate work and they are indenpendent from each other? And what about distributing binaries compiled from UC, how do those count?

[csagan5]

I do not see them as separate work, but you can modify the whole work by removing patches.

I consider the patches as a bundle, same as you can have "security enhancement" patches. You are provided the patches to use them during the build process instead of a stand-alone component.

And what about distributing binaries compiled from UC, how do those count?

Licenses do not apply to binaries; binaries are released as freeware (it's no different than Chromium).

Feel free to explore this further, I have never dived into it. My goals are simple:

• open source nature of the project, so that other can continue/fork it
• avoid commercial exploitation

There are already some projects re-using the patches, although they not always refer back to Bromite (rebranding jobs).

[PF4Public]

This is actually a good question.

On one hand, every patch by itself that touches chromium codebase is a derivative/modification of the said codebase as it inevitable (by the virtue of having context) contains snipplets of chromium code. Most of chromium is BSD, so this allows any modifications and derivatives. Good question is if anyone is allowed to re-license BSD code into GPL. But that feels to be about OK. So here we have one separate object with its own license. I may be wrong, but they are more like documentation of sorts. So that if you receive those patches and want to modify/distribute them further, you must abide by GPL rules. If you do this in-house for your own purposes — you don't have to.

Now when we compile a modified version of chromium, which we are perfectly allowed to, we create a modified version of chromium and those patches, they are not like code, they never link or compile into resulting binary, we kinda utilise them during build and they are never included in chromium by themselves, so they do not inflict any licensing consequences. That is a rather thin thing and I'm not 100% sure with it also. But that is my understanding of this.

[csagan5]

Now when we compile a modified version of chromium, which we are perfectly allowed to, we create a modified version of chromium and those patches, they are not like code, they never link or compile into resulting binary, we kinda utilise them during build and they are never included in chromium by themselves, so they do not inflict any licensing consequences. That is a rather thin thing and I'm not 100% sure with it also. But that is my understanding of this.

As I see it patches are code, if you look at any version control system, it is just a pile of patches - one on top of each other - yet no one considers them as non-code. They also correspond 1:1 to generated code, as you can find the code differences as binary differences.

[wchen342]

That is probably ture, otherwise the license for this project is mostly meaningless (the only other codes being several python scripts).

I think the key point is whether UC and Bromite are "derivative works" of each other. There will only be a problem if UC is considered a derivative work.

[Eloston]

Won't that be a problem for the current license of UC? Is it no one noticed that so far, or am I missing something?

Yes, it is a problem. I don't think either of us really considered licensing problems before, so we should clarify this before it becomes a problem.

Feel free to explore this further, I have never dived into it. My goals are simple:

• open source nature of the project, so that other can continue/fork it
• avoid commercial exploitation

In that case, this could become a problem because I don't think of avoiding commercial exploitation as a goal for ungoogled-chromium. This is a deeper topic involving opinions about Chromium's impact on web browsers and the challenges of using licensing to avoid commercial exploitation, so I'd be happy to discuss this in a separate issue if you'd like.

For the record, we switched to BSD 3-clause back in #230, and there was a small discussion about it in #517. If we want to revisit re-licensing, we should open a new issue.

I think the key point is whether UC and Bromite are "derivative works" of each other. here will only be a problem if UC is considered a derivative work.

I would consider ungoogled-chromium a derivative work because the Bromite patches aren't really separate from the other patches.

Based on what I know about licensing, I see four options:

1. Get permission from @csagan5 to license the Bromite patches we use under BSD 3-clause (or compatible license). This would mean that any new patches we'd get from Bromite would need to be licensed this way too, but I don't think that will be a problem since we haven't been getting new patches from Bromite recently (and @csagan5 has been kind to contribute directly).
2. Re-license ungoogled-chromium under a GPLv3-compatible license. If we are to explore this option, we should discuss in a new issue as noted above.
3. Remove Bromite patches. We could also consider a mixture with Option 1 so only some patches are removed and others are relicensed, because some patches are more interesting than others.
4. Have Bromite change to a BSD 3-clause compatible license. I doubt this will happen but it's still a slight possibility...

[wchen342]

For me I will prefer keeping the BSD license, but for a different reason (I believe more in absolute freedom rather than the GPL kind). Option 1 will be optimal IMO and if that doesn't work I think option 3 is the way to go.

[csagan5]

3. Remove Bromite patches. We could also consider a mixture with Option 1 so only some patches are removed and others are relicensed, because some patches are more interesting than others.

What is the worst case scenario? As far as I am aware, it would be that if a binary version without sources is released, someone can require by the terms of the GPL to release the sources. I am fine with that (although you might not be).

I am not going to change the license of Bromite nor release all patches as BSD, as it would achieve the same goal (replacing the current license).

I would enforce the license claims if there is a commercial spin-off of Ungoogled-chromium, or it goes closed source; I think we have discussed the license for the current Bromite patches in UG already (need to find the issue/PR), but I have never given too much thought to this because - as for Chromium - I thought any project can have multiple licenses in their codebase as well, especially a Chromium-related project.

The claims of GPL on binaries are also very difficult to enforce (although I am not giving them up - either explicitly or implicitly) here: we need a lawyer, but most probably the answer is that you cannot have a mix of GPL and non-GPL code and still have the GPL binary claims apply to the result.

Forgive me for the confusion, but this is pretty much how I see all of it. Having a project made up of "patches" is just not something that can be easily licensed.

[csagan5]

2. Re-license ungoogled-chromium under a GPLv3-compatible license. If we are to explore this option, we should discuss in a new issue as noted above.

As for this option, no need to have this discussion because of me or Bromite, but it feels extremely unfair to me when a commercial entity can create a spin-off and does not even have to refer back to the original project.

[PF4Public]

@csagan5 I do sincerely share your feelings about commercial code usage, but, given that there is already your collection of patches freely available, are there really any reasons for a commercial entity to use your patches? I'm not trying to reassure you or anything like that, just willing to see the reasoning behind.

[Eloston]

@csagan5 I'm a little confused about your writing, so let me try to rephrase it in terms of the options:

• Option 1 does not work because you want all of your contributions under GPLv3; i.e. the few Bromite patches we include must remain GPLv3
• Option 3 works only if all Bromite patches are removed, for the same reasons as for Option 1.
• Option 4 does not work for the same reasons as for Option 1.

So therefore the only potential options left are 2 and 3. Am I understanding you correctly?

[csagan5]

• Option 1 does not work because you want all of your contributions under GPLv3; i.e. the few Bromite patches we include must remain GPLv3

No, I wrote that I think we already agreed back then to re-license them as BSD, see:

I think we have discussed the license for the current Bromite patches in UG already (need to find the issue/PR)

But I cannot apply this to all/more patches of Bromite, it would not make any sense.

@PF4Public the problem is not just with commercial usage but with releasing any binary which uses them and not the sources, effectively detracting from any future open source development possibilities. And as I wrote, I am not even sure if you can derive claims on the produced binary if the whole sources are not GPL, it's a whole construction of hypotheticals.

[csagan5]

I have never given too much thought to this because - as for Chromium - I thought any project can have multiple licenses in their codebase as well, especially a Chromium-related project.

@Eloston this is where I was hinting at a 5th option: let patches have different licenses, same as Chromium does with components

[PF4Public]

Will GPL patches prevent anyone distributing ungoogled-chromium from distributing it with widevine? Users locally can do as they please ofcourse.

[wchen342]

No, I wrote that I think we already agreed back then to re-license them as BSD

@csagan5 What about the patches I used in ungoogled-chromium-android? They are a different set than those in this repo and I didn't thought about license before.

[csagan5]

@wchen342 check each of them, I am not the author in every case but I preserved original author so you can search them online and refer to the original author/project license.

[csagan5]

@wchen342 @Eloston what will happen in practice (and it's not mentioned in options 1~4) is that patches will be "looked at" and rewritten, authorship removed and the license problem is solved.

That's why I'd prefer to have each patch as an individually licensed contribution; but I am not concerned about any approach in particular, if we all had the time to sift through the Chromium codebase we would find these and more patches, as privacy is eroded and features changed. So the patches act more as a "pointer"/bookmark than anything else.

[Eloston]

No, I wrote that I think we already agreed back then to re-license them as BSD, see:

Oh, that's what you meant. Thanks for reminding me. In that case, we don't have a licensing issue here.

@Eloston this is where I was hinting at a 5th option: let patches have different licenses, same as Chromium does with components

Components in Chromium are more distinct and separated compared to patches. However, is it even legal to include GPL components with their BSD 3-clause? I've seen some GPLv2 components in their code that seems to suggest it is fine, but the Chromium licensing is more complex than I'm willing to spend time on...

Regardless, if the time comes that we want to borrow more code from Bromite, we can discuss the licensing for those.

That's why I'd prefer to have each patch as an individually licensed contribution; but I am not concerned about any approach in particular, if we all had the time to sift through the Chromium codebase we would find these and more patches, as privacy is eroded and features changed. So the patches act more as a "pointer"/bookmark than anything else.

I agree, especially for patches that add new functionality like the canvas or DOM fingerprinting patches. Otherwise for patches that simply remove/disable code, it'd be a bit silly to think about licensing.

Anyway, thanks again for your time @csagan5

[csagan5]

In that case, we don't have a licensing issue here.

I think @wchen342 was wondering about the new patches used in ungoogled-chromium-android, but I think there is not much if you exclude those I did not write. For the remainder I could also grant BSD-3 to solve the issue (they are probably small patches that change flags and similar).

I agree, especially for patches that add new functionality like the canvas or DOM fingerprinting patches. Otherwise for patches that simply remove/disable code, it'd be a bit silly to think about licensing.

Yes. I would be less convinced for patches like this: https://github.com/bromite/bromite/blob/83.0.4103.119/build/patches/Bromite-AdBlockUpdaterService.patch that constitute self-standing new small components.

Components in Chromium are more distinct and separated compared to patches. However, is it even legal to include GPL components with their BSD 3-clause? I've seen some GPLv2 components in their code that seems to suggest it is fine, but the Chromium licensing is more complex than I'm willing to spend time on...

Yes. I think the biggest aspect to clarify is whether someone else than me can make any claim based on the license; even if you have to take my word for it, I would not be interested in making any claim if the downstream project is open source.

[wchen342]

but I think there is not much if you exclude those I did not write

I check the patches/Bromite folder and all except the one adds exit menu item and the one disables ping are written by you, so for all the other ones I will need you to grant BSD-3. The big one is the DoH one I think, others are just flags/small fixes.

[csagan5]

@wchen342 from the text of the GPL v3 license:

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

This is the part I refer to regarding patches that can be possibly licensed individually.