On Wed, Jul 29, 2009 at 03:42:16AM -0400, Albert Cahalan wrote:
> I really don't care for any of this, particularly if:
> a. they remove the Tux Paint name
I'm not personally concerned about this, nor is it a requirement we
can make. (Situations like Firefox vs Ice Weasel and
RedHat vs Fedora and CentOS come to mind, but they're kind of the reverse.)
> b. they fail to comply with the GPL
A very large concern, but my assumption is that they'll (1) understand
the GPL, and either (2a) use the code, and comply with the license, or
(2b) decide not to use the code. I'm encouraged by the fact that
they came to us to get advice at this early stage.
> c. they supply non-free starter images
This is not a concern for me. And, in fact, I assume this will be part
of the purpose of the app -- to fill it up with some trademark brandname
characters. See below, for more.
> d. they tack on some nasty EULA
As long as they adhere to the GPL, this is not a concern to me.
(See RedHat's EULA with regards to trademark.)
> e. they mislead the company who is paying
In this case, I believe this would be the trademark owner. (I think
I'm ok saying that they develop, publish and distribute software.)
> f. they fail to support Linux
This is not a concern to me, because the GPL doesn't insist
"if you sell a product based on this code, it must work with Linux."
However, part of the reason they've shown interest in Tux Paint is that
it's multi-platform. (But to them, this likely means: Mac and Windows.)
I will do what I can to encourage Linux support, though. Esp. considering
Linux's prevalance in netbooks.
> Shipping a Tux Paint with alternate stamps and
> fonts is no problem I guess, even if redistribution
> is prohibited by copyright law.
e.g. Quake code is GPL, Quake data is proprietary.
> Buyers of the product should be able to replace
> the executable with a modified one, starting from
> either pristine Tux Paint or the hacked Tux Paint.
> This shouldn't cause loss of any extra media files.
I see no reason that it _must_ be compatible with a pristine Tux Paint.
They can fork it. They must adhere to the GPL, though. (Which means
we could incorporate the code from their fork back into Tux Paint,
> Buyers of the product should be able to share the
> resulting images with users of pristine Tux Paint.
> Because starter images are not embedded in the
> user's work, this makes starter images a problem.
Again, not a concern.
Now, keep in mind that all of these 'not a concern' comments are not
necessarily me disagreeing with you, but it's not something that we
can require. We can only make requirements based on the current
licenses for the current code and data. (That is, if they use the
code, they must adhere to GPL. If they use this and that piece of
artwork, they must adhere to CC-Attrib or CC-Sampling-Plus or
...just like everyone else.
If we WANTED to add all of these restrictions ("any derivatives of
Tux Paint must be able to share images with the main Tux Paint"), we'd
need to release a new verion that included them. Meaning (1) we would
likely no longer be GPL-compatible, or even open source compliant, and
(2) people and companies could still grab Tux Paint 0.9.21 or earlier,
and run with it. ;)
> Essentially: don't cause incompatibility, and don't
> take away or hide the rights that normally come
> with Tux Paint.
The latter is the thing we're already asking for (by using GPL,
CC licenses, etc.) And that's what I want to make sure gets done correctly.
> Imagine this:
> Flybynight Company sells a rebranded Tux Paint
> to Disney. They purport to grant Disney all rights.
> Maybe they even strip off the copyright in the source.
> The closed-source Windows-only result becomes
> the "better" version because it has the right branding.
> Disney later discovers Tux Paint and sues **you**
> for copyright infringement. You go bankrupt fighting.
Even Disney wouldn't have a chance, due to the sheer proliferation
of Tux Paint. (That is, 7+ years of proof of the existence and
open development of the project.)
I will keep everyone here up-to-date on any decision that gets made,
and bring up any questions and concerns here.
I've contacted the Software Freedom Law Center
( http://www.softwarefreedom.org/ ) about the situation (as much as I know
and can share) and their comments ('not legal advice') are as follows:
A commercial redistributor of GPL'd code cannot in any way limit what a
downstream recipient of a modified version of the program can do with
the functional aspects of the program beyond those provisions in the
GPL. So, in essence, all functional / structural changes they make must
be licensed under the GPL. There's no way around that.
However, they can restrict usage by downstream recipients of their
trademarks and logos. RedHat does this to keep people from
redistributing RedHat linux using the RedHat trademark and logo. See
https://www.redhat.com/licenses/rhel_rha_eula.html, and specifically
paragraphs 1 and 2. See also
They could also probably create their content as a separate independent
work from the program itself and, thus, when they distribute those
content files, as the whole copyright holder themselves, they can
distribute under any terms they want. Think music player distributed
along with a music file. Although they interoperate, they're not
derivative of each other, and thus are separate works and separately
...and I'm passing it along to my contact at the company.
Thanks again for the feedback,
Sent from my computer