According to the Readme, “All icons and images in Openfire are provided under the following license agreement:”
[legal jargon omitted - see attachment]
The license does not include an explicit right to copy or redistribute the icons, and it’s non-transferrable and non-sublicensable. So we can use OpenFire internally, but if we provide it to our customers we have to remove the icons first? Is that really what you meant to say?
Openfire Readme.htm.zip (2317 Bytes)
I’m not a lawyer or Jive attorney, but to me it looks that you can provide Openfire with its icons to your customers as long as it is Openfire. It means that you can’t take the icons out, put them into your own software and distribute it. I could be wrong, though. Jive should be able to answer this better, but i don’t know whom to ask and how.
Related question: in StringUtils.java there’s a comment on one member function (hexEncode) stating that it is licensed under LGPL.
According to section 5 of the LGPL ( www.gnu.org/licenses/lgpl-2.1.html ), aren’t you required to place all of OpenFire under LGPL (or GPL) ?
"All ownership and copyright of the images and icons included in the Software
distribution remain the property of Jive Software and INCORS GmbH. Jive Software
grants to you a nonexclusive, non-sublicensable right to use the icons royalty-free
as part of Openfire.
You may not lease, license or sub-license the icons, or a subset of the icons,
or any modified icons to any third party. You may not incorporate them into your
own software or design products."
This is quite clear. As long as your customers want to use the normal Openfire version everything is fine. If you want to provide Openfire packages you may want to contact Incors and ask for a license.
I did create http://issues.igniterealtime.org/browse/OF-502 for the StringUtils LPGL issue.
“As long as your customers want to use the normal Openfire version everything is fine”
How do I get someboy authorized to speak for Jive and/or INCORS to say that and put their name on it?
(the LGPL issue is less of a problem for us - we know how to comply with the LGPL and we know how to comply with Apache. My question was more in the nature of an informal bug report, so thanks for making that official. I could say the same thing about the distributability question: unclear license document = bug in documentation. Would I be off base filing a bug report for that?)
http://www.iconexperience.com/v_collection/license/ is the current license agreement for companies which want to re-use these icons. For $400 you may simply buy such a license - this may be cheaper than asking a lawyer.
That would be a great solution - but it doesn’t cover all the icons in OpenFire.
For example, the readme.html for the Kraken plugin indicates that “a couple” of the icons came from the Adium project. Which is GPL, by the way, so we definitely can’t use those icons, unless we can prove that the icons’ authors released them under some other license.
Also, it’s a bit of work for us. We have to guess at which icon is which (maybe this is obvious from the filenames, I haven’t downloaded VCollection yet) and track where OpenFire expects each icon to reside. THEN we see which OpenFire icons we haven’t accounted for, conclude those were non-VCollection icons, and try to find substitutes for those.
We’ve already spent way more than $400 in lawyer time on OpenFire, by the way.
Every plugin may use it’s own icons, that’s true and this make things much more complicated.
Well, Kraken is not maintained and you may want to avoid giving it to customers.