GPL licensing and integrations

[MrPrise]

Will be a corresponding typo3 user created for the SMF user, so we can manage their rights for the typo3 part?

[jack]

Yes.

A lookup will be made for the user, based on the SMF MEMBER_ID (I'll probably need to add a field to the T3 users table to accommodate this) and if one isn't fond, it is silently created.

[Kindred]

A lookup will be made for the user, based on the SMF MEMBER_ID (I'll probably need to add a field to the T3 users table to accommodate this) and if one isn't fond, it is silently created.

why not base the loookup on SMF username (not displayname (aka realname), which can be changed, but the username field which is the user's login ID)?

That way, there is no change to either system's database setup (which is always preferable)

[jack]

That's the way I do it with YaBBSE, but in SMF, both the username and realname can be changed. MEMBER_ID is (AFAIK) the only immutable identifier in a user's profile.

[Orstio]

That's the way I do it with YaBBSE, but in SMF, both the username and realname can be changed.

Only admins are allowed to change usernames in SMF, and only if they are allowed to edit accounts.

Here's the code from SMF:

Code Select Expand

// Only show these settings if you're allowed to edit the account itself (not just the membergroups).
if ($context['allow_edit_account'])
{
if ($context['user']['is_admin'] && !empty($context['allow_edit_username']))

Regardless of that, if you are using the SMF integration hooks, the integrate_reset_pass integration hook passes both the old username and new username to update whatever integration you're working with.

[jack]

Only admins are allowed to change usernames in SMF, and only if they are allowed to edit accounts.

That still doesn't make them immutable. While I can restrict the use of that function ion my site, I cannot state that someone else may find it invaluable.

Regardless of that, if you are using the SMF integration hooks, the integrate_reset_pass integration hook passes both the old username and new username to update whatever integration you're working with.

Unfortunately, I have to use the updated api.php due to the SMF license being incompatible with the gpl (typo3 is gpl licensed).

On the plus side, a well supported and a strong framework for extending the Typo3 database schema exists. Adding the extra field is not an issue.

[Kindred]

the point is that a bridge should not modify either of the bridged systems, in order to remain viable despite possible system upgrades on either side.

[jack]

Any bridge does modify one or the other of the systems being integrated. That is unavoidable as you are modifying the behaviour of one of the systems. Also any integration is heavily dependant on the version of the software on either side of the bridge. Integration and mod APIs are generally kept as stable as possible, though it is possible for them to change with major upgrades.

When writing an integration, it is good practice to only modify the side who's behaviour you wish to change. In this case, I am changing the behaviour of Typo3 not SMF, therefore the changes are made there. You may have mis-understood, I am not integrating SMF into Typo3, I am integrating Typo3 into SMF.

Typo3's support for modifications and extensions is much more stable and advanced than that of SMF (though admittedly much more complex). For example, no extension will modify any existing code file, all changes are made by overriding behaviour through sub-classing and configuring the system to use your new classes rather than the existing ones. Each extension must register a unique identifier centrally which is then used as a prefix for anything global (such as schema extensions) ensuring that two similar extensions cannot easily conflict. This isn't the place for a real discussion on the different extension systems. I'm happy to discuss them in another thread if you're interested.

[Orstio]

Unfortunately, I have to use the updated api.php due to the SMF license being incompatible with the gpl (typo3 is gpl licensed).

I don't see what this has to do with licensing?  I've written a brief guide to using the integration hooks.  With them, SMF itself can be used as an API.

http://www.simplemachines.org/community/index.php?topic=173483.0

Any bridge does modify one or the other of the systems being integrated. That is unavoidable as you are modifying the behaviour of one of the systems.

Not true.  None of the bridges in the downloads section of this site modify SMF code nor the code of the CMS in which they integrate.

[jack]

I don't see what this has to do with licensing?  I've written a brief guide to using the integration hooks.  With them, SMF itself can be used as an API.

It has everything to do with licensing. The GPL forbids linking (compile-time or run-time) with code that is incompatible with the GPL. Therefore a simple

Code Select Expand

require("smf/SSI.php");
cannot be done from a GPL'd program (such as Typo3). I queried the FSF specifically about this when writing the original Coppermine bridge for SMF. We were able to get around the problem as we were able to ask all the Coppermine copyright holders and added an exception to the Coppermine license. It is this specific reason why [unknown] created the api.php file in the first place. The same is true in reverse, I cannot call GPL code from within SMF.
As I am not a member of the Typo3 Dev team, I can't really ask them to change their license for me.

Not true.  None of the bridges in the downloads section of this site modify SMF code nor the code of the CMS in which they integrate.

They may not make changes to code in existing files on disk, but the code being compiled and executed by the processor is different.

[Orstio]

It has everything to do with licensing. The GPL forbids linking (compile-time or run-time) with code that is incompatible with the GPL. Therefore a simple

Code:
require("smf/SSI.php");cannot be done from a GPL'd program (such as Typo3). I queried the FSF specifically about this when writing the original Coppermine bridge for SMF. We were able to get around the problem as we were able to ask all the Coppermine copyright holders and added an exception to the Coppermine license. It is this specific reason why [unknown] created the api.php file in the first place. The same is true in reverse, I cannot call GPL code from within SMF.

Interesting....[Unknown] is also the one who created the integration hooks in the first place which rendered smf_api.php obsolete for SMF 1.1....

Are you absolutely certain?  I was just reading this:

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

If the libraries that you link with fall within the following exception in the GPL:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them. Thus, if the libraries you need come with major parts of a proprietary operating system, the GPL says people can link your program with them without any conditions.

Which, in your case, as long as you are not distributing your Typo3 integration along with Typo3 itself, should still be fine by the GPL.

[jack]

.. at the functional level yes, but not license level.

It's an easy enough thing to overlook and I guess it got forgotten about when I took a hiatus and stopped banging on about it Life would be so much simpler if all problems were technical ones.

I daren't even look at GPL3 yet.. it may sink my entire site

[Orstio]

This is getting way off-topic, but I found this reading further:

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

There seems to be a lot of grey area around this type of usage.

[jack]

Are you absolutely certain?  I was just reading this:

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

Yup .. that explicitly states

the major components (compiler, kernel, and so on) of the operating system on which the executable runs

That was one of the clauses causing us confusion.
However, Typo3 isn't an operating system

Here's an excerpt from my emails with the FSF (received 5th Feb 2004)...

>       * As a convenience feature for our users, we are working on a mechanism
> where Coppermine can optionally link to external programs (such as web
> based 'forums') to read user data & authenticate users. We are including
> this link code as part of the Coppermine package. The code remains
> dormant and unreferenced unless the user explicitly configures it and
> separately installs a compatible forum package. The link code involves
> no modifications to the third party package, but in some circumstances,
> where convenient, source files and internal from the forum package are
> referenced from this link code at run-time.
> Obviously, if the forum package is under the GPL license, this wouldn't
> be a problem, but there are some that are under more restrictive
> licenses. As it is all in a scripting language (in this case PHP) and
> all inter-operation happens at run-time (no aspect of the GPLd code is
> present within the forum package and non of the forum package code is
> within our project), where do we stand with regards to 'linking' the
> packages in this manner? Are we allowed to do this at all, is it
> permitted 'out of the box' with the GPL, or would we have to write a
> special exception clause?

Dynamic, run-time linking is still linking. 

If you intend to allow your program to be combined with GPL-incompatible
programs in this way, add an exception.

--
-Dave "Novalis" Turner
GPL Compliance Engineer
Free Software Foundation

lol, gotta love my over-enthusiastic use of 'quotes'.
The forum with the more restrictive license was in fact SMF. His response is pretty clear-cut. Adding an exception involves changing the license for the whole program, something that was possible for coppermine, but - alas - highly unlikely for Typo3.

[Kindred]

but wait...   this is only if you plan to distribute an SMF bridge with the Typo3 release package.

If you submit and distribute the bridge here on simplemachines.org, then there should be no problem.   Typo3 is distributed and installed at will. To link SMF, you must download the official SMF package from this site AND them run the bridge package.

This would enable you to use the integration hooks built into both systems to the fullest extent.
(Isn't Joomla also GPL? There's never been any question about the joomla bridge.)


and, actually, if you use the integration hooks in your code, without including any actual SMF functions in your release package, you are still in compliance.  I'm not sure why soeone would claim that including a call for SSI.php would violate either the SMF or the GPL license.

[jack]

This is continuing from the Typo3 thread Here as it was getting waaay off-topic.

but wait...   this is only if you plan to distribute an SMF bridge with the Typo3 release package.

Not by my understanding. Any seperately distributed code would have to fall under one license or another.

If you submit and distribute the bridge here on simplemachines.org, then there should be no problem.  Typo3 is distributed and installed at will. To link SMF, you must download the official SMF package from this site AND them run the bridge package.

Typo3 plugins unavoidably contain GPL code for the integrating of them into Typo3 (at least in my case - and every other one I can think of) as I don't have the skill to be able to write 'clean-room' code to link into Typo3.

This would enable you to use the integration hooks built into both systems to the fullest extent.
(Isn't Joomla also GPL? There's never been any question about the joomla bridge.)

I don't know, Joomla may be under a GPL with exclusions license like Coppermine and the linux kernel is.

and, actually, if you use the integration hooks in your code, without including any actual SMF functions in your release package, you are still in compliance.  I'm not sure why soeone would claim that including a call for SSI.php would violate either the SMF or the GPL license.

It's not about what is in release packages, it is about hat happens at run-time. Calling SSI.php pulls in a lot of SMF code into the current process.

A good solution would be something like a SOAP or XMLRPC interface that could be queried. That would be 'at arms length' enough I reckon to make it work.