[beyond-licensing] quick review of scope, resources, and goals
Matthew Taylor
matt at numenta.org
Wed Apr 13 19:41:48 UTC 2016
+1
---------
Matt Taylor
OS Community Flag-Bearer
Numenta
On Wed, Apr 13, 2016 at 11:57 AM, Karl Fogel <kfogel at red-bean.com> wrote:
> I thought it might be worth mentioning that I had a quite different conception (compared to recent discussions) of what the Beyond Licensing Working Group is for.
>
> I'm not sure it's actually true that transparency and democracy are necessary for open source projects to function well. Transparency and democracy are incredibly important things in the non-bit-based world, where physical goods and finite resources must be allocated in some fair way to ensure that Genghis Khan doesn't take over and control everything. No argument there. But because open source projects can just be forked (unlike non-bit-based things), I don't think the OSI ever needs to get into the business of recommending effective ways to run projects.
>
> Yes, it's true that for certain kinds of open source projects, of a certain scale and demographic, formal governance processes and transparency are "better" for some reasonable definition of "better" (presumably some combination of technical quality, project efficiency, and the happiness of the participants). But not every project is like that, and it's an exceedingly complex question; I'm not sure OSI has any call to ever dive into that kind of thing. Many very successful projects are not run that way, and who's to say they're making a mistake?
>
> Instead, what Beyond Licensing means IMHO is "things the OSI and allies can do, that don't involve software copyright licenses, to help open source as a cause". Hence my original two examples: an OSaaS standard (w/ logo etc), and trying to persuade companies to stop using "community" when they really mean "open source" (and the corollary, stop using "enterprise" when really mean "proprietary").
>
> These things are about labeling and clarity of conception -- they're about preventing dilution or diminution of open source as a brand, and about helping people who don't pay as close attention as we do to recognize and value open source when they encounter it. These proposals don't get into how to run open source projects; they just start from the assumption that "open source" means simply "source code released under an open source license", which is what open source has always meant to the OSI. If we start making "open source" *also* be about how you run your project community, we run the risk of damaging open source as a brand, and confusing people about what it really means at its core.
>
> Naturally, there are many fascinating and important things to know about working with open source communities -- heck, I run a whole company devoted to providing that knowledge on a commercial basis :-). But the OSI's role is special. It and the FSF together are uniquely qualified to do certain things, and rather unqualified to do others. I think we should be very careful about identifying those "others" and steering away from them.
>
> Best regards,
> -Karl
>
> Stephen Walli <stephen.walli at gmail.com> writes:
>>I really like where you're going here with your ideas. A couple of
>>things I would want to capture better as we discuss models of success
>>beyond the license attributes that define an open source license.
>>
>> I think transparency in community is hugely important. More so
>> than governance. We can have variations on governance from well
>> documented meritocracies (e.g. The Apache Way, The Debian Social
>> Contract) to the undocumented dictatorship of Linux and they
>> encompass a collection of hugely successful open source
>> development communities. So transparency of meeting minutes,
>> email discussions, bug lists, etc. to me is more important than
>> trying to describe the various governance structures. People see
>> how the community functions regardless of its documented (or
>> undocumented) governance. I think the failure of some of the
>> "modern, corporate" collaborations will be their lack of complete
>> transparency.
>> I think we should be careful as we articulate things that are
>> part of an open, collaborative, liberally licensed software
>> development community versus attributes of well constructed
>> software. Software construction discipline (configuration
>> management, version control, batch-oriented recipe driven builds,
>> etc.) is an aspect of all scalable software, regardless of
>> whether developed in highly proprietary closed companies or
>> highly successful open source communities. There are lots of open
>> source licensed software packages on the forges that lack
>> community and lack discipline. There are lots of proprietary
>> products that scale the same as successful communities. The
>> models for the early tools came out of places like the sometimes
>> very proprietary world of Bell Labs with PWB, make, sccs, etc.
>>
>>I may have poorly stated my initial position on picking a focus (or
>>carefully choosing multiple foci). I was not suggesting the OSD with
>>its licensing attributes couldn't encompass licenses that embody
>>software freedom with its focus on the rights of the user. I was
>>suggesting each definition (OSD and software freedom) was powerful
>>because it picked a focus for its message.
>>
>>cheers, always
>>stephe
>>
>>On Sun, Apr 10, 2016 at 7:08 PM, Luis Villa <luis at lu.is> wrote:
>>
>> I'm afraid I'm jumping in to the middle of this discussion, not
>> having been part of the initial discussion. I'm going based on
>> what I've seen on the wiki, and the initial discussions we had
>> about this topic 1+ year ago at the board level.
>>
>> (Overall, to be clear, I strongly support the "beyond licensing"
>> exercise - I think it is critical to the future of OSI and FOSS
>> more broadly. And I support software freedom; I think it is
>> ethically important and am a dues-paying member of FSF, though I
>> would have opposed the addition of "software freedom" to the OSI
>> mission statement had I still been on the board, mostly for the
>> same reasons I'm going to give below.)
>>
>> (tl;dr: open source's developer-focused pragmatism is related to,
>> but quite different than, any existing definition of software
>> freedom; blurring those distinctions risks losing lots of
>> important context and learnings.)
>>
>> On Sun, Apr 10, 2016 at 8:46 AM Allison Randal <
>> allison at opensource.org> wrote:
>>
>> In fact, software freedom is the direct cause of the
>> practical
>> benefits of open source. And at some point, those abstract
>> benefits of
>> software freedom are important in telling the difference
>> between open
>> source and a license that only shares the source code but
>> doesn't grant
>> the right to use, modify, and redistribute it. At first
>> glance it might
>> seem "like open source", but the fauxpen source license only
>> gives you a
>> fraction of the practical benefits of open source.
>>
>> Open source and software freedom aren't two different things,
>> they're
>> two ways of talking about the same thing.
>>
>>
>> I don't think that's correct; perhaps more importantly for this
>> group, it isn't consistent with a "beyond licensing" approach to
>> open source.
>>
>> Definitionally, the reason why software freedom isn't the same as
>> open source "beyond licensing" should be obvious: no one has
>> articulated a coherent, useful definition of software freedom
>> that goes beyond licensing, so you can't go "beyond licensing"
>> without also going beyond software freedom.[1] More arguably,
>> FSF's freedoms are (correctly!) focused on the freedoms of the
>> user,[2] open source has focused on developers.[3]
>>
>> Practically, I think there are many activities/behaviors that
>> would widely be labeled as "open source" but:
>> have nothing to do with licensing/source availability
>> are not part of "software freedom" as anyone has ever defined
>> it that I'm aware of (i.e., if you failed to do them, FSF
>> would still sign off, but many open source developers would
>> be grumpy)
>> are being rapidly embraced/extended by proprietary software
>> (so are very relevant to the future of both free and open
>> software, and certainly to the future of OSI)
>> Some examples of these activities, just offhand (don't have time
>> to elaborate a ton tonight):
>> revision control: historically something done poorly by
>> proprietary software development; brought to the forefront as
>> a best practice, and best tools developed aggressively, by
>> FOSS communities; now assumed by all software (free, open, or
>> otherwise) as a minimum necessary for beginning any
>> development. Nothing to do with freedom per se; widely
>> associated with open source development.
>> publicly-readable bug tracking: key part of non-licensing
>> open source community-focused development; now adopted widely
>> even by Apple. Nothing to do with freedom or licensing.
>> collaborative decision-making: So little to do with
>> "freedom" that RMS is used as the posterchild for how to do
>> this wrong. Considered a key part of any healthy open source
>> community.
>> communication and distributed development: IRC and mailing
>> lists to tie together distributed developers were rare in
>> proprietary software pre-OSS; they're now de rigeur to the
>> point of supporting multiple "unicorns" (Slack and Github).
>> distributed governance: free software licenses are one
>> mechanism for ensuring distributed governance, but they
>> aren't the only one; this is why you see standards bodies and
>> industry consortia adopting many of our governance patterns,
>> not just (and often not ever) our licensing.
>>
>> The common theme among all of these, of course, is how developers
>> work together. Doing that right gives you most of the benefits of
>> open source, regardless of licensing. That's why proprietary
>> software is embracing these things pretty wholesale. It's
>> telling, I think, that no one calls these "free" development
>> practices; they're open development practices (recent example).
>>
>> So, yeah, I think OSI does itself, open development practices,
>> and the broader movement a disfavor by tying itself too deeply to
>> software freedom. When those are (incorrectly) touted as
>> synonyms, important nuance is lost.
>>
>> Sorry for the brevity - this is an important topic that deserves
>> less force and more nuance, but I'd rather put the issues on the
>> table badly than not at all.
>>
>> Luis
>>
>> [1] As some of you even saw in person, I've started talking about
>> a non-licensing theory of software freedom myself, but it's very
>> definitely in an overall vacuum: http://lu.is/?p=2917
>> [2] http://www.gnu.org/philosophy/free-sw.en.html uses "user" 16
>> times, developer 6x, "community" 2x
>> [3] ESR engaged in a lot of revisionist history in old versions
>> of http://www.opensource.org/history, but one claim that I think
>> was accurate (and left in when I rewrote it) was the statement
>> that OSI grew out of a determination to "advocate for the
>> superiority of an open development process". (emphasis added by
>> me in this email)
>>
>>
>>
>>
>>--
>>Stephen R. Walli
>>mailto: stephen.walli at gmail.com
>>mobile: +1 425 785 6102
>>blogs: http://stephesblog.blogs.com (Once More unto the Breach)
>> https://opensource.com/user_articles/16271 (opensource.com)
>>Flickr: http://www.flickr.com/photos/stephenrwalli/
>>LinkedIn: http://www.linkedin.com/in/stephenrwalli
>>Twitter: @stephenrwalli
>>
>>
>>_______________________________________________
>>beyond-licensing mailing list
>>beyond-licensing at opensource.org
>>https://lists.opensource.org/cgi-bin/mailman/listinfo/beyond-licensing
> _______________________________________________
> beyond-licensing mailing list
> beyond-licensing at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/beyond-licensing
More information about the beyond-licensing
mailing list