Major Feature #25731
Handling of non GPL-compliant Extensions in TER
| Status: | Needs Feedback | Start date: | 2011-04-04 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Joern Bock | % Done: | 0% |
|
| Category: | [FOR] TER | |||
| Target version: | - | |||
| Votes: | 0 |
Description
Hi
Upon request of Steffen Kamper and Steffen Müller, I'm posting this here. There was a discussion, how we handle non GPL-compliant extensions in TER. For this, I've written the following proposal:
---
((pre-discussion was about that just dropping non-compliant extensions that give important functionality to TYPO3 like e.g. a flash based video player would cause harm))
+1 from my side, just dropping would harm and cause unneeded discussions
but also +1 for cleaning up the TER and enforcing the rules
What about having a new option in ext_emconf where the authors will have
to declare whether an extension is
a) undefined (value for all the existing extensions unless one of the
following statements are made)
b) complies completely with the TER rules (all code == GPL licensed)
c) contains non-GPL code
d) contains non-GPL code with a written agreement with the corresponding
developers thus legally to be published
This would allow us to show GPL-compliant extensions with a certain icon
and e.g. hide a) and c) after a certain grace period. Hiding in this
case would mean: hide by default, show on request (*)
*) somehow like Debian's non-free collection of software - you have to
explicitly enable that group of packages to install software out of it.
---
I'd like to hear your inputs on this issue.
Cheers,
Mario
History
Updated by Steffen Müller about 2 years ago
My opinion on this topic:
- We should provide a mechanism in official TER to keep non-free works out of TER, as long as the TYPO3 Association (and/or their members) can be made responsible for copyright violations. How is this handled in Debian non-free repository? Where is it located?
- Free licenses have to be granted on all parts of an extension. This includes all files like PHP code, content, documentation, templates, binaries etc. (see below)
- A second repository (unofficial TER) can be set up to host non-free extensions. This would avoid harm and unneeded discussion. The TYPO3 Association should not be responsible for hosting this repository. We'd have to find someone else.
- If the author grants the TYPO3 Association a permission for publishing an extension under non-free license, we can make exceptions. Then we need to proof that manually. But a better idea would be to always put that stuff into unofficial TER. Then no manpower is wasted with proofing non-free licenses
- Extension authors should read and agree some legal terms, which are shown in the EM before extension are uploaded (repeated on each upload). Authors need to click "I agree" to be able to proceed to upload to official TER, otherwise his work will be put into unofficial TER.
Some notes on free licenses:
- PHP code in extensions is in most cases derived work of the core, since it extends core functionality and it can't be run as a standalone application. According to GPL, this code inherits the GPL licence of the core. So the extension author has no choice here, their code is automatically GPL. In the GPL FAQ the used term is "plug-in", but this is IMHO equivalent to what we call extension: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins Exception are possible, e.g. phpmyadmin, which is perfectly running on its own and is simply shown in a frame of the TYPO3 backend.
- In case of PHP code which does not extend the core, we should also accept non-GPL code, which has a GPL-compatible license: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses So I suggest to use the term "GPL (or compatible) software" in any text/terms we publish. I know that it is sometimes hard to find out, if a license is compatible.
- Extensions do not only contain plain PHP code, but other kinds of contributions: documentation, content, templates, CSS, JS, binaries...
- Documentation of extensions usually are licensed under Open Content License: http://www.opencontent.org/opl.shtml
- JS can have own licence, not neccessarily GPL - as long as the JS code does not extend core JS and matches the "standalone" criteria.
- Content (e.g. images), templates (fluid, HTML) and CSS do not have to be GPL compatible. The GPL FAQ interpretes this as trivial content, which does not need GPL http://www.gnu.org/licenses/gpl-faq.html#WMS But in practice, this is not the case. There are a lot of templates with non-free licenses available in the web. Since we cannot guarantee that these licenses are invalid, we have to take them into account. So templates and stuff can also cause license issues.
- If the extension ships binary program files (e.g. imagemagick or html2pdf), the corresponding source code also needs to be published on TER, if the license says so (e.g. the GPL does).
- We should look how other free CMS handle this (dr*pal, w*rdpress, j**mla)
Updated by Mario Rimann about 2 years ago
Steffen Müller wrote:
- A second repository (unofficial TER) can be set up to host non-free extensions. This would avoid harm and unneeded discussion. The TYPO3 Association should not be responsible for hosting this repository. We'd have to find someone else.
I don't see a need for a separate repository yet. Marking the extensions clearly should be enough IMHO. But I'm not sure about the liability of the Association herein -> I hope we can solve this by having your idea from below set up and clearly declare the single extensions within the TER to be owned by the responsible authors (and that they are responsible for correct licensing). Something we should communicate yet, but I couldn't find it right now.
- Extension authors should read and agree some legal terms, which are shown in the EM before extension are uploaded (repeated on each upload). Authors need to click "I agree" to be able to proceed to upload to official TER, otherwise his work will be put into unofficial TER.
I agree, that would be great. But this directly brings up the question what to do with the existing extensions in the TER? Just hiding/removing them is a no go I think. That's why I proposed the step-by-stop introduction in my initial idea.
I've had a look and found the following:
- We should look how other free CMS handle this (dr*pal, w*rdpress, j**mla)
- Joomla has a Licensing FAQ (http://opensourcematters.org/index.php?option=com_content&view=article&id=55) which basically says "We consider all modules to be derivative work that needs to be licensed under GPL"
- Drupal has an even better Licensing FAQ (http://drupal.org/licensing/faq) which clearly says that everything that get's published to drupal.org (including their whole Git-Repository) must be GPL licensed
- Wordpress basically just notes what copyright notice should be copy-pasted to any module without further explanation (http://codex.wordpress.org/Writing_a_Plugin#License)
Updated by Steffen Müller about 2 years ago
We talked about this issue in the Usergroup Freiburg. Opinions were:
- A second non-free repository is not necessary.
- Extension developers must read & click through a license agreement before uploading to TER. The agreement must clarify, that all code users contribute to TER has to be free. It must be a requirement to be allowed to push to TER and also when signing up for a new account at typo3.org. Otherwise uploads to forge/git/svn are not covered by the agreement.
- Existing non-free extensions should immediately be removed, once there were complains.
- Then the Association shouldn't be responsible for possible license violations - as long as non-free extensions get removed once it was revealed and removal was request. It seems to be comparable with copyright issues and hosting providers like rapidshare etc. Have a look at the upload rules in the terms of use on https://www.rapidshare.com/#!rapidshare-ag/rapidshare-ag_agb
None of these statements have been legally proven. Just opinions!
My personal view:
I don't like the idea of leaving non-free extensions on TER, although it is known in public that they may cause license violations. Doing this for a limited period of time only postpones harm and unneeded discussions. Why do you think people will not agree with the 100% free software rule? Of course we should start a general discussion in the ML before removal rules get applied. We should always share opinions before making decisions.
I also don't like the idea of write-protect git/svn accounts who did not sign the existing CLA of the Association (like it is already done for FLOW3). This would heavily reduce contributions, since CLA is IMHO a bloated monster and few people might be willing to sign it.
Updated by Thomas Loeffler 5 months ago
- Project changed from TER Frontend Index to The typo3.org project
Updated by Thomas Loeffler 5 months ago
- Category set to [FOR] TER
Updated by Thomas Loeffler 5 months ago
- Status changed from New to Needs Feedback
- Assignee set to Joern Bock
Interesting discussion.
What do you mean, Joern?