Hello,
We are maintaining Foxyproxy package in Ubuntu repositories. The license comment:
"PLEASE NOTE:
The FoxyProxy name, logo, graphics, art work, website, styles, and documentation are proprietary works and are neither open-source nor free."
went unnoticed until recently, when we were planning to update the package to version 2.9. It is unclear from the notice if the redistribution of the mentioned contents is allowed, so could you tell me if it is?
If it isn't, is there any easy way to debrand Foxyproxy (e.g. strip proprietary contents)?
Thanks in advance,
Saša Bodiroža
jazzva wrote: It is unclear
It is unclear from the notice if the redistribution of the mentioned contents is allowed, so could you tell me if it is?
I hereby grant you full rights to redistribute all non-free aspects of FoxyProxy on the Ubuntu repositories as long as the original code of FoxyProxy is unpatched or otherwise altered. If there is a reason you need to patch or alter FoxyProxy, please let me know and we can discuss that as a possibility without you needing to fork.
If you need other permissions or other help, please let me know. I am a huge fan of Ubuntu and use it every day!!
Eric Jung
Author
FoxyProxy
Hello Eric, Thanks for your
Hello Eric,
Thanks for your response and willingness to cooperate on this issue :).
I think the license to redistribute non-free artwork is fine to keep software in universe (instead of moving it to multiverse), because that sounds like the case with Mozilla artwork. I'll have to check with other developers to see if that is correct.
Though, the part of your post that mentions restriction of modification might push the software to multiverse (universe contains only free software, which includes the right to redistribute, modify, etc.). May I suggest the deal that we forward our modifications back here, so you can consider them for inclusion in the main branch? So far we had only one modification, which was needed to get Foxyproxy working [1] [2] [3].
[1] http://foxyproxy.mozdev.org/drupal/content/tries-use-usrlibfirefox-304fo...
[2] https://bugs.edge.launchpad.net/ubuntu/+source/foxyproxy/+bug/279466
[3] http://bazaar.launchpad.net/~jazzva/firefox-extensions/foxyproxy.ubuntu/...
ok
May I suggest the deal that we forward our modifications back here, so you can consider them for inclusion in the main branch?
OK. That's a good idea, but the contributions can't break FoxyProxy on other operating systems.
So far we had only one modification, which was needed to get Foxyproxy working [1] [2] [3].
[1] http://foxyproxy.mozdev.org/drupal/content/tries-use-usrlibfirefox-304fo...
[2] https://bugs.edge.launchpad.net/ubuntu/+source/foxyproxy/+bug/279466
[3] http://bazaar.launchpad.net/~jazzva/firefox-extensions/foxyproxy.ubuntu/revision/25
Thanks. I'll put this into FoxyProxy 2.9.1, assuming it doesn't break other operating systems.
Eric
Great, thanks :). Also, can
Great, thanks :).
Also, can you put your permission for redistribution inside license file in the next version of FoxyProxy, so we can publish the extension to our repositories?
Thanks in advance,
Saša Bodiroža
Hi Saša, Can you please
Hi Saša,
Can you please review these two changes?
1. Amendment to the LICENSE file with the information you requested. Is this OK for universe instead of multiverse? (You prefer universe to multiverse, right?)
2. Changes you requested here in order to support application-wide installation of FoxyProxy. I have tested to ensure no problems are caused when upgrading from FoxyProxy 2.9 to trunk; everything is OK.
http://fisheye2.atlassian.com/changelog/foxyproxy/?cs=386
Kind regards,
Eric Jung
I personally dont understand
I personally dont understand why Ubuntu would want to have Firefox addons in their repositories and not just link to them at AMO since this provides better updates.
Reason for extensions in repositories
I personally dont understand why Ubuntu would want to have Firefox addons in their repositories and not just link to them at AMO since this provides better updates.
The reason for this is to be able to install extensions system-wide. The downside of this approach is the one you mentioned. We are working on automatic packaging of the extensions, which would auto-update the package in repositories when newer version of some extension is found.