Thanks for your comments Daniel! It wasn’t our intention to add the badgeware paragraph in the first place, it was there because we recovered our header license text from our past open source components (from 4 years ago), that were in fact badgeware.
Since this is not our intention with spice-web-client we will be removing this parts from the headers. Regards, joca > On 02 Nov 2015, at 18:25, Daniel P. Berrange <berra...@redhat.com> wrote: > > On Fri, Oct 30, 2015 at 10:05:23PM +0900, Daniel P. Berrange wrote: >> On Fri, Oct 30, 2015 at 01:24:36PM +0100, j...@eyeos.com wrote: >>> >>>> I note the attribution clause in your license. As it stands now, I >>>> don't think that would cause any trouble (because of the 'however' of 5 >>>> (d) of the agpl). But it would probably be useful to get a clear >>>> expression of your intent - is it the case that you are willing to >>>> contribute this only so long as the eyeos logo is prominently displayed >>>> by any one choosing to deploy it? >>> >>> Our intentions are very simple. We want this to become the defacto html5 >>> client for spice. Of course we want to maintain it and develop it >>> openly. Aside from our obvious personal preferences for FOSS the main >>> reason to opensource it is to develop it in community and of course, we >>> are very excited to discuss the next steps with you and anyone >>> interested in web support for spice :) >>> >>> And no, we are not willing to have an eyeos logo everywhere this client >>> is used. In fact there is no need for you to display an eyeos logo to >>> use this. >>> >>> We choosed AGPL because it protects the spice web client from the ASP >>> loophole. We don't want en eyeos logo or something like this displayed >>> every time this client is used, we just don't want for example a third >>> party company adding support for opus in a private product of its own >>> and not contributing it since this can be used from a service provider >>> (ASP loophole in gpl and similar licenses). >>> >>> However, we are open to discussions about the license if you feel this >>> can be a problem for reasonable scenarios. >> >> Your rationale for using the AGPL as a core license makes sense to me. >> >> Adding any additional terms to any license though, generally makes me >> concerned, as it is very easy to add seemingly innocuous text that in >> fact has non-obvious legal consequences. So I am a bit conerned about >> the additionl terms wrt attribution & logo display. IANAL though, so >> I will see if I can get any clarity / expert opinion on whether these >> terms are likely to cause any problems for acceptance in distros such >> as Fedora (or Debian) which are quite strict about interpretation of >> licensing. > > Ok, so besides the standard AGPLv3 boilerplate text, there are two > paragraphs added to the license header at the top of the various .js > files in the repo > > First is > > [snip] > The interactive user interfaces in modified source and object code versions > of this program must display Appropriate Legal Notices, as required under > Section 5 of the GNU Affero General Public License version 3. > [/snip] > > Since this is just re-stating section 5(d) of the LICENSE file it seems > pretty pointless, but at the same time, mostly harmless. > > The second paragraph is the problematic one > > [snip] > In accordance with Section 7(b) of the GNU Affero General Public License > version 3, > these Appropriate Legal Notices must retain the display of the "Powered by > eyeos" logo and retain the original copyright notice. If the display of the > logo is not reasonably feasible for technical reasons, the Appropriate Legal > Notices > must display the words "Powered by eyeos" and retain the original copyright > notice. > [/snip] > > This is essentially adding a "badgeware" clause to the license. > Historically opinion has been divided as to whether "badgeware" / > "advertizing" clauses make a license non-free, or are merely an > undesirable attribution approach. > > I was pointed at the SugarCRM community license which had an (somewhat > stricter) logo display requirement and there were strong opinions in > Debian that this made it non-free. Although your clause isn't as strict, > I think it is sufficiently similar that people would have the same > opinion about it being non-free. > > https://lists.debian.org/debian-legal/2005/11/msg00114.html > <https://lists.debian.org/debian-legal/2005/11/msg00114.html> > > I was also referred to this FOSDEM presentation by a lawyer in the open > source space which puts across the case for all "badgeware" licenses > being considered non-free > > https://archive.fosdem.org/2014/schedule/event/trademark_licenses/ > <https://archive.fosdem.org/2014/schedule/event/trademark_licenses/> > > Since you say elsewhere in this thread, that it is not actually your > intention that everyone have to display a logo in their application, > I think it would be beneficial if you were able to re-consider the > terms used in the boilerplate text of the source files. To make the > licensing clear & simple to understand, IMHO, the easiest could be > to use the standard AGPL v3 boilerplate text "as-is" without any > custom additions. > > Regards, > Daniel > > [1] https://lists.debian.org/debian-legal/2005/11/msg00114.html > <https://lists.debian.org/debian-legal/2005/11/msg00114.html> > -- > |: http://berrange.com <http://berrange.com/> -o- > http://www.flickr.com/photos/dberrange/ > <http://www.flickr.com/photos/dberrange/> :| > |: http://libvirt.org <http://libvirt.org/> -o- > http://virt-manager.org <http://virt-manager.org/> :| > |: http://autobuild.org <http://autobuild.org/> -o- > http://search.cpan.org/~danberr/ <http://search.cpan.org/~danberr/> :| > |: http://entangle-photo.org <http://entangle-photo.org/> -o- > http://live.gnome.org/gtk-vnc <http://live.gnome.org/gtk-vnc> :|
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
