Task #50133

License compatibility

Added by Jigal van Hemert over 6 years ago. Updated almost 3 years ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
Target version:
Start date:
2013-07-17
Due date:
% Done:

0%


Description

Felix Kopp mentioned that he wanted to include Twitter Bootstrap [1]. This has the Apache License v2.0 (documentation and images Creative Commons BY 3.0).

The question is of course if this is compatible with the license of TYPO3 CMS.

There of course more often packages that could be included which have a different license than TYPO3 CMS currently uses. One chart [2] mentions that Apache License 2 is compatible with GPL v3, but not with v2. The thing that makes it complex for mere mortals is that TYPO3 CMS has GPL v2 or higher as license.

It would be great to have an overview with the licenses that are compatible with TYPO3 CMS to make it easier to decide if something can be included or not.

[1] http://twitter.github.io/bootstrap/
[2] http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#Approvals


Related issues

Related to Licensing Team - Task #50438: Collect Links that might be relevant Accepted 2013-07-25
Related to TYPO3 Core - Bug #82774: Check license compatibility upon extension install Closed 2017-10-16
Related to TYPO3 Core - Bug #82875: Check license compatibility upon extension upload to TER Rejected 2017-10-27

History

#1 Updated by Jo Hasenau over 6 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Jo Hasenau

Well - first of all it depends on, what the meaning of "include" is.

Both, Apache License and GPL, only apply to code, that one of its users is giving to another, together with a piece of software, that has been derived from this code.
As long as you don't deliver a package made of TYPO3 and bootstrap code, you are free to use both packages however you like.

We discussed that during the Themes-Workshop at T3DD13 and there seem to be different ways to go:

The easiest way would be to not include the bootstrap code within the TYPO3 package at all but provide a download option for those, who want to use it. I.e. just use one of the common bootstrap sources to remotely get the files at frontend runtime. IMHO this would be a good idea, since the code could be cached to be reused with other sites built on the same bootstrap version.

You could even include it within a GPL v3 extension, that would not cause any problems as long as it would not be delivered together with GPL v2 TYPO3 code. So we could only get in trouble when bootstrap code would be implemented as a core extension or a default third party package to be delivered as part of an official TYPO3 package.

Another solution could be to change the license of the TYPO3 core to GPL v3, which should be easy, since every contributor already agreed to the license term "GPL v2 or higher".
In this case someone just has to actually do it and provide a huge monster of a patch, but after all it would make the life of many contributors easier regarding license restrictions ;-)

#2 Updated by Jo Hasenau over 6 years ago

Actually it would even be possible to include the code within a GPL v3 extension and deliver that together with TYPO3 code.
The TYPO3 license being "GPL v2 or higher" already allows GPL v3 extensions, and currently we already got GPL v3 code in the TYPO3 source package.
Since the actual "derivative work" would be the extension itself and not the whole TYPO3 source, it would still comply to the GPL v2 terms [1] to distribute them within one downloadable source.

[1] http://en.wikipedia.org/wiki/GNU_General_Public_License#Communicating_and_bundling_with_non-GPL_programs

#3 Updated by Jigal van Hemert over 6 years ago

"include" see http://www.merriam-webster.com/dictionary/include

To be absolutely clear: "include" was meant to describe the way all third party software has been used so far, part of the distribution preferably in a clearly marked section (such as the 'contrib' directory).

It would seem incorrect to me that we have GPL v3 code in the source package. TYPO3 CMS is shipped as GPL "either version 2 of the License, or (at your option) any later version". My logic says that I can choose to have the GPL v2 license and the GPL v3 license is not backwards compatible [1]. Thus using TYPO3 CMS under GPL v2 would make part of CMS violate its own license!

According to [2] is the Apache License 2 only compatible with GPL v3. Including software with that license would make it impossible to use CMS under GPL v2.

Some people suggested to convey CMS to GPL v3, but others indicated that this would require the approval of all contributors (which is quite impossible).

It seems to me that it is really necessary to get a solid legal statement about the following matters:

1. Which licenses are compatible with the TYPO3 CMS license regarding the possibility to ship software or code with those licenses as part of the TYPO3 CMS package?
2. Is it possible to convey TYPO3 CMS to GPL v3 (or higher?) to increase the number of compatible licenses? If yes, what is the impact for the currently "included" third party software?

This would make an end to any discussion about licenses of third party software and would make it much easier to judge if such third party software can be shipped with TYPO3 CMS.

[1] http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
[2] http://www.gnu.org/licenses/quick-guide-gplv3.html#new-compatible-licenses

#4 Updated by Jo Hasenau over 6 years ago

To be absolutely clear: "include" was meant to describe the way all third party software has been used so far, part of the distribution preferably in a clearly marked section (such as the 'contrib' directory).

"part of the distribution" and "shipping" is completely covered by [1] of my former statement.

It would seem incorrect to me that we have GPL v3 code in the source package. TYPO3 CMS is shipped as GPL "either version 2 of the License, or (at your option) any later version". My logic says that I can choose to have the GPL v2 license and the GPL v3 license is not backwards compatible [1]. Thus using TYPO3 CMS under GPL v2 would make part of CMS violate its own license!
According to [2] is the Apache License 2 only compatible with GPL v3. Including software with that license would make it impossible to use CMS under GPL v2.

The term "GPL v2 or later" means just the contrary. [2]

If the Program specifies a version number of this License which applies to it and "any later version", 
you have the option of following the terms and conditions either of that version or of any later version 
published by the Free Software Foundation.

This just excludes any version before GPL v2 but explicitely includes any later version

Some people suggested to convey CMS to GPL v3, but others indicated that this would require the approval of all contributors (which is quite impossible).

No approval necessary, since they all already agreed to the term "GPL v2 or later". So we could switch to GPL v3 for the whole package, but actually this will not be necessary.

It seems to me that it is really necessary to get a solid legal statement about the following matters:

1. Which licenses are compatible with the TYPO3 CMS license regarding the possibility to ship software or code with those licenses as part of the TYPO3 CMS package?

Regarding the shipping you are free to include anything you like, even completely "incompatible" licenses, since - as already mentioned - the GPL does not cover shipping at all, but just derivative work. Even enhancing a GPLed piece of software with another non GPLed piece of software is not "derivative" work, since "derivative" work has to incorporate and therefor replace the original work (i.e. compile a piece of proprietary software that uses GPLed parts). [3]

2. Is it possible to convey TYPO3 CMS to GPL v3 (or higher?) to increase the number of compatible licenses? If yes, what is the impact for the currently "included" third party software?

There only would be an impact if the third party software was just GPL v2 without the addition "or later", in this case we would have to ask for permission of the authors.
But anyway it would be a good idea to ask third parties for permission, since they might provide us with a special version using another license.

[2] http://www.gnu.org/licenses/gpl-2.0.html
[3] http://scholar.google.com/scholar_case?case=10867856245078964488

#5 Updated by Ernesto Baschny over 6 years ago

Jo, would you say that we can include Twitter Bootstrap in the Core Package that we release and distribute, following your logic, or NOT?

That's a vital point, because Felix's point was about including it in the Core, mainly to be able to use it in the backend (and not in the Frontend for themes), i.e. using their widgets and conventions to make it more easier for developers to style their backend modules. We would then bootstrap's conventions, its base.css and augment it with our own custom css to fit the TYPO3 BE style.

Can't we get legal council on that, wasn't that why we had a budget allocated for this matter? Why don't we hear anything about it from this team and instead let us "developers" discuss our "point of views"?

  • could we release the Core as GPLv3 and what would the consequences be (i.e. for extensions in TER etc...)?
  • do we need to migrate to GPLv3 in order to integrate Bootstrap or is there any other easier way to do that?

#6 Updated by Jo Hasenau over 6 years ago

The problem is, that even lawyers would not be able to give you much better advice, since there is the need for real cases and decisions made by judges to be more or less on the safe side. Since there are no cases to be found with decisions about GPL v2 or higher AND Apache v2, we have to stick to the definition made in the "mere aggregation" part of the GPL:

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Since there is no derivative code, which would be based on both GPLed TYPO3 code AND non GPLed Bootstrap code, and since the packages are using completely different languages and libraries and are still able to run independently, IMHO this is what "aggregation" means.

Based on this assumption there should be no need to shift the license of TYPO3 itself to GPLv3 or higher, but still this would make things a lot easier, since this license would be DEFINITELY compatible in any case, while GPLv2 or higher just SHOULD be compatible, or MIGHT be irrelevant due to the definition of "mere aggregation".

Actually the consequences in the TER would be quite low, since most of the extensions should be using the default copyright notice, that clearly states "GPLv2 or higher".
So the only problematic extensions would be those using GPLv2 without the additional "or higher", but even these extensions should be compatible, since they are linking to the TYPO3 sources and not the other way around.
http://www.gnu.org/licenses/quick-guide-gplv3.html

So my recommendation is: Go for GPLv3 or higher within the whole TYPO3 package to be completely on the safe side. GPLv3 and Apache v2 are compatible by definition, no need to spend a budget for the lawyers in this particular case then.

#7 Updated by Jo Hasenau over 6 years ago

BTW: It seems there are other GPLed CMS projects having similar issues, which is why the Twitter Bootstrap guys are planning to change their license to MIT (X11).
https://github.com/twbs/bootstrap/issues/2054
http://www.gnu.org/licenses/license-list.html#X11License

Current state is: 99.3% acceptance rate, for those who voted, still 68 votes missing.

As far as I read they are trying to replace and/or remove the commits by the 2 "no" voters, so the chances are good that there will be an MIT licensed Twitter Bootstrap soon.

But it seems that according to that discussion TYPO3 should be in less trouble than the Drupal people, since Drupal is licensed as GPLv2 only, but not "GPLv2 or later" - which is currently just a dual license under GPLv2 and GPLv3. This is why they would have to ask their contributors for permission as well, which is what we don't have to do.
http://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater

So either we should wait until TB was relicensed before including it into the core or go for GPLv3.

#8 Updated by Jo Hasenau over 6 years ago

BTW: There seem to be no problems with the Apache License used by Open ID, which is already part of a sysext. So I don't think we should overact on Twitter Bootstrap ;-)

#9 Updated by Kay Strobach about 6 years ago

Source: http://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater

Why should programs say “Version 3 of the GPL or any later version”? (#VersionThreeOrLater)

From time to time, at intervals of years, we change the GPL—sometimes to clarify it, sometimes to permit certain kinds of use not previously permitted, and sometimes to tighten up a requirement. (The last two changes were in 2007 and 1991.) Using this “indirect pointer” in each program makes it possible for us to change the distribution terms on the entire collection of GNU software, when we update the GPL.

If each program lacked the indirect pointer, we would be forced to discuss the change at length with numerous copyright holders, which would be a virtual impossibility. In practice, the chance of having uniform distribution terms for GNU software would be nil.

Suppose a program says “Version 3 of the GPL or any later version” and a new version of the GPL is released. If the new GPL version gives additional permission, that permission will be available immediately to all the users of the program. But if the new GPL version has a tighter requirement, it will not restrict use of the current version of the program, because it can still be used under GPL version 3. When a program says “Version 3 of the GPL or any later version”, users will always be permitted to use it, and even change it, according to the terms of GPL version 3—even after later versions of the GPL are available.

If a tighter requirement in a new version of the GPL need not be obeyed for existing software, how is it useful? Once GPL version 4 is available, the developers of most GPL-covered programs will release subsequent versions of their programs specifying “Version 4 of the GPL or any later version”. Then users will have to follow the tighter requirements in GPL version 4, for subsequent versions of the program.

However, developers are not obligated to do this; developers can continue allowing use of the previous version of the GPL, if that is their preference.

#10 Updated by Olivier Dobberkau over 4 years ago

  • Target version set to Q2 2015

#11 Updated by Olivier Dobberkau almost 3 years ago

  • Target version changed from Q2 2015 to Q1 2017

#12 Updated by Jo Hasenau about 2 years ago

  • Related to Bug #82774: Check license compatibility upon extension install added

#13 Updated by Jo Hasenau about 2 years ago

  • Related to Bug #82875: Check license compatibility upon extension upload to TER added

Also available in: Atom PDF