It is not necessary to include the text of the license itself in order to be licensed under that license. All the LGPL components in WP reference the LGPL by URL, it is in there in several places.

The general topic to provide the license-text and URL has already been addressed in #14703. While working on the ticket, I did research on it and got in contact with various experts from the free software movement.

With the following result: It is strongly recommended, that the license text is part of the package. Linking it via URL does not change this. Text of the licenses should be provided in the software package.

Please see also the link above which is about the LGPL in specific.

If you still see this differently, please provide some reference for your statement.

To solve this, I can offer to discuss this topic (LGPL code used, comment has URL, LGPL license missing) with an institution like the Software Freedom Law Center additionally.

We do not need license bloat any more than we need any other kind of bloat. WordPress itself is GPL, and though some components in it (from elsewhere) have their own license, we are not required to distribute copies of that license with them.

Please reference something that shows it is _not_ necessary. I get the impression that this is just an opinion which does not stand an argumentation. Repeating it doesn't help.

We do not need license bloat any more than we need any other kind of bloat. WordPress itself is GPL, and though some components in it (from elsewhere) have their own license, we are not required to distribute copies of that license with them.

What do you want to argument for? That the LGPL license text inside the package is bloat? And to follow recommendations is not necessary? I'm pretty shocked that I must read such a statement by a regular.

What's that problematic with adding the LGPL file to the Package? Do you really think that the text of the LGPL is bloat and providing it is negative for users? That there is no benefit by doing so?

As it was criticized that "recommends" was too vague, here you have a "must" in the original terms. Please read the licenses carefully when you comment and judge about them. The related literature is helpful as well to understand the big picture.

But struggling about fine-details between words often does prevent getting the big picture. That's leading away from what this is about: To respect and ensure the freedom of contributed code.

I know of the fact that programmers have the tendency to apply boolean logic to everything they read. It's a kind of disease we have in common. But that's not getting the point. Get the big picture. I don't want wordpress to promote such bad practice.

What about my suggestion we let this mediate through a third party like the SFLC? If two regular contributors argument strongly against something that is so straight forward and simple to solve - providing the license text to the packages users - then I think that some professional feedback from a third-party can be helpful.

And while discussing the matter here, please give arguments instead of just closing the ticket just because you have a different opinion. Only with contradictions we can come to good conclusions.

"Recommended" is not "required". "Should" is not "must". And your opinion is not a factual piece of information.

What's that problematic with adding the LGPL file to the Package? Do you really think that the text of the LGPL is bloat and providing it is negative for users? That there is no benefit by doing so?

Yes, and yes.

And you must show them these terms so they know their rights.

As it was criticized that "recommends" was too vague, here you have a "must" in the original terms.

That does not say that you must include the license. That says that you must show them the terms. The terms, in our case, are shown by referring to the URL of those terms. Your argument here has no merit.

What about my suggestion we let this mediate through a third party like the SFLC?

I don't care who they are, what their credentials are, or what they decide to back up their arguments with. If they agree with you, then they are still wrong. And I will look them right in the eye and tell them flat out that they are wrong. Wrong is wrong, and credentials don't make it right.

More to the point, while we could easily include the license in there, I think that it's "bloat" because it's confusing to the end user. We already have a license.txt document. Putting another licensing document in there, which doesn't actually do anything, which doesn't actually *change* anything, just creates more opportunities for people to read the wrong thing and make invalid assumptions.

The third party bits of WP that are LGPL are all pretty clearly marked as such, and they have URLs that point to the text of their licenses. Unless you think that gpl.org is going away anytime soon, then they are adequately documented as to their licensing already.

More to the point, while we could easily include the license in there, I think that it's "bloat" because it's confusing to the end user. We already have a license.txt document. Putting another licensing document in there, which doesn't actually do anything, which doesn't actually *change* anything, just creates more opportunities for people to read the wrong thing and make invalid assumptions.

AFAIK licensing terms are in written form. That *implies* to provide it. If you don't do so, it's like referring to something that is subject of change or just inexistent.

"Recommended" is not "required". "Should" is not "must". And your opinion is not a factual piece of information.

"It's recommended not to breath under water." Help yourself. The recommendation is not my personal opinion but the on of the folks who made the LGPL. Maybe you can honor that "factual piece of information".

What's that problematic with adding the LGPL file to the Package? Do you really think that the text of the LGPL is bloat and providing it is negative for users? That there is no benefit by doing so?

Yes, and yes.

It's sad. Quoted for truth.

And you must show them these terms so they know their rights.

As it was criticized that "recommends" was too vague, here you have a "must" in the original terms.

That does not say that you must include the license. That says that you must show them the terms. The terms, in our case, are shown by referring to the URL of those terms. Your argument here has no merit.

The URL argument has no merit. I can only underline this: Based on the research and various talks I had with others (and I _openly_ asked for their opinion and explicitly about linking Licenses), put the license text inside the package. I mean this is a software package. When you get software, where do you expect the license. EULA anyone? URLs are not always provided and some of the content they link are not licenses btw. So even technically URLs are broken to show the license.

What about my suggestion we let this mediate through a third party like the SFLC?

I don't care who they are, what their credentials are, or what they decide to back up their arguments with. If they agree with you, then they are still wrong. And I will look them right in the eye and tell them flat out that they are wrong. Wrong is wrong, and credentials don't make it right.

I can understand that this topic is somehow complex and not easy to understand for a programmer as it has legal implications. So my suggestion was to contact a third party regarding this issue, namely the SFLC because I know that your employer asked for their opinion once. That's whay I thought that organization might be trustworthy for you. But it was a suggestion only, you can suggest to a third party of your choice as well.

And I don't know the opinion of the SFLC yet, so I did not suggest them because they share the arguments I gave. The opposite is the case, they can be freely asked, telling them the problems raised here with providing the license. It would be the first time regarding the LGPL licensing issue here. I suggested them for mediation.

More to the point, while we could easily include the license in there, I think that it's "bloat" because it's confusing to the end user.
We already have a license.txt document. Putting another licensing document in there, which doesn't actually do anything, which doesn't actually *change* anything, just creates more opportunities for people to read the wrong thing and make invalid assumptions.

There are analogies in history where helpful kings needed to protect dumb subjects from damage. All the time. This sounds a bit like: If they don't have the license, they can't misread it, these idiots. So that actually not providing the license is better then providing the license.

I respectfully oppose such a point of view. I'm for providing the license-text so users can easily access it and educate themselves.

If you fear that the scope of the license is not clear, then you might be addressing an additional problem. One that most probably this can be easily solved. For example by providing some information in form of a short notice in the readme comparable to the one that existed once.

The third party bits of WP that are LGPL are all pretty clearly marked as such,
and they have URLs that point to the text of their licenses.

Hmm. I think you have not really taken a look into the code, have you? Naturally only code marked as LGPL can be seen as being LGPL (easy to state, right?) but are you sure all have URLs. And to what content are those URLs acutally pointing? Do you think those URLs point to the text of the LGPL-License? I think you should take a look first before making such a statement. Just to ensure we talk about the same code.

Unless you think that gpl.org is going away anytime soon, then they are adequately documented as to their licensing already.

I have no idea why you refer to gpl.org but generally spoken, as written, providing URLs is not the same as providing the license. So having a URL inside some comment does by far not mean that they are adequately documented already. That's probably a misunderstanding because we as web-developers make use of URLs every day and this is normal to us to deal with them.

But in a legal sense, a URL can not represent the license text. And other things can happen then a site being inaccessible (as opensource.org was lately and is always in LAN environments), for example change of URLs. Some of the URLs in wordpress code say it's outdated and suggest to relicense (!).

Something must have reminded me of the relative short amount of time the oxygen tank allows to breath under water ... :)

I have no idea why you refer to gpl.org but generally spoken, as written, providing URLs is not the same as providing the license.

I stated "gpl.org", however I meant "whatever URL is being pointed to". On searching, that is in fact "opensource.org".

Okay. And which code did you meant when you stated "The third party bits of WP that are LGPL are all pretty clearly marked as such, and they have URLs that point to the text of their licenses."?

Check the WordPress codebase then you'll see that it's not that well documented as you wrote. "opensource.org" as quoted is not linked btw.

And I question your statement here. Providing a reference to the terms of the license is functionally identical to providing the text of the license.

But in a legal sense, a URL can not represent the license text.

[citation needed]

As a URL is not the same as a license text, I would not put it on the same level. IANAL so please don't take that statement for granted, I stated "can not represent" but I meant "is not" in an overall sense, and that most probably has a legal implication. I already referred to the document linked in the description of the ticket. That for example is by the creator of the LGPL and I have the feeling that they legally sensed it. So if you need citation how to provide the license I would refer to the creator of the license firsthand.

And you need to be fair if you now counter with a [citation needed]: As it is you who wrote that the requirements of the license text can be fulfilled by providing a URL only, you should back that up when being questioned as well. I'm still missing some reference for your argument.

And you need to be fair if you now counter with a [citation needed]: As it is you who wrote that the requirements of the license text can be fulfilled by providing a URL only, you should back that up when being questioned as well. I'm still missing some reference for your argument.

I'm going to go with the "simple common sense" argument here.

Let's I write a piece of code. I give you the piece of code. I *verbally* tell you that the licensing for that piece of code is X. Guess what? That's perfectly legally binding. It's my code. I can license it how I choose. How I decide to communicate that license to you is irrelevant.

The license is my set of terms on the software I write. Unless stated otherwise, there is no requirement anywhere in law to make me communicate those terms in a specific manner.

Contrary-wise, your position is rather weak. Are you suggesting that the license somehow does not apply if the text of the license is not included? Because that makes no sense whatsoever.

As I already wrote and you are somewhat immune to the argument, a URL does not do the job to show the license. You wrote it yourself. "hey, the license is over here" implies that it's not part of the package and located on some other, foreign system.

And you're not mentioning about the places that do not have a URL at all.

And you're not mentioning the places of which the URL is not linking any license.

And then you're mentioning the license.txt of TinyMCE editor but you don't comment on it. What do you suggest with that statement? I'm just curious.

Firstly, I "look into the code" every single day, and I did a search on the code to see which pieces are LGPL before I responded to you in this thread at all. I probably know "the code" better than most people.

Secondly, I reject your argument that a URL does not do the job. A reference to a thing can indeed take the place of a thing. That's what "reference" means.

Third, a URL is not actually necessary. The LGPL is a well-known and commonly used license, so simply stating that that is the license by name is also perfectly acceptable. Even legally.

Fourth, I have no idea what you're talking about with me not commenting on the TinyMCE editor. I thought that my previous post pointing out that it DOES have the license included there was my comment on it.

Firstly, I "look into the code" every single day, and I did a search on the code to see which pieces are LGPL before I responded to you in this thread at all. I probably know "the code" better than most people.

Then I wonder why you gave wrong URLs first and why you didn't notice that some places do not have a URL at all.

Secondly, I reject your argument that a URL does not do the job. A reference to a thing can indeed take the place of a thing. That's what "reference" means.

A license file on a foreign system can not take the place of a license file in the concrete package. I know that you reject the argument, and I know that you do not question your own opinion. Just deal with the fact that there is contradiction about that point. I did as well already in the other ticket and was asking some legal folks for help. Maybe you can do on your own the same so this is actually productive.

Third, a URL is not actually necessary. The LGPL is a well-known and commonly used license, so simply stating that that is the license by name is also perfectly acceptable. Even legally.

[citation needed]
And btw, please read the text of the LGPL. There are licenses out there that imply you need to pass them/a specific fingerprint with the work. Just a hint.

Fourth, I have no idea what you're talking about with me not commenting on the TinyMCE editor. I thought that my previous post pointing out that it DOES have the license included there was my comment on it.

I was wondering about your feelings when you found out about the license.txt file in the tinymce folder. You only wrote that you found it, but not what that means in your eyes.

Third, a URL is not actually necessary. The LGPL is a well-known and commonly used license, so simply stating that that is the license by name is also perfectly acceptable. Even legally.

I wonder about how consequential you are with your arguments. Doesn't that mean as the GPL is even more well-known then the LGPL, that it should be removed from the package because of not being "necessary" and "bloat" as you coined it?

Just a marginal note and a little reminder that shows on how LGPL is treated within wordpress: not all code that is actually LGPL (which needs to be done intense research first) is marked as such in the WP codebase.

While dealing with #16039 it came to my attention, that LGPL sits on top of the GPL. As the GPL clearly needs "to give any other recipients of the Program a copy of this License along with the Program." (see GPL v2 §1) and as LGPL extends the GPL this concludes to the LGPL license text as well.

All LGPL code in WordPress is marked as LGPL. In each case, the original source code properly references the LGPL and either links to it, or points to the FSF in case the file is missing. Additionally, we do include the LGPL license at wp-includes/js/tinymce/. Closing as invalid, for everything is covered. If there's a file not properly covered as I outlined above, we can fix that.

As it's time of repeating arguments again, I'm in for it: You need to pass the license text with the package, you need to make that prominently with the file (and not in some other pacakges subdirectory like tinymce) and for the sake of good style, the readme should inform about this.