The month before the Harmony 1.0 release was quiet, and I was starting to wonder if anyone other than the drafting group was even paying attention any more. So, I was pleasantly surprised to see the posts start to appear last week after the Monday release. Some more positive, some more negative, but the most important thing right now is that people are engaging with Harmony, thinking through what the agreement templates mean, and how they fit in the general FLOSS ecosystem. So far I’ve read posts by: Bradley Kuhn, Dave Neary, Jon Corbet, Mark Webbink, Richard Fontana (part 1 & part 2), Simon Phipps, Stephen Walli and a Slashdot mention (glad for links in the comments if you come across others). I’ve observed a few common themes, so I thought it might be useful to take a step back and ponder through them.
Who’s the leader?
Various posts talk about Canonical leading the project, or Amanda Brock, or Mark Radcliffe, or me. For the first few months I was involved in Harmony, I thought it was lead by the SFLC. The surface question seems to generally be whether the “leader” influenced Harmony in a direction against the poster’s philosophy. But there’s a deeper question here: How is it possible to have so many different ideas of who is leading Harmony? Shouldn’t it be immediately obvious who the leader is? The answer is that Harmony has no leader, and since there is no leader, any member of the group looks as much like a leader as any other member of the group. Simon put it best, calling Harmony “the work of a loose grouping of people”. If that seems strange, think about this: In a group made up of so many radically different philosophies, including several who publicly state that they only got involved to keep the process from going off the rails, who would we choose as leader and how would we choose them? Is there anyone in the group who could adequately represent all the diverse perspectives? Anyone who could stand as neutral arbiter? I deeply respect the group of FLOSS lawyers and advocates who have participated in Harmony, and have only grown to respect them more over the past year, but there’s not one person I’d put in that position. Honestly, it’d be some form of cruel and unusual punishment to give anyone the responsibility of herding the rest of us cats. A second thing to think about is whether a group like Harmony really needs a leader. Of the FLOSS lawyers and advocates you know, are any of them shy about expressing their opinions? Do any of them seem likely to hesitate to negotiate for fair representation of their philosophy? The Harmony process works because it’s a table of equals speaking their minds. It could not have worked any other way.
I don’t have confidence in the Harmony documents because of some blessing from some authoritative leader. There is no blessing, no authoritative leader, and if you get right down to it, no one in the world I would want to be that leader or give that blessing. I have confidence in the Harmony documents precisely and only because they were born out of the chaos of collaboration.
What’s the agenda?
As some posters/commenters have pointed out, the Harmony agenda is stated plainly on the project’s website: “We hope that our work will enable more people to contribute code, by reducing the cognitive cost and legal time of reviewing contribution agreements.” It talks about how contributor agreements are “one available tool out of many” and not “a necessary part of all FOSS legal strategies”. So, the public agenda is clear and obvious. But, there’s been speculation about a hidden agenda, or an agenda behind the agenda. Why is that? Why is the simple and obvious answer not enough? I would guess it’s because the posters are students of human nature and know how complex and multi-layered human motivations usually are. The public statement is so straight-forward that they figure there must be more to it, and so speculate on the possibilities of what “more” might be there. I can pretty much guarantee that there are other agendas floating among the Harmony participants. Probably at least 200+ completely different agendas for the 100+ participants, many of them entirely incompatible. I don’t know all the deep and varied motivations of everyone involved (though I know enough to be confident that none of the speculations I’ve read so far are accurate).
The statements on the public website are the set of things that the Harmony drafting group agrees on. We spent a great deal of (probably too much) time hashing those out early in the Harmony process. The reason the public statement is so straight-forward is not because it’s hiding some big secret agenda, it’s because Harmony is so diverse that the simple stated goals are all that we could 100% agree on. For students of human nature, this won’t be too surprising either. Collaboration is rarely about gathering people who agree on absolutely everything, it’s mostly about gathering people who agree on a small set of things, to make progress on that small set.
Do the Harmony agreement templates meet the stated goals for Harmony? I believe they do, but I hope you’ll read them and decide for yourself.
What do they mean?
Some of the discussion has ranged around what various parts of the agreement templates mean, or what it means that various things aren’t in the templates. I’ll touch on a few key points.
- inbound=outbound: I won’t argue against the “inbound=outbound” strategy, because I think it’s a good one, and works well for many projects. But, I will argue that it’s not the only valid legal strategy within the realms software freedom. There are reasons to choose inbound=outbound, and reasons not to choose it. If an inbound=outbound strategy is right for your project, you should use it. And if you do, I encourage you to take a look at the Linux Kernel Developer Certificate of Origin (DCO) as an example. In the short-term, part of my 1.0 todo list is to create a page about inbound=outbound for the Harmony website, and I’d welcome contributions to it. In the slightly-longer-term, even though drafting a DCO-style template was more than we could manage for 1.0, there was definite interest in the Harmony drafting group. I’d personally be interested in collaborating on something like this. If you would find a general DCO-style template useful, or would like to work on drafting one, please say so.
- Copyright accumulation: There are various ways of talking about it, but one of the fundamental facts of FLOSS contribution is the process of assembling a collection of small bits of code from various sources into one big body of code. Some pieces are relatively independent of the whole, and could usefully stand alone. But for the most part, especially with maintenance work and refactoring over time, the contributions of any one person aren’t particularly useful separated from the whole. This is a beautiful thing about FLOSS, the whole is greater than a simple sum of parts. By copyright law, the default rule in place for all copyrightable work is “only the author has the right to distribute”, which means the project only has permission to distribute the contributors’ work because the contributors have granted that permission. Also by copyright law, the whole collection is itself a copyrightable work, owned by whoever assembled it (a “compilation”). These basic facts apply no matter what contribution policy a project chooses, no matter whether they’ve defined any policy at all. The contribution policy layers on top to more clearly define what kind of permission the contributors are granting the project and what they get in return. When you work on a project with no defined contribution policy, don’t make any assumptions about what the “implied” policy really is. Sometimes it’s inbound=outbound, but sometimes it’s a much older common FLOSS strategy of an original founder or foundation owning the compilation copyright. Fontana talks about how common inbound=outbound is, but in actual fact what’s common is not providing any clarity at all about the contribution policy, not even a simple web page stating “we assume you’ve given us permission to use your contributions”. That complete lack of information is a great disservice to contributors. The Linux Kernel DCO or the Mozilla Committer’s Agreement are good examples of how to be clear with contributors about an inbound=outbound contribution policy. Beyond inbound=outbound is every other possible way of granting permission for the project to distribute the code. Simon speaks against copyright assignment, and there are good reasons not to choose it. In Harmony, the only form of copyright assignment offered is one where the contributor gets back such a broad license to their contribution that there’s only a tiny sliver of a difference between that and ownership. If your project is going to adopt copyright assignment, and there are good reasons to choose it too, this is the best way to do it. Fontana talks instead about “maximalist” contributor agreements, where a project collects inbound permissions from contributors that are broader than the outbound permissions granted to users. There are good reasons for this too, in addition to the unhealthy reasons he mentions. Both talk about the inequality of rights held by the project versus the rights held by the contributors. But, that inequality lies in the fact that the project holds a collection of code, while the contributor holds a few pieces of that collection. All forms of collaborative development are copyright accumulation, there’s no way around it. The act of entering a group project is one of establishing a set of relationships with all the other contributors, which may include some form of legal entity. It’s all about building bonds, and trust, and confidence in this group you’ve adopted, and there’s no way around that either. I’m skeptical that the ultimately very thin differences between DCO/CLA/CAA contribution policies actually have much impact on the overall hurdles for joining a collaborative group or on the overall equality of the situation. Those fine differences will be important to some people, and I encourage people to adopt policies they’re comfortable with, and contribute to projects they’re comfortable with. But, I also ask you all to be charitable to others who have made different choices.
- Outbound copyleft license: Harmony offers 5 options for outbound licensing. Fontana points out that only two of these options are a restriction to “only copyleft”. True enough, but this doesn’t mean copyleft licenses are underrepresented. One of those two options (a specific list of licenses) is flexible enough to handle any possible combination of copyleft licenses that a particular project considers compatible with their philosophy. A few months ago, I was hoping for a rigorous legal definition of “copyleft”, that would capture just exactly the set of “true copyleft” licenses, and exclude all others. I even tried drafting some language, but any way of wording it failed to accommodate the fact that different projects have different definitions of what they consider “true copyleft”. Some are only GPL (or even only a specific version of GPL), some include AGPL, some LGPL, etc… The option for a specific list of licenses is a simple (I’d even say elegant) way to capture this diversity, giving each project a fine-grained knob to tweak on their “level” of copyleft. The other option (“FSF recommended copyleft licenses”) provides an updating list of copyleft licenses, which some projects may prefer for “future proofing”. Note from Mark Webbink’s post that a Harmony CAA with a strong copyleft outbound license option is actually a stronger guarantee to contributors than the FSF’s CAA, which only promises some copyleft or permissive license.
- Outbound permissive license: Of the 5 options, two are permissive. One is an updating set of OSI approved licenses (again, for “future proofing”) and the other is more generally permissive. Fontana talks about “the appearance of constraining outbound licensing”, as if the permissive options will sneak by unwary developers. This is something the drafting group took great pains to avoid, being very explicit about the types of licenses each option allows (e.g. “copyleft and permissive” for the OSI option). It’s also worth noting that the generally permissive option is also a bit copyleft, obligating the project to release a contribution under “the current license”. In the calls where we discussed it, this was considered by many drafters to be an important expression of developer’s rights, and a step ahead of existing permissive strategies. (I’m glad it made it in.)
- Outbound current license: The fifth option for outbound license is “the current license or licenses”. I suspect this may be a less popular option, because one of the big advantages of a CLA/CAA is flexibility for future changes. If your project plans to release always and only under one license, or is willing and able to invest the effort to get a separate signoff from contributors for a license change, you may find that inbound=outbound is actually closer to your needs.
- Incorporated feedback: Brad commented that the “1.0 documents differ little from the drafts that were released in April 2011” in support of the idea that they’re “primarily documents drafted in secrecy”. I asked about this and it turns out he ran a diff from Beta to 1.0, and so missed all the changes from Alpha to Beta, which is when we got the most feedback. Here’s a diff from Alpha to 1.0, showing that the changes in response to the public review periods were quite extensive, with only 21 lines of text (less than 10% of the total) remaining unchanged from Alpha to 1.0.
What happens now?
I expect that over the next year a handful of projects will adopt Harmony agreements. That may not sound like much, but I consider my time on Harmony well-spent when I count the collective human-years that will be saved from drafting and redrafting contributor agreements. That time can be much better spent on community building, documentation, coding and everything else that makes FLOSS projects great. Some posters expressed concern that the mere existence of Harmony might divert some projects from one philosophy or legal strategy to another. I just don’t see that happening. The community of FLOSS developers are some of the most legally aware and opinionated non-lawyers on the planet. Harmony will be useful to those projects who would have adopted a CLA/CAA anyway, or for projects who already have one and are looking for an update.
Dave Neary commented in closing “the goal should not be to write a better CLA, it should be to figure out whether we can avoid one altogether, and figure out how to create and thrive in a vibrant developer community.” I completely agree. I’m pleased to see the various efforts for copyright reform, as I think one of the fundamental problems within FLOSS is that we’re trying to build a system of open distribution on top of copyright law, a system that was inherently designed to be closed. I’m in favor of copyright reform, but realize that the law changes slowly and only with enormous effort. On the whole, that slow pace is probably a good thing for the stability of society, but it means there are a few areas where society has changed quickly and radically, leaving the law trundling along to catch up. I also recognize that there’s economic/political pressure to make copyright more closed rather than more open, and it’s not clear who will win.
There’s another idea floating around that I know has been an inspiration for some people involved in Harmony. Right now, FLOSS contribution is all about taking your piece of code and granting permission to one project to distribute it. What if, instead of making individual agreements with individual projects, developers could contribute their code into a kind of “FLOSS commons”, together with annotations on how the code may be distributed. Instead of figuring out each new project’s contribution policy, a developer can just check whether the tags requested by the project are compatible with the tags they’ve chosen. And instead of endless discussions on whether license A is compatible with license B, so library X or algorithm Y can be included in code Z, projects could just check if the code was tagged for their intended use. I don’t know if the idea will ever fly, but if it does, something like Harmony (or future versions of Harmony) could be one of the ways that code flows into a system like that, where Harmony’s “options” turn into tags a developer puts on their own code to identify the forms of distribution they want to allow. Interesting potential there.
Allison Randal 
Considering the nature of the Harmony agreements, a handful of projects adopting it is actually quite a lot. That is unless you count really niche projects with only one or two contributors, or on the other end perhaps Canonical’s projects since Canonical did play a part in the creation of the Harmony documents, possibly purely to smooth out problems they’re having with the adoption of their copyright assignment policies.
What nature of the Harmony agreements?
evil?
😉
Just joking, although I would hope the number of projects having ANY kind of CLA/CAA stays as small as possible.
I don’t like the majority of options Harmony offers and as I wrote in a column before, I would vocally oppose Harmony if those arguably ‘evil’ options are not clearly classified as such. They are not*, so sorry, I oppose anything ‘Harmony’.
For foundations/charitable entities CLA/CAA/etc, Harmony could be useful. But then, why not take the one by the FSFE which was also adopted by KDE? You don’t need much choices there, I’d recon.
* Yes, I’d like those options to have on top of them in big black letters something like “WARNING: this licence erodes the rights of you as developer(s) and/or your potential user(s) by allowing the entity you assign your copyright to to release proprietary versions of your code while disallowing you and/or your users to do so. This in-equality means you essentially work for free for this entity. Do not sign if you do not like this.”
Or something like that.
Which options are “evil”? I’m not clear here if you’re speaking against copyright assignment or against permissive licensing.
What I’ve found so far is that different people in the FLOSS community are comfortable or uncomfortable with different options, in much the same way they are comfortable or uncomfortable with different FLOSS licenses. It’s almost a “Meyer’s-Briggs” of FLOSS contribution strategies. “What personality are you?” “Oh, I’m a CLA-OSI.” “How about you?” “I’m DCO-SAME, definitely.” (A DCO-style option is the major gap right now, just from lack of time.)
Harmony covers the current practices of a broad spectrum of the FLOSS community. Don’t shoot the messenger, Harmony didn’t invent these FLOSS legal strategies, we just analyzed and presented them as a clear list. Curiously, it seems that the simple act of presenting the existing alternatives more clearly, is actually elevating the discussion around contribution policies into the same range as the very long-standing discussions about FLOSS licenses. I see that as a good thing, should have happened years ago.
I consider the option(s) where the party who receives the code ownership can take it proprietary while the contributor can not to be evil. With a non-copyleft (BSD) licensed project, anyone can take the code closed at any time – at least everyone is on equal grounds. With copyright assignment where only one party has that power you get a very un-favorable position for the contributor and I think he/she should be VERY clearly warned of this.
I’d be much nicer towards Harmony if no such options were included as that would prevent the ‘inflation’ of the term, like what happens with ‘CC licensed’*.
* As I’m sure you are aware some ‘CC’ licenses are actually incredibly restrictive which has made the term ‘Creative Commons licensed’ rather meaningless.
Well, let’s face it if it wasn’t for Canonical’s agenda with Copyright Assignment they probably would have had less incentive to kickstart the Harmony project. Most other free software projects either already have an agreement that they use that are relatively simple to understand or they aren’t interested in CA.
I’m sure you’ve done much more research on it than I have and maybe 5 projects might even adopt it. I guess we’ll see…
Canonical doesn’t have an agenda for copyright assignment. That’s one of the speculations about motivation I mentioned in the post, and I know for a fact that it’s inaccurate.
But, agreed that looking back, say, a year from now, we’ll have a much clearer picture of Harmony’s true effect and true potential.
Hmm, seems like I can only reply up to 2 thread levels (this in response to https://allisonrandal.com/2011/07/16/harmony-1-0-reflections/?replytocom=111#comment-114).
I really like that Myers-Briggs of FLOSS licenses idea. Might not be ideal for choosing a license since licensing is usually more about what’s practical for each use case rather than ideals (ideally all software that exists would be BSD licensed, right?), but at least it would make it easy to look at someone’s 4 letter code and have an idea of where they’re coming from.
Oh, looks like WordPress had a default limit of 3 levels of comment embedding. Odd. I’ve upped it to the max now.
Hmmm… I wonder if we could get the FLOSS Meyers-Briggs down to 4 major “letters”? One is definitely C/P for copyleft/permissive, but like Meyers-Briggs would need finer gradations between the two poles.
Heh, I have a tomboy note where I started writing ideas and the first one I added was also “Permissive / Restrictive”.
Another one that I thought of (but might be phrased a bit better) is the split between the Activist type, who wants to do things like change the world, do things, make big changes, build a big business, make an entirely free OS and then there’s more of the Hobyiest/Tinkering type who works with free software purely because they enjoy the technical challenges and doesn’t necessarilly care about things like licensing specifics either. It’s surely possible to be both of those types, but most people lean towards the one side or the other and I think it might be a useful thing to include in such a profile. Maybe the letter to describe that could be “Active/Passive” but sometimes it’s hard to choose descriptions where people wouldn’t imply too much about the single word.
Can’t think of other combinations right now but I’ll definitely be observing my co-workers and free software people I work with. There are sure to be more differences between them that are interesting that could be fun to profile, I’ll keep you updated if I can think of more letters!
Ah, yeah, P/R could work. It actually reminds me a lot of the P/J distinction in Meyers-Briggs.
Active/Passive is a good vector, reminds me of the Meyers-Briggs Extrovert/Introvert. Yes, have to be careful about “overtones” of the word choices (I’ve always thought “Judgment” was an unfortunate choice, it sounds kind of negative). And, besides, P is already taken for “Permissive”. Maybe Activist/Individualist? Most of Meyers-Briggs is a scale, so it’s not that you’re only Introverted or only Extroverted, but that you’re somewhere between totally one or totally the other.
Thank you for the detailed explanation. Said much better than I could have.
451 CAOS Theory » 451 CAOS Links 2011.07.20
jospoortvliet, so the problem from your perspective is not copyright assignment or permissive licensing, but the combination of copyright assignment with a permissive philosophy.
If I put on my “Extreme Permissive” hat for a moment, it’s totally fine that the project can make proprietary versions, and if the project uses a permissive license, then anyone else can too. The “little bit copyleft” of the generally permissive outbound license option is relevant here. If a project accepts assignments to a FLOSS licensed project, and then releases a proprietary version, they’re required to release the contributions under the same FLOSS license. So, if the project uses a permissive license, they can never take an assigned contribution and make it proprietary without also releasing it under terms that allow anyone else to make their own proprietary version.
Now, to put on my “Extreme Copyleft” hat for a moment, if the project uses a strong copyleft license and takes an assignment with the generally permissive outbound license option, there is potential for the project to release a proprietary version, where no one else can. But, the project would still be required to release the contributions under the copyleft license, so anyone can fork the project under that copyleft license. Allowing everyone to make proprietary versions would completely undermine the force of the copyleft outbound license, so really isn’t desirable from a strong copyleft perspective. What may be desirable (likely so for strong copylefts) is also restricting the project from releasing under a permissive or proprietary license, so in those communities it may make more sense to choose one of the other outbound license options: “same license”, “list of (copyleft) licenses”, or “FSF recommended copyleft license”. (It seems fairly common-sense that a strong copyleft philosophy is not a close match for a generally permissive strategy.)
Between the two poles are a range of philosophies with varying levels of permissiveness or copyleftness, and various combinations of Harmony options. What’s important is to be very clear with the contributor about the project’s philosophy, so the contributor can decide if they’re comfortable with it. The generally permissive option does that with: “We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses.” It would have been simpler to just say “any license”, but we wanted to be very clear about exactly what permissive outbound licenses actually allow.
2 things 😀
First, you’re confusing me a bit with ‘project’. Project, to me, is anyone working on something together, each contributor. Individual, corporate, whatever.
You seem to say with ‘project’ the entity which owns the code, be it a company or a foundation etc, correct? I only really have a problem with CAA/CLA if that entity is a company so I’ll use that term, just for clarity.
Second, yes, it seems you get the point.
FWIW to me the Extreme Permissive case is no issue. Every contributor to the project (including the company which gets the copyright of the code) is on the same level: everyone can, at any time, make a proprietary version. No advantage of having a CLA/CAA either, at least I have not seen any convincing argument to that end, but whatever. No harm done.
Then the Extreme Copyleft case where one contributor (the company which owns the copyright) can make a proprietary version but otherwise releases (has to release) the code under a copyleft license. Here we get into the Oracle/Canonical/etc situation which I want to be very clearly identified as such, or much rather, not be in any way associated with Harmony if I’m ever to talk positively about it. This situation is in my opinion evil, wrong, and should not exist. And companies using them should be clearly flagged as such by the community (and preferably be ignored until they change their ways or just leave). Yes, I feel strongly about that. Oracle has shown how dangerous such situations are and I would strongly advice anyone to never contribute to such a project. This brings me to the saying rom the GNU website: “when I work on proprietary software, I expect to get paid”. Whether the company in question DOES make/sell a proprietary version doesn’t matter – a future buyer of the company could.
IANAL so next up is a question, not a statement. I dunno if this is true but if it is this is my biggest problem with Harmony.
Say you have as license option one which is mostly copyleft but contains one BSD style license. Is it possible for the company to only ever release the code publicly under a strong copyleft (GPL) license but give a copy of the code to a customer under the BSD (allowing that customer, and ONLY that customer, to make a proprietary version)? If that is the case, such a scheme introduces the unfairness I’m worried about – the other contributors to the project won’t have the same rights as that one company (they can NOT make a proprietary version, the company which owns the copyright can). And if this is the case, isn’t it true that most of the Harmony options actually allow this evil scheme – while not making this clear AT ALL to the contributor?
I feel that pretty much ALL harmony options except for the extreme permissive one allow for the scheme resulting in contributors working, unpaid, on code for a company which then can sell it off under a proprietary license (while only having a copyleft version in public). I don’t know if I’m correct in this thinking but if it’s true I’ll continue to oppose harmony and speak bad of it and anyone involved. Sorry. If it’s untrue and harmony makes this clear (but still possible) I’ll be far moderate in my criticism and would even be quite positive if that option would be very clearly flagged as such, distinguishing it from the other, ‘safe/non-evil/fair’ options.
I use the generic “project” intentionally, because the Harmony agreements can be used by individuals, groups of individuals with no entity, foundations, companies, etc…
It sounds like you consider the Harmony agreements (of all varieties) to be totally fine when used by individuals or foundations. I’m glad. But, it also sounds like there are some varieties you think companies shouldn’t use. That’s totally fine, you are entitled to an opinion on what contribution policies are best suited to companies. But it isn’t a flaw in Harmony. General purpose templates are not the right place to mandate individual views on project policy. If you want to advocate the adoption of particular policies for FLOSS projects that were started by companies, or projects that interact closely with corporate partners, please do. But don’t spread FUD that the policies you don’t like are caused by Harmony, or even encouraged by Harmony. That’s simply not true.
Personally, I think there’s a lot more room for companies to beneficially participate in FLOSS projects than the narrow set of options you seem to be advocating. It’s something the FLOSS world is still figuring out, in much the same way that it has done over the past decade+ for foundations.
Oh, I’m sure there are many more ways of companies to benefit if they use those less (or I should even say non) equal options. But then they should just keep their code proprietary and not try to confuse people.
Yes, I believe that if Harmony presents these options as reasonable choices, it is seen as encouragement. So if Harmony wants to do something good for FLOSS, it shouldn’t do that in any way. If Harmony is just an effort to push something which is arguably evil and contrary to the spirit of Free Software, well, it seems to be doing just fine. Luckily a lot of people are smart enough to recognize it and anyone involved in Harmony is being properly (and deservedly) badmouthed right now.
Look, I get what you/Harmony try to do. Create clarity. And not judge in any way. But the world doesn’t work that way. Harmony would just act as a validation/justification of policies which go very much against the nature of FLOSS. And that’s bad, evil, whatever. And your (an many other contributor’s) intentions might be all good, but then they (and you) are letting themselves be used for an evil purpose and you’re going all ‘lalalala it’s not true there’s nothing wrong’ when people tell you.
I would appreciate it if you answered my question – I really don’t know but for now I’m going to assume ‘the worst’ which means anytime Harmony comes up I’ll present it a wrong and evil as well as I can.
You know that I meant “companies contributing to FLOSS in a way that benefits the projects”, not “in a way that benefits only the company”. 🙂
I thought I answered your question, what did I miss?
Ok, I didn’t mean to mis-understand. But frankly I don’t see how it benefits a project if it’s held hostage by a single company – we’ve seen plenty of examples of why that is wrong. Luckily we can fork them (provided they have a reasonable license like the GPL or so) but it usually does quite some damage before that finally happens.
Anyway, the question I had was (fixed it a bit):
====
Say you have as license option “any license OK’ed by the FSF”. This includes GPL and BSD style licenses. Is it possible for the company* to only ever release the code publicly under a strong copyleft (GPL) license but give a copy of the code to a customer under the BSD (allowing that customer, and ONLY that customer, to make a proprietary version)? If that is the case, such a scheme introduces the unfairness I’m worried about – the other contributors to the project won’t have the same rights as that one company (they can NOT make a proprietary version, the company which owns the copyright can). And if this is the case, isn’t it true that most of the Harmony options actually allow this evil scheme – while not making this clear AT ALL to the contributor?
I feel that pretty much ALL harmony options except for the extreme permissive one allow for the scheme resulting in contributors working, unpaid, on code for a company which then can sell it off under a proprietary license (while only having a copyleft version in public). I don’t know if I’m correct in this thinking but if it’s true I’ll continue to oppose harmony and speak bad of it and anyone involved. Sorry. If it’s untrue and harmony makes this clear (but still possible) I’ll be far moderate in my criticism and would even be quite positive if that option would be very clearly flagged as such, distinguishing it from the other, ‘safe/non-evil/fair’ options.
=======
Now again I realize you don’t want to police anyone but by not flagging such licenses clearly developers (who usually don’t care much about legalize) can sign something which goes much further than they think. Harmony would act as a disguise over clearly wrong (from a copyleft/Free Software perspective) CLA’s. I mean, I’ve been reading into this and I still have to ask questions like the one above. The average developer won’t know what he’s signing, the way it is now… And again, I’m sure you see that point… And wonder why you are so positive about the whole effort.
Frankly, it’s awesome if our ecosystem would benefit from Harmony, but ONLY if it doesn’t erode the thing we fought for all this time – freedom.
*you were correct in assuming I only care about for-profit entities and their intentions. Usually the GPL makes it impossible for them to screw their users forcing them to write FOSS in an level playingfield. Copyright assignment screws up that protection, hence I oppose any copyright assignment to a company unless it doesn’t allow them to do ‘bad stuff’ like the things I described.
With perpetual and exclusive right granted, this should mean that a contribution can not be submitted e.g. to both the Xfce and LXDE projects? Or am I not getting the finer legal points here?
With either license or assignment versions it is possible to contribute the same code to more than one project. With the license version, the contributor still owns the copyright, and so has the right to license it to anyone else. With the assignment version, the contributor gets a broad license back from the project that grants them the right to license it to anyone else.
That’s what I don’t understand; if I grant you a perpetual and exclusive right and can later grant a perpetual and exclusive right to someone else for the same code then the exclusiveness is not really there is it?
Two entities can’t hold an exclusive right to something at the same time in my simple world. I suspect that must be one of the finer points I don’t get.
The rights granted are perpetual, but not exclusive.
So…
What precisely do you think are the advantages of using a CAA/CLA for a typical Free Software project? I can’t seem to find that explained anywhere…
See http://harmonyagreements.org/overview.html for a list of considerations. A quick list (and some of these apply to DCO strategy as well).
1. Being clear with the contributor about what their relationship is with the project, both what rights they’re granting when they make a contribution, what their responsibilities are, and what the project’s responsibilities are to them in return.
2. A sensible check-point to make sure the contributor really does have permission to contribute to the project.
3. Reassuring the users that the project really does have permission to distribute the contributed code.
4. Some tools to help projects, in their responsibility as stewards of the body of code, with things like: enforcement of the project’s license, releasing project documentation or media under a non-code license like GFDL or CC, the natural lifecycle of outbound licenses (updates to existing licenses, deprecations of old licenses, new licenses that more closely match the project’s philosophy), the death or bankruptcy of a contributor, or legal action against the project or contributors. These things can be handled without a CLA/CAA, but having the signed agreement in place ahead of time can make them easier.
openSUSE Weekly News 187 is out! | The Linux Crowd