Re: Full featured (qxl compatible) spice web client released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <berrange@xxxxxxxxxx> 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, jose@xxxxxxxxx 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

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/

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]