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

[Chuck Swiger]

On Dec 15, 2006, at 6:52 AM, Craig Muth wrote:
> IMO the original issue raised by the SugarCRM people is important.
> For projects that want to open source a compelling and useful project,
> the prospect of your code being rebranded (with little or no
> modification) and/or sold (or supported for money, arguably a close
> cousin to selling) with no "by the way these guys did all the work" is
> a daunting one.

When you choose to open source a project, you are explicitly putting  
it out into the world for other people to use, change, modify,  
resell, support, and so forth.

If a project isn't OK with people reselling their software, then the  
people writing the code don't actually want to put it under an open  
source license.  They should simply use a restrictive license with a  
"no commercial use" clause instead, and call it "source available",  
"freeware", "trialware", or some such....

> Pulling someone else's code into yours and
> distributing it under your project's name is de facto attributing it
> to yourself.

Changing an existing attribution when you have not written or  
extensively modified that software is considered in extremely bad  
taste; if the changed attribution could be considered fraudulent (ie,  
deliberately misrepresenting who the original author was), they would  
probably constitute a violation of copyright.

I've only heard of this happening a handful of times (the g4u issue;  
http://www.feyrer.de/g4u/g4l.html).

> If the end result was that you added something of value
> to the code, then it was good for open source.  If you did not improve
> the code, but only rebranded and profited from it, then I would argue
> that it was *very bad* for open source (in that it discourages coders
> from releasing their code as open source) and the spirit of open
> source will visit you three times in the night:)

There's nothing wrong with profiting from reselling open source  
software.  Red Hat, Ubuntu, Debian and Novell/SuSE all do so, as do  
various BSD-derived platforms such as MacOS X....

--
-Chuck

[Brian Behlendorf]

On Fri, 15 Dec 2006, Rick Moen wrote:
> Quoting an offlist side-discussion I was recently in:   Code reuse,
> albeit somewhat rarer than often believed, is an important enough core
> notion of open source to be referred to (though without specific mention
> of _multiple_ codebases) in OSD#3.  Like forking, it's (IMVAO) an
> important reserve power, regardless of how often used in practice.

I agree.

On Fri, 15 Dec 2006, Craig Muth wrote:
> Although I think many here on the list have made valid refutations for
> many points raised by SugarCRM, I think this one still stands:
>
>> I guess they didn't notice that it's not open source.  They downloaded it,
>> accessed the source, modified it, forked it, and redistributed it.  If it
>> smells like open source and tastes like open source...maybe it's open
>> source?

That was an argument for consensus by bullying and establishing
"Wikiality" (Colbert[1]).  I guess it's this list's and OSI's job not just
to determine whether there's some sort of provision that could work, but
once defined, to inform the public when someone's selling them a bill of
goods labelled "Open Source" when it really isn't.  Otherwise, the
revelancy of the mark and this organization is nil.

On Fri, 15 Dec 2006, Michael Tiemann wrote:
> I've already addressed this, but can you imagine "Powered by
> Shakespeare" at the bottom of every movie that has a plot that can be
> related to one of his works?

I think that's an overstretched analogy.  We're not talking about separate
software that might be "related" to some other original piece - we're
talking about derivative works.  If the Bard still had copyright, you can
rest assured his estate would be asking for credit in some form anytime
someone created a plot that paid more than passing coincidence or subtle
homage to the Tempest.  (Many filmmakers don't even need to be compelled
to do so - some proudly state their influences.)  The widespread use
of the Creative Commons' attribution clause suggests that it can be an
important motivation for creating public works.

Michael, are you against any form of attribution clause?  Or simply put
off (as am I) by the specific one suggested by Ross?

  Brian



[1] http://en.wikipedia.org/wiki/Wikipedia_in_popular_culture

[Michael Tiemann]

On Fri, 2006-12-15 at 11:53 -0800, Brian Behlendorf wrote:

> Michael, are you against any form of attribution clause?  Or simply put
> off (as am I) by the specific one suggested by Ross?

I am not against any form of attribution clause.  In fact, when
opensource.org moves to its shiny new incarnation (hopefully soon) it
will be licensed under CC:BY 2.5.  We chose CC:BY because we want to
benefit from attribution, even if the user doesn't SA.

I see a distinction, for example, between splash-screen attribution and
continuous display attribution.  I see a distinction between going to
the logical equivalent of an About box and getting truth (proper
attribution) and fiction (a ripped and replaced claim that does not
match the reality of the source code).  I believe 100% that it is
legitimate that authors should expect their names to be presented when
users probe the provenance of the code.  For example, I am happy that,
after 10 years of retirement from hacking GNU C++, I'm still listed
here: http://gcc.gnu.org/onlinedocs/gcc/Contributors.html .  That's
proper attribution in my book, and the GPL's strong guarantee of source
availability make that attribution effective.

I am sympathetic to the fact that in the world of SOA there is an issue
where the GPL (and other OSS licenses) do not necessarily provide an
effective guarantee that the software you use, over the wire, provides
you equal opportunity to access the source.  But I also believe that the
proper remedy for that problem is for users who care about OSS to say
"OK, so you don't have to give me the source if I use your service.
BUT, I can refuse to use your services unless you provide me with
sources that /are/ the sources running on the website.  And if you do,
I'll consider that to be open source for me, and I'll live by all those
open source rules, including copyright and proper attribution, whether I
redistribute, modify, build services that integrate with your services,
or run the code as a service myself."

M

[Rick Moen]

Quoting Chuck Swiger (chuck@...):

[Misrepresentation of authorship:]

> I've only heard of this happening a handful of times (the g4u issue;  
> http://www.feyrer.de/g4u/g4l.html).

FYI, the newer maintainers of g4l corrected this misdeed (including
retroactive acknowledgement of their debt to Hubert Feyrer, and of the
misdeed committed by prior maintainer "nme", in all new releases, despite
their complete rewrite since the offending g4l v. 0.12 release), after a
number of people including me strongly confronted "nme" in public.[1]

I kept Hubert apprised of all those developments, and a couple of months
ago asked if he'd please acknowledge the new maintainers' corrective
action on his page (referenced above).  He hasn't yet done so, but I
hope he will at some point.

[1] Note in particular Freshmeat comments around Jan. 14 2005,
immediately after the story was first mentioned here:
http://freshmeat.net/projects/g4l/  Though new maintainer Frank Stephen
at first dragged his feet against fully fixing the situation (on grounds
of his rewrite), he and subsequent co-maintainer Michael D. Setzer II
quickly changed course, and did the right thing, i.e., also adding
retroactive acknowledgement.

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> How so?  I'm attempting to give my perspective on section 8, which
> everyone had been discussing.

Your point might clearer if you'd quote relevant material from the
preceding thread, but unfortunately you did not in the post to which I
replied, so I could only go by memory or find relevant prior posts in
the Web archive.

In any event, this is starting to get extremely silly:  A codebase under
GPLv2 with some specific geographic-restriction addendum based on clause
#8 is _not_, in fact, under the same licence as one under GPLv2 without
that additional clause.

Are you entirely done?

--
Cheers,       A positive attitude will not solve all your problems, but it will
Rick Moen     annoy enough people to make it worth the effort. -- Herm Albright
rick@...

[Chuck Swiger]

On Dec 15, 2006, at 3:00 PM, Rick Moen wrote:

> Quoting Chuck Swiger (chuck@...):
>
> [Misrepresentation of authorship:]
>
>> I've only heard of this happening a handful of times (the g4u issue;
>> http://www.feyrer.de/g4u/g4l.html).
>
> FYI, the newer maintainers of g4l corrected this misdeed (including
> retroactive acknowledgement of their debt to Hubert Feyrer, and of the
> misdeed committed by prior maintainer "nme", in all new releases,  
> despite
> their complete rewrite since the offending g4l v. 0.12 release),  
> after a
> number of people including me strongly confronted "nme" in public.[1]

This was well done on your and other's parts; thanks for providing  
some more details.

> I kept Hubert apprised of all those developments, and a couple of  
> months
> ago asked if he'd please acknowledge the new maintainers' corrective
> action on his page (referenced above).  He hasn't yet done so, but I
> hope he will at some point.

I suppose you could ping him again, perhaps at the start of 2007...

--
-Chuck

[Matthew Flaschen]

Rick Moen wrote:
> Your point might clearer if you'd quote relevant material from the
> preceding thread, but unfortunately you did not in the post to which I
> replied.

My mistake.  I thought I had.

> In any event, this is starting to get extremely silly:  A codebase under
> GPLv2 with some specific geographic-restriction addendum based on clause
> #8 is _not_, in fact, under the same licence as one under GPLv2 without
> that additional clause.

I agree.  I was just pointing out that this *was* a copyright issue.  I
wasn't the one who brought up clause 8 to begin with.  Now we're done. :)

Matt

[Ben Tilly]

On 12/15/06, Rick Moen <rick@...> wrote:
> Quoting Matthew Flaschen (matthew.flaschen@...):
>
> > How so?  I'm attempting to give my perspective on section 8, which
> > everyone had been discussing.
>
> Your point might clearer if you'd quote relevant material from the
> preceding thread, but unfortunately you did not in the post to which I
> replied, so I could only go by memory or find relevant prior posts in
> the Web archive.

If you wish to find relevant material, I was the one who raised #8 in
the GPLv2.  And my point was that immiscibility between 2 codebases
under essentially the same license is not new for open source.

> In any event, this is starting to get extremely silly:  A codebase under
> GPLv2 with some specific geographic-restriction addendum based on clause
> #8 is _not_, in fact, under the same licence as one under GPLv2 without
> that additional clause.

The starting comment for this subthread was your saying that we had
"immiscibility of two codebases under the _same_ licence." when there
were two codebases with similar attribution requirements but
requirements to attribute different companies.

I think that is as much (or not) the same license as GPLv2 and GPLv2
with optional restriction added based on clause 8.  So this kind of
conflict in attribution licenses is not new.  (It is, however,
substantially more likely.)

> Are you entirely done?

Hopefully we're all done, but I fear this will drag on some more.
However I did want to refresh your memory on how this subthread got
started.

Ben

[Rick Moen]

Quoting Ben Tilly (btilly@...):

> If you wish to find relevant material, I was the one who raised #8 in
> the GPLv2.  And my point was that immiscibility between 2 codebases
> under essentially the same license is not new for open source.

But that was _not_ the same licence.  Moreover, even in your
hypothetical, they _are_ miscible; the derivative work is merely not
lawful in the one country where the upstream coder so specified for
legal reasons, per clause 8.

> The starting comment for this subthread was your saying that we had
> "immiscibility of two codebases under the _same_ licence."

And so you felt obliged to drag in a hypothetical that did _not_ use the
same licence, but was in fact miscible anyway -- and managed thereby to
utterly ignore and distract from my point.  Bully for you, Ben.  Well done.

Meanwhile, struggling painfully back to the point, I'll just quote from
my side of an offlist conversation to someone else, on the point I _was_
actually talking about, as opposed to your recent irrelevant sideshow:



To answer your question:  Sure, but this _isn't_ licence combinatorics,
but rather an effect that happens with multiple borrowings from
codebases all under the _same_ licence.

The point is that a natural coding activity, of code reuse without
any licence incompatibility, is substantively blocked by the particular
form of badgeware requirement referred to in the Subject header.  (I'm
trying to be careful about logic:  The same problem presumably might not
exist in other badgeware provisions not under discussion.)

> [code reuse is less common than often asseumed]

True enough.  However, it's an important enough core notion of open              
source to be referred to (though without specific mention of _multiple_          
codebases) in OSD#3.  Like forking, it's (IMVAO) an important reserve            
power, regardless of how often used in practice.                                
                                                                                 
> [multiple "badgeware" advertising clauses don't _block_ reuse, just
> make it a bit messy]

As a poster just pointed out, with at least one recent formulation of            
a badgeware provision (the one with requirement of positioning in                
the exact centre bottom), it _is_ actually impossible.                          
                                                                                 
Moreover, even the theoretically possible cases might be reasonably              
interpreted as making use infeasible in practice, e.g., three or more            
mandated logos strike me as not something a reasonable user would                
tolerate.                                                                        
       
> [OSI helping distinguishing between reasonable and unreasonable burdens
> would be a good thing; but what is immediately relevant is compliance
> with the extant OSD criteria or not.]

Indeed.

As things stand, with Alfresco and others so far specifically eschewing
an "if any" qualifier on the "user interface" wording, I'd speculate
that OSD#10 is a bigger obstacle, anyway.

> [What's wrong with three or more logos?  Haven't I seen commercial
> webmail screens?  Mailstream technical Web sites?]

I can't help thinking this is a sloppy comparison.                              
                                                                                 
Users of Web-based mail clients and mainstream techie Web site are              
entering into a contractual business relationship for services.  (It            
remains that, regardless of whether money changes hands, as I went to            
some pains to remind people on
http://linuxmafia.com/faq/Essays/winolj.html .)  
They are consenting to being barraged by advertising, of that and other          
sorts, pursuant to that business relationship.                                  
                                                                                 
However, even given that fundamentally different nature of the event --          
the user is not making code reuse, and is not directly using it at all,          
as you well know (as this model has been discussed to death back to the          
OpenSales licensing symposiums I think we both attended, and in other            
places), the Web site does not bear multiple logos prominently placed on        
the site ("Lovingly crafted code from Foo!", "Lovingly crafted code from        
Bar!", "lovingly crafted code from Baz!") that were legally mandated            
upon the site-hosting company by software licences.                              
                                                                                 
You seem to come close, above, to saying "Aww, be a sport, Rick.              
Logos are everywhere in business; what are a few more between friends?"          
                                                                                 
However, the question is not whether [multiple] advertising logos are OK        
in a business setting, Web, app-server, or otherwise, but rather whether        
a requirement to retain them, mandated by software licensing in a way            
that would cause them to accumulate through code reuse, is compatible            
with the principles articulated in OSD#3 and maybe OSD#6 -- leaving              
aside for a moment the larger problem of OSD#10.                                
                                                       

[John Cowan]

Rick Moen scripsit:

> To answer your question:  Sure, but this _isn't_ licence combinatorics,
> but rather an effect that happens with multiple borrowings from
> codebases all under the _same_ licence.

I guess we are not done yet.

Suppose someone comes to me and said "Are you John Cowan?", receives
an affirmative answer, and then goes to you and asks you "Are you
John Cowan?"  is told "No", and then complains because our answers
were inconsistent.  They aren't, because although the two questions are
expressed in the same words, they aren't the same question.

By the same token, a license that says "Put my badge centered on the
top" and another license from another programmer that says "Put my
badge centered on the top" are *not* the same license, because of the
indexicalness of "my".  Therefore it's hardly surprising that they are
inconsistent.

> The point is that a natural coding activity, of code reuse without any
> licence incompatibility, is substantively blocked by the particular
> form of badgeware requirement referred to in the Subject header.

But there is a license incompatibility.  You've just pointed it out.

> Moreover, even the theoretically possible cases might be reasonably
> interpreted as making use infeasible in practice, e.g., three or
> more mandated logos strike me as not something a reasonable user
> would tolerate.

This is what makes the old-BSD advertising clause obnoxious; nevertheless,
the four-clause BSD is still presumably open source.  (OSI has never
bothered to actually certify it, but it's close to the old Apache license,
which they did certify.)

--
"But I am the real Strider, fortunately,"       John Cowan
he said, looking down at them with his face     cowan@...
softened by a sudden smile.  "I am Aragorn son  http://www.ccil.org/~cowan
of Arathorn, and if by life or death I can
save you, I will."  --LotR Book I Chapter 10

[Rick Moen]

Quoting John Cowan (cowan@...):

> > To answer your question:  Sure, but this _isn't_ licence combinatorics,
> > but rather an effect that happens with multiple borrowings from
> > codebases all under the _same_ licence.
>
> I guess we are not done yet.
>
> Suppose someone comes to me and said "Are you John Cowan?", receives
> an affirmative answer, and then goes to you and asks you "Are you
> John Cowan?"  is told "No", and then complains because our answers
> were inconsistent.  They aren't, because although the two questions are
> expressed in the same words, they aren't the same question.

This has all gotten rather silly.  

Apparently, someone (perhaps you) recently posted a rather pointless
hypothetical about two "GPLed" codebases, one with a clause 8 addition
making it unlawful to use in some specific country -- claiming that this
was an already existing example of two codebases being incompatible
despite being under the same licence -- with the alleged point, such as
it was, being that immiscible codebases under the same licence were
(allegedly) nothing new.

My reply, once I was told the exact hypothetical and realised just how
dumb it really is, was thus:  (1) No, those are not under the same
licence, and (2) no, anyway, they _remain_ miscible codebases, with the
derivative work merely unlawful in the one particular country where it
has legal problems.

At this point, I'm quite done with this inane digression, and would
appreciate returning to the main discussion about "attribution"
(mandatory graphical advertising) clauses and OSD #3, 6, and 10.


For example:

> By the same token, a license that says "Put my badge centered on the
> top" and another license from another programmer that says "Put my
> badge centered on the top" are *not* the same license, because of the
> indexicalness of "my".  Therefore it's hardly surprising that they are
> inconsistent.

I'm not sure what your point is.  Those requirements _could_ physically
be simultaneously complied with.  The derivative work sporting two
mandatory advertising logos would start looking pretty silly, though.
Four or five, more so.  (See below.)


> > The point is that a natural coding activity, of code reuse without any
> > licence incompatibility, is substantively blocked by the particular
> > form of badgeware requirement referred to in the Subject header.
>
> But there is a license incompatibility.  You've just pointed it out.

I'm afraid I fail to grasp any essential impossibility to requiring
multiple mandatory logos (other than cases like multiple logos required
to be, e.g., in the exact centre bottom, as one provision recently
discused requires); maybe you can explain that to me.


> > Moreover, even the theoretically possible cases might be reasonably
> > interpreted as making use infeasible in practice, e.g., three or
> > more mandated logos strike me as not something a reasonable user
> > would tolerate.
>
> This is what makes the old-BSD advertising clause obnoxious; nevertheless,
> the four-clause BSD is still presumably open source.

Sorry, there is a vital difference in kind:  

* 3. All advertising materials mentioning features or use of this software
*    must display the following acknowledgement:
*      This product includes software developed by the University of
*      California, Berkeley and its contributors.

That BSD clause's encumbrance was not on what the code may and may not
(or must and must not) contain or become -- but rather on advertising
about the codebase: its features, and its usage.

My point is that an "attribution" (mandatory graphical advertising)
software licence clause, after its effect has been multiplied through
code reuse to requiring _three or four or five_ mandatory graphical
logos festooned around every screen, starts to make reasonable reuse
infeasible in practice.  That was not true of the "obnoxious" BSD clause #3.

[Nick Moffitt]

Rick Moen:
> Apparently, someone (perhaps you) recently posted a rather pointless
> hypothetical about two "GPLed" codebases, one with a clause 8 addition
> making it unlawful to use in some specific country -- claiming that
> this was an already existing example of two codebases being
> incompatible despite being under the same licence -- with the alleged
> point, such as it was, being that immiscible codebases under the same
> licence were (allegedly) nothing new.

So I may be only offering a distraction here, but it is my understanding
that:

  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".
  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.  

So this hypothetical situation seems to be about six or seven kinds of
unlikely, as opposed to the usual two or three that the typical GPL
straw man tends to create.

--
"N'aimez pas votre voiture?                             Nick Moffitt
Alor, l'heure est arrive pour la brulé!"          nick@...
        -- Mark Jaroski

[Matthew Flaschen]

Craig Muth wrote:
> What I proposed was bad for open source was specifically when
> companies rebrand and charge money without contributing back.

Obviously, OSD #1 explicitly allows this, which in my eyes is enough
reason to stop  complaining about it.  I would argue further that any
use of open source freedoms is good for open source.  The market can
decide which distributions of open source software to acquire or buy.

If distributions/programs don't innovate, people will likely abandon
them, as noted by Michael Tiemann.

> Not all projects are like this though.  Not all projects have a huge
> group of contributors to leverage.  Many projects deal with a very
> specific application or component, and can't reasonably expect help
> from contributors.  This is why the OSI has approved more than just
> the GPL - because not all projects are alike.

I wasn't around for most, but it seems they approved them because they
comply with the OSD.  For all the back-and-forth, and "Well if they
just..." the GAP as submitted doesn't comply with OSD #10.  It may not
even really comply with OSD #3.  More importantly, the submitter hasn't
expressed willingness to make the necessary adjustments so it would comply.

Matthew Flaschen

[Matthew Flaschen]

Michael Tiemann wrote:

> And if you do,
> I'll consider that to be open source for me, and I'll live by all those
> open source rules, including copyright and proper attribution, whether I
> redistribute, modify, build services that integrate with your services,
> or run the code as a service myself."

What's wrong with making this arrangement explicit through a license
(roughly) along the license of the Affero GPL?  I think it's too early
to approve such a license, but the basic idea makes sense to me.

Matthew Flaschen

[Matthew Flaschen]

Craig Muth wrote:
> However,
> the preferred option for projects of large scope and with large
> committer bases will likely remain the unmodified GPL (the
> contributions by a large number of committers benefits you by
> improving your code and makes your contribution less by proportion,
> thus outweighing the lack of credit given and making attribution less
> deserved).

The GPL *gives* credit.  When you modify GPL code, 2a guarantees that
you must/can put a notice in the source describing your modification
(and it's implied that this shouldn't be removed).  2c further
guarantees that a copyright notice is displayed when the program is run
interactively; note that this isn't technology-specific and allows for
non-interactive programs.  Such a copyright notice either lists all
authors, or can refer to a list of authors elsewhere.  Moreover, this
copyright notice must be "appropriate" (i.e. accurate) because of
section 1 and 2c.

Matthew Flaschen

[Matthew Flaschen]

Rick Moen wrote:
> I'm afraid I fail to grasp any essential impossibility to requiring
> multiple mandatory logos (other than cases like multiple logos required
> to be, e.g., in the exact centre bottom, as one provision recently
> discused requires); maybe you can explain that to me.

I think someone *may* have said two licenses that both require logos at
the *very top left* (for example) are incompatible because of course
only one can actually be in the exact top left.  However, I don't think
this is a real issue; it would be acceptable in practice to put them
both as close as possible to the top left.

> That BSD clause's encumbrance was not on what the code may and may not
> (or must and must not) contain or become -- but rather on advertising
> about the codebase: its features, and its usage.

Apache License 1.1 (which is approved) has a quite similar clause:

 "3. The end-user documentation included with the redistribution, if
any, must include the following acknowledgment:

    "This product includes software developed by the Apache Software
Foundation (http://www.apache.org/)."

Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear."

Matthew Flaschen

[Craig Muth]

> > What I proposed was bad for open source was specifically when
> > companies rebrand and charge money without contributing back.

Matthew Garrett wrote:
> Given that the BSD license (one of the original open source licenses)
> explicitly allows this, and given the continued popularity of such
> licenses, I think it's unlikely that this belief is especially common.

I agree that no one wants to throw away the BSD license because of
this.  However if you released some software under BSD and someone
grabbed your code and simply replaced all instances of "YourProject"
with "Microsoft" (for example) and stuck it on their website and
charged for it, I doubt many would consider this particular act good
for open source, though I grant it wouldn't voilate the license.  I'd
buy calling it a necessary evil for certain licenses.

Nicholas Goodman wrote:
> I'm trying to figure out why these companies find the term
> "shared source" or "public source" or "community source" so offensive.
> I'm NOT dogging freeware.   Freeware is good for users, not as good as
> Open Source, but it's good for users.  :)

If we're talking about projects whose source is open - for
downloading, modifying, redistributing, and selling - and assuming
they get their license to reasonably conform to the OSD, who are we to
say it's not open source?

Chuck Swiger wrote:
> If a project isn't OK with people reselling their software, then the
> people writing the code don't actually want to put it under an open
> source license.  They should simply use a restrictive license with a
> "no commercial use" clause instead, and call it "source available",
> "freeware", "trialware", or some such....

But I don't think any project in question isn't OK with people
reselling their software (although I can only speak for myself).  It
is true that an attribution provision names terms which must be
conformed to upon sale/redistribution of a *modifed* version, but the
GPL and other licenses are a precedent for that.

--Craig Muth

[Matthew Flaschen]

Craig Muth wrote:

> However if you released some software under BSD and someone
> grabbed your code and simply replaced all instances of "YourProject"
> with "Microsoft" (for example) and stuck it on their website and
> charged for it, I doubt many would consider this particular act good
> for open source, though I grant it wouldn't voilate the license.

Open source is a set of freedoms.  It makes no sense to say something is
good for freedoms; it can only be good for people.  This is certainly
good for the reseller.  It's bad for consumers, since they're paying but
getting no added value (and possibly not even getting source).  It's
also arguably bad for the original developer since they're losing
attention to someone who has contributed nothing; however, BSD
developers might not be care.  However, if there were truly *no* added
value, it would come out pretty quickly and people would move back to
the original package.

> If we're talking about projects whose source is open - for
> downloading, modifying, redistributing, and selling

The great thing about OSI approval is we don't just test based on
arbitrary verbs or whether they happen to be using a non-trademarked
phrase.  We have a handy OSD, and we can go down point-by-point.  I (and
many others) did that, and found the GAP very dubious on OSD #10.

> - and assuming
> they get their license to reasonably conform to the OSD, who are we to
> say it's not open source?

How about we say just "*conform*" and call it even?

> It is true that an attribution provision names terms which must be
> conformed to upon sale/redistribution of a *modifed* version, but the
> GPL and other licenses are a precedent for that.

By that argument, any license that allows selling modified versions is
OSI-compliant.  Any other details are just terms...

Matthew Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> I think someone *may* have said two licenses that both require logos at
> the *very top left* (for example) are incompatible because of course
> only one can actually be in the exact top left.

I saw one cited where the logo was supposed to be in the exact centre, a
specified distance from the bottom.

> > That BSD clause's encumbrance was not on what the code may and may not
> > (or must and must not) contain or become -- but rather on advertising
> > about the codebase: its features, and its usage.
>
> Apache License 1.1 (which is approved) has a quite similar clause:
>
>  "3. The end-user documentation included with the redistribution, if
> any, must include the following acknowledgment:
>
>     "This product includes software developed by the Apache Software
> Foundation (http://www.apache.org/)."
>
> Alternately, this acknowledgment may appear in the software itself, if
> and wherever such third-party acknowledgments normally appear."

Yes.  Please note that in neither case does this does not substantially
interfere with the OSD-detailed ability to use the software for any
purpose.  My earlier point was that, through accumulation of mandated
logos in consequence of code reuse, a badgeware provision may tend over
time to substantively interfere in exactly the way that old-BSD and APL
1.1 doesn't.  ;->

--
Cheers,                   Now, it's time to hack the real world, and let other
Rick Moen                 people write Web sites about it.
rick@...                                   -- Donald B. Marti

[Rick Moen]

Quoting Craig Muth (craig.mu@...):

> I agree that no one wants to throw away the BSD license because of
> this.  However if you released some software under BSD and someone
> grabbed your code and simply replaced all instances of "YourProject"
> with "Microsoft" (for example) and stuck it on their website and
> charged for it, I doubt many would consider this particular act good
> for open source, though I grant it wouldn't voilate the license.  I'd
> buy calling it a necessary evil for certain licenses.

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.

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.


> If we're talking about projects whose source is open - for
> downloading, modifying, redistributing, and selling - and assuming
> they get their license to reasonably conform to the OSD, who are we to
> say it's not open source?

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

--
Cheers,            
Rick Moen                 "Anger makes dull men witty, but it keeps them poor."
rick@...                                   -- Elizabeth Tudor