Licensing policy change proposal

Tue Jan 29 05:38:35 GMT 2019

First of all, I'd like to mention that I've been snooping around the Pexels
website and it turns out that they misappropriate images from Pixabay while
claiming that the license for those images is CC0. The actual license for
those images is the Pixabay license, which is the same as the Unsplash
license (forbidding anyone else to create a competing service, which Pexels
is in direct violation of).

So, Pexels is out.

I wouldn't necessarily characterize the Unsplash license as FOSS, but
rather public domain with restrictions (not entirely public domain). I also
think that in order to verify that the photographers have indeed waived
their rights, we might have to contact them (it's easy enough to do so
though, their contact information is right there on the website).

*In response to Ken's email*, while I sympathize with what you've written,
public domain doesn't entail accreditation from what I understand
(otherwise it wouldn't be *public* domain), and the idea that we can avoid
using public domain in KDE is somehow *unrealistic* to me, because *we do
it all the time*. The very GUI itself (or WIMP) is a great example of that,
see:

https://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Microsoft_Corp.#Background
and the second paragraph of
https://en.wikipedia.org/wiki/Idea–expression_divide
sorta boring legal text that covers this problem in the EU
https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1446134154470&uri=CELEX:62010CJ0406

Namely, an overwhelming number of our UI elements already are in the public
domain simply because they're non-copyrightable. We ourselves can give
credit / enforce accreditation, but we can't deny that we've long reaped
the benefits of public domain and shall continue to do so, without giving
any credit to the authors whose public domain elements we use on a daily
basis (mostly because we don't know who they are).

And I don't think the goal here is to shy away from the possibility of
abuse considering that any license can be subject to abuse; I think the
ultimate goal here is to make sure it isn't abused (rather than avoid it
altogether because it's hard to enforce).

On Tue, Jan 29, 2019 at 12:01 AM Ken Vermette <vermette at gmail.com> wrote:

> As an author and contributor I'm giving my thumbs-down on CC0 and
> friends. The main crux I have is that, already, many of us have
> artwork (including wallpapers, glyphs, icons, designs, and many other
> visual assets) which are used unaccredited with extreme regularity.
> Legally speaking, I need to go after every website I find using the
> artwork and heckle them to post the appropriate license/attributions.
> In practice if a company is abusing our visual work in some way (such
> as claiming ownership, authorship, or excessive rights) I need to be
> able to claim that the appropriate license was posted for the work,
> and that I have enforced said license. I have also seen instances
> where we have distributed assets without any license information at
> all. In these cases, I at least have our license policy to fall back
> on should a license abuser come to light.
>
> The danger in accepting CC0 is that, if the KDE community were to
> start publicly validating non-accrediting public domain licenses, then
> it throws into someone like me *not* actively heckling people to
> properly post licenses into a legal problem. If someone were to ever
> abuse our work, it essentially removes my ability to claim that it is
> not our policy to publish public domain work. I can claim I don't do a
> great job at enforcement, but in tandem with that a license abuser
> could claim that KDE community distributes public domain artwork, that
> licenses haven't been enforced, and that there was reason to believe
> the work may have been published in a public domain.
>
> To add fuel to the fire, when we distribute assets, sometimes we get
> the license wrong. If ever we maintained a body of work and a license
> like the CC0 was mistakenly attached to it, it would be a very bad
> situation for every author involved. It gets worse here because we're
> talking about using public-domain licenses specifically to make
> bundling several works of disparate authors together; everyone would
> need to be vary careful about appropriately licensing every. single.
> image.  in such a bundle. At least with what we have now, the licenses
> aren't so dissimilar that significant problems could arise because of
> this.
>
> TLDR; Authors who don't enforce license compliance with a heavy-hand
> are put at a higher risk of losing rights when public-domain licenses
> add potential confusion to what our work may be represented as. It
> could, very easily, become ammunition against authors and artists to
> be used by license abusers.
>
>
> On Mon, Jan 28, 2019 at 10:43 AM Krešimir Čohar <kcohar at gmail.com> wrote:
> >
> > I think they're one and the same. All intellectual property the rights
> to which have been waived = CC0 = public domain. There are a few European
> exceptions to copyright expiration, such as
> https://creativecommons.org/2016/04/26/long-arm-copyright-millions-blocked-reading-original-versions-diary-anne-frank/
> that I don't think concern CC0.
> >
> > On Mon, Jan 28, 2019 at 3:51 PM Cornelius Schumacher <schumacher at kde.org>
> wrote:
> >>
> >> On Sonntag, 27. Januar 2019 21:14:10 CET Mirko Boehm wrote:
> >> >
> >> > I need to point out that CC0 licenses are problematic in many
> jurisdictions,
> >> > as there is no simple way to dedicate a work to the public domain. The
> >> > correct way in for example France or Germany would be to use a
> permissive
> >> > FOSS license. Let us avoid the mine field of public domain.
> >>
> >> Isn't the CC0 license the attempt to solve the issues of the term
> "public
> >> domain" across jurisdictions and provide a license which works as what
> people
> >> expect from public domain?
> >>
> >> What are the issues of public domain that CC0 doesn't solve?
> >>
> >> --
> >> Cornelius Schumacher <schumacher at kde.org>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20190129/609ab717/attachment.htm>