Re: [Fwd: FW: For Approval: Generic Attribution Provision]

[John Cowan]

Nick Moffitt scripsit:

>   A: The GPL as published by the FSF all but self-destructs when you try
> to impose additional restrictions such as the aforementioned "clause 8
> addition".

That's the one and only additional restriction that GPLv2 allows you
to add.

>   B: The copyright for the GPL is owned in total by the Free Software
> Foundation with all rights reserved (except distribution), and they are
> not in the habit of licensing it to developers for the purposes of
> adding additional restrictions.  

Not in the habit, no, but it has happened at least once.

--
We do, doodley do, doodley do, doodley do,        John Cowan <cowan@...>
What we must, muddily must, muddily must, muddily must;
Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon

[Matthew Flaschen]

Nick Moffitt wrote:
>   A: The GPL as published by the FSF all but self-destructs when you try
> to impose additional restrictions such as the aforementioned "clause 8
> addition".

Well...not exactly.  Additional restrictions are invalid when added by
redistributors.  The original author can have them, though the FSF
frowns on it.  More importantly, the clause 8 restriction is a clause of
the GPL; thus, the GPL hardly self-destructs when it is specified by the
copyright holder.

> They are not in the habit of licensing it to developers for the purposes of
> adding additional restrictions.  

No, they allow this: "You can use the GPL terms (possibly modified) in
another license provided that you call your license by another name and
do not include the GPL preamble"
(http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL)

Matthew Flaschen

[David Woolley]

> frowns on it.  More importantly, the clause 8 restriction is a clause of
> the GPL; thus, the GPL hardly self-destructs when it is specified by the
> copyright holder.

Actually, the option isn't to impose restrictions but to give additional
permissions, namely to permit distribution in certain countries, when
the basic GPL would have forbidden distribution in all countries.
It's probably only worded in terms of restricted countries because, at
the time of drafting, software patents were only a problem in a few
countries, and, in any case the set of countries in the world keeps
changing.

[Matthew Flaschen]

David Woolley wrote:

> Actually, the option isn't to impose restrictions but to give additional
> permissions, namely to permit distribution in certain countries, when
> the basic GPL would have forbidden distribution in all countries.
> It's probably only worded in terms of restricted countries because, at
> the time of drafting, software patents were only a problem in a few
> countries, and, in any case the set of countries in the world keeps
> changing.

Yes, from the FSF's perspective, all of their restrictions are actually
granting permissions/freedom to someone.  Obviously, this has been
controversial...

Matt Flaschen

[David Woolley]

> Yes, from the FSF's perspective, all of their restrictions are actually
> granting permissions/freedom to someone.  Obviously, this has been
> controversial...

I think you are missing the point.

Whilst it is true that the pure licence concept can only give permissions,
and the FS rely on making those additional permissions conditional, the
base GPL does not grant those permissions when there is a patent
conflict.  Section 8 then allows a distributor of new code which has
a patent conflict to grant additional permissions without conflicting
with the GPL.  The fact that the list of countries is specified in terms
of the universal set minus problem countries is a minor detail,
although one that is very practical, as it allows newly formed countries
to use the software without a new licence being issued.

There is some controversy as to whether the negative terms of the GPL
require a formal contract, but I don't see that there is any reasonable
way that one can interpret the section 8 rules as being an additional
restriction in this sense.

[Craig Muth]

Rick Moen wrote:
> I think you might be confusing two things.  The action you describe is
> _not_ what Matthew Garrett spoke of, and would in fact be a clear tort
> by established principles of copyright law.

What I had in mind was rebranding the UI (rather than the license) and
selling, which I don't believe violates BSD/Copyright.  The SugarCRM
guy mentioned that some instances of this initially spurred him to add
the attribution language.

> Granted, Matthew was a bit vague in his rejoinder that "the BSD license
> explicitly allows this" -- but then, so were you in your preceding
> comment that companies "rebranding and charging money for open source
> without contributing back" are being "bad for open source".

> I believe what Matthew had in mind was the traditional (and specifically
> intended) BSD freedom to make proprietary derivative works based on
> BSD-licensed code.  In no way does that freedom grant downstream users
> the right to lie about upstream code authorship.

Agreed.  BSD does grant you the right to rebrand *the UI* (and charge
money) and so I don't consider doing so a lie.  Nor do I consider BSD
bad because of this.  My larger point is that I think attribution
could be a middle-ground between allowing proprietary derivative works
(a la BSD) and not allowing them (a la GPL), which could be a
compelling option for certain types of projects looking for a license.
 That is, as a price for using an open source component many
commercial projects can't reconcile releasing their own source, but
many likely wouldn't mind leaving attribution in the UI.  An improved
attribution license/provision could give some projects an option to
get some benefit, without going as far as restricting commercial
projects from using them without releasing their source and thus
greatly reducing their pool of potential adopters.

A common example of a business using open source is taking a big open
source project (like Linux) and making a few modifications to it and
using the whole.  Another common example of a business using open
source is taking a small open source component and using it in an
existing large proprietary project.  In the former case the business
shouldn't begrudge releasing the source of their modifications, as
payment for the tremendous benefit they've gotten.  In the latter case
it becomes less clear whether giving away the proprietary source is a
fair demand.  This is a dilemma commercial projects face quite often,
but at the same time can understand why many coders don't want to go
with an overly permissive license.  Attribution could be a great
option for projects that have an application tending more toward the
latter case.

> We're the people who take OSD #3, 6 and 10 seriously, and who aren't
> distracted by insultingly bogus analogies and special pleading.

I apologize for any insult unintendedly inherent in the bogusness of
my analogies:)  I was addressing the broader "is UI attribution
incompatible with open source" and "what is the value of attribution"
questions.  I agree that there are some issues that haven't been
addressed regarding the OSD and "the very bottom center of each user
interface screen" wording etc., when one digs into the details.

--Craig Muth

[Matthew Flaschen]

Craig Muth wrote:
> My larger point is that I think attribution
> could be a middle-ground between allowing proprietary derivative works
> (a la BSD) and not allowing them (a la GPL), which could be a
> compelling option for certain types of projects looking for a license.

The issue is that we are currently considering a *generic* attribution
license.  It would have to be applicable to any modifiable license,
including the GPL.  Thus, redistribution could be more burdensome than
the ordinary GPL, not less.

> An improved attribution license/provision could give some projects an
option to
> get some benefit, without going as far as restricting commercial
> projects from using them without releasing their source and thus
> greatly reducing their pool of potential adopters.

I think the more important issue is the effect on further redistribution
of the project as open source.  Some licenses the GAP applies to will be
copyleft, and even if they aren't, some redistributors will keep the
modifications open source (OSD 3).  Will these logos become too
burdensome on their projects, e.g. because of technological restrictions
(OSD 10)?

This reminds me.  OSI has begun to come out against license
proliferation, but approving GAP would effectively approve 60-something
licenses, all of which are near-identical to their parents; you have to
wonder whether that alone (regardless of the content of GAP) is a big
mistake.

Matthew Flaschen