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

[Sacha Labourey]

Hello Andy,

It seems there is something not mentioned in the AGAINST position 
relative to #3 (OSD-compatible licenses must allow modifications). The 
current position seems to focus only on the "practical" aspect of 
including several GAP licensed codebase in a software (and its impact on 
the screen size), that is not the core issue IMO. GAP licenses do not 
completely allow for modifications as they force developers to stick to 
some runtime behavior developers might otherwise want to change (i.e. 
displaying somebody's logo). While licenses like GPL/LGPL force 
developers to put the list of copyright holders in the distribution 
(i.e. this is a weak form of attribution), it does not impose any 
*runtime* constraint (i.e. I develop the software I really want).

If the OSI were to accept GAP licenses, then I could very well imagine 
new license proposals with similar constraints pop-up in the future. 
Example: a company developing management software could propose a 
license to the OSI that would force derivative work to only contact 
their management server repository URL or to "announce its presence" to 
some license-counting repository that could not be changed by downstream 
developers. They could argue it would be "fair" from a business 
standpoint (much like the attribution logo).

If some companies want to force such GAP behavior, they could license 
their main code under an OSD-compliant license AND bundle their software 
with some proprietary /non-OSS library that will be responsible for 
displaying their logo as well as providing additional "things" 
(features, etc.) that developers will feel are compelling enough so that 
they keep this proprietary library it in their own software (and display 
the logo screen).

As a user of OSD-compliant Open Source software, I want to be able to 
fully modify such code, not just pieces of it. IMO, #3 must apply to the 
complete source code (hence its runtime behaviour), not just a subset of 
it.

Cheers,


Sacha


Andrew C. Oliver wrote:
> As I understand it:
>
> 1. The GAP has been submitted.
> 2. Licenses submissions are judged by the board against the Open 
> Source Definition.
>
> Thus WHETHER GAP should be approved will be judged by the board based 
> on the open
> source definition.
>
> Whether the open source definition should be changed is another matter 
> entirely.  The arguments we're mostly discussing now in which we're 
> trying to form clearly expressed position papers 
> (http://www.buni.org/mediawiki/index.php/GAP_Against, 
> http://www.buni.org/mediawiki/index.php/GAP_For) are based on the open 
> source definition as it is presently expressed, not as the proponents 
> or opponents of the proposal would like the OSD to be.
>
> The below present a fairly decent summary on how we ended up here and 
> why:
>
> http://en.wikipedia.org/wiki/Open_Source_Software
> http://en.wikipedia.org/wiki/Open_source_movement
>
> -Andy
>
> Peter Kloprogge wrote:
>> Which # are you referring within the definition that limits an 
>> attribution provision? #6 or #10 (or perhaps another)?
>>
>> I cannot comment on your other statements as I'm too new to open 
>> source. But it does sound weird if the execution of the definition 
>> (in 10 statements) becomes OSI's mission instead of having a 
>> clear/mission that is executed by 'managing' the definition. Any good 
>> management will have a clear mission and vision and the OSD should be 
>> the best possible definition towards the set mission. So I would be 
>> very disappointed in OSI if indeed the OSD is the core mission!
>>
>> To state that, within my rationale, we could just as well accept 
>> shared source is an insult. If distribution is key to OSI's mission, 
>> shared source won't comply!
>>
>> And once we start reading the front page it also mentions: "This site 
>> is still evolving as we think through the implications of open source 
>> in the commercial world. We don't claim to have all the answers yet, 
>> so mail us <mailto:osi at opensource.org> with your thoughts and 
>> criticisms." And that's what I'm doing, contemplating about how (what 
>> I expect to be) OSI's mission could be better served in the 
>> commercial world.
>>
>> So the question remains: is an attribution provision against the 
>> current OSD and, if so, is that a wise choice?
>>
>> Peter
>>
>>
>>
>> Matthew Flaschen wrote:
>> > Peter Kloprogge wrote:
>> >   >> Reading the arguments I get the strong impression that many 
>> feel an attribution >> provision is not supporting the general open 
>> source idea, but there is no >> definition that limits an attribution 
>> provision.
>> >>     >
>> > Actually, yes there is.  It's called the Open Source Definition 
>> (not to
>> > mention the Free Software definition and the Debian Free Software
>> > Guidelines).
>> >
>> >   >> Just to go back one
>> >> step, the home page of opensource.org clearly states:
>> >>
>> >> " The *basic idea behind open source* is very simple: When 
>> programmers can read, >> redistribute, and modify the source code for 
>> a piece of software, the software >> evolves. People improve it, 
>> people adapt it, people fix bugs. And this can >> happen at a speed 
>> that, if one is used to the slow pace of conventional software >> 
>> development, seems astonishing."
>> >>     >
>> > Why start at the second paragraph?  The first paragraph (indeed the
>> > first sentence) says "Open Source Initiative (OSI) is a non-profit
>> > corporation dedicated to managing and *promoting the Open Source
>> > Definition* for the good of the community [...]" [emphasis added].
>> >
>> >   >> and it also states:
>> >>
>> >> "Open Source Initiative exists to make this case to the commercial 
>> world."
>> >>     >
>> > Not to cater blindly to the commercial world, but to persuade them.
>> >
>> >   >> The key issue here is that providing the possibility to add an 
>> attribution >> provision doesn't hurt the basic idea (if enough 
>> contributors accept it) and it >> certainly helps making a case to 
>> the commercial world.
>> >>     >
>> > The basic idea is the OSD.  The OSD predates OSI (as DFSG) and the OSD
>> > (in current form) is the organization's core mission.
>> >
>> >   >> So OSI should allow (and perhaps even support) attribution 
>> provisions
>> >>     > to fulfill its objectives and
>> >   >> these objectives should take precedence above the ten 
>> definitions - if reasonable >> attribution provisions don't comply 
>> with #10 change #10 and develop specific >> rules with regards to 
>> attribution.
>> >>     >
>> > This would be the tail wagging the dog.  Why not change the OSD so 
>> that
>> > shared source becomes OSI-approved too?  Because we're trying to
>> > persuade companies to use real OSD-compliant licenses.  Letting them
>> > persuade us to call non-compliant licenses open source is a 
>> betrayal of
>> > OSI's mission.
>> >
>> > Matthew Flaschen
>> >
>> >  
>>   
>
>