Proprietary licenses?

[rossjones]

It also includes the right to license the Contributions to
others without any restriction on the nature of the sub-licence, including
without limitation: (a) open source licenses like the MIT license; and (b)
binary, proprietary, or commercial licenses. 

When asking people to contribute to an Open Source project, I don't believe allowing the software's use under a proprietary license if the developer wants contributions licensed openly.

[wardi]

I agree.

CKAN's AGPL license requires sharing all ckan modifications (and extensions IIUC) used for a public ckan instance. Many developers are already reluctant to work with those restrictions, to also say "we want to be able to sell your contributions and keep things built on them secret" would be poisonous for new contributors and the project as a whole.

[amercader]

+1 On 15 Apr 2014 13:00, "Ian Ward" notifications@github.com wrote:

I agree.

CKAN's AGPL license requires sharing all ckan modifications (and extensions IIUC) used for a public ckan instance. Many developers are already reluctant to work with those restrictions, to also say "we want to be able to sell your contributions and keep things built on them secret" would be poisonous for new contributors and the project as a whole.

— Reply to this email directly or view it on GitHubhttps://github.com/ckan/cla/issues/4#issuecomment-40473306 .

[rufuspollock]

OK, my understanding here is as follows:

• There is an absolute commitment for CKAN codebase to remain open-source forever
• At same time what happens if there is an opportunity (whilst keeping code open) to license code to some third-party and they don't want to make code open source (let me emphasize this is license not sell the code) and are willing to pay for that. To put it most starkly: imagine someone wants to use CKAN in house at their corporation and is willing to pay us a $5m for a license with no open-source requirements. This $5m can be used to fund CKAN's open-source development to make it better and more awesome for all concerned. Wouldn't we want to at least be able to consider doing that? (I should also emphasize that any decision to do this would be taken by the CKAN Association - and that is overseen by Open Knowledge Foundation who have written into their articles of association a commitment to Open Knowledge).

Bottom line: this is all about promoting CKAN and open knowledge - but there could be situations where being able to license to someone under a non-open license would be a way of pushing open-source CKAN forward.

[rossjones]

Why would someone need the license to be proprietary for a company to use it? If this is about them being able to make modifications without releasing those modifications it seems GPL2 would have been more useful ;)

This $5m can be used to fund CKAN's open-source development to make it better and more awesome for all concerned

Is there a commitment that any money made taking this approach is absolutely guaranteed to be spent only on CKAN under the direction of the CKAN Assoc? Presumably it will be OK selling the private version of CKAN? I don't mean to question motivations, I'm just after clarity.

[rufuspollock]

@rossjones re the license there are 2 reasons I think. The first as you point out is that the CKAN license is the AGPL which would be onerous for some people (if it were e.g. the MIT many companies could just use the code and not be concerned about any requirements it imposes on them). There is still a second reason which is that people may still want a license (even if base was MIT) as that license may provide for things e.g. a warranty or similar.

One second point:

Is there a commitment that any money made taking this approach is absolutely guaranteed to be spent only on CKAN under the direction of the CKAN Assoc? Presumably it will be OK selling the private version of CKAN? I don't mean to question motivations, I'm just after clarity.

Yes, my understanding here would be that any money the CKAN Association decided to accept would be spent only on CKAN under the direction of the CKAN Assoc (though I note that "CKAN" may be broadly interpreted her to include e.g. running events plus, in terms of software, might be software beyond the main CKAN repo e.g. specific extensions or Recline (as determined by CKAN Association ...)).

Not sure what you mean by "it will be OK selling the private version of CKAN" :-)

[rossjones]

I think I mean that it won't be CKAN Assoc selling CKAN with a proprietary license, but rather OK Services Team, so the path from OK selling something privately to the money going to CKAN Assoc wasn't/isn't clear. It also isn't clear to me how any other Open Source developer could do the same thing, if I were to try and sell CKAN with a restrictive license, I couldn't do so.

[rufuspollock]

@rossjones ok, I think the key thing to emphasize here is that CKAN Association and Open Knowledge are committed to keeping CKAN open forever (it is written into OK articles of association). I understand a fear here could be that there's some nefarious plan to "go to the dark side" (accompanied by suitably ominous laughter and the words "mine, all mine" :-) ...)

[rossjones]

I totally understand that OK are irrevocably public minded, this is a good thing.

I also believe that as OSS everybody should have the right to use the software in the same way, and currently this isn't the case. OKServices can use the software in a way that others can't.

[rufuspollock]

Ah, ok I understand now.

My understanding is that all would be operating on an equal footing here going forward.

[nickstenning]

I don't think it's logically possible to actually use this clause (i.e. relicensing under a commercial license) in a project which is released under the AGPL.

[nickstenning]

Actually that's not true, sorry. Shooting from the hip. If a contributor signs this CLA, then of course the licence OKF has to their contributions is unrestricted, and isn't bound by the terms of the AGPL.

I would suggest there is a "scariness" cost associated with having this clause in the CLA, though, and thus my preference would be for an agreement that does no assignment of copyright, no granting of unrestricted licences, and which simply asserts that the contributor owns the IP they're contributing, and is happy for it to be released under the terms of the project licence. q.v. #2.

[nickstenning]

If the problem here is that AGPL is overly restrictive, then that should be resolved by relicensing CKAN, not through an unrestricted licence granted solely to OKF through a CLA.

[wardi]

@nickstenning +1

Companies can already use CKAN internally. The AGPL only requires that the changes be available under the same terms to those using the web site, not that you need to make your website public.

[wardi]

I can see two possible outcomes from this sort of CLA. Neither is appealing:

1. A company wants to set up a software-as-a-service site based on CKAN and so they purchase a license that allows them to do so without sharing their changes and extensions. This company now has more rights to use my contributions than I do.

   New contributors will see that their work is now directly supporting the bottom-line of a company interested in closing off their source. This service might even be successful and employ more and more developers to work on proprietary extensions, eventually eclipsing the original project.

2. A large established commercial open data company may purchase a license that allows them to sell CKAN as a lesser offering to their commercial product. It would be branded as "starter" catalog and customized in ways that makes it easy to funnel clients into their commercial offering. MySQL and Oracle come to mind.

[rufuspollock]

@wardi re point 1 I think the logic is: but that company has contributed a bunch of money to make CKAN better for everyone including you. If the ultimate goal is the most awesome and widely used open-source project that we can make then you want to at least consider that option. I mean to put it ludicrously: suppose someone offered us (us all) $1bn for a license to use CKAN in proprietary code we would want to take it and use that money to make CKAN absolutely amazing.

1. Again the question would be, taking account what that other company may do, what will deliver maximum value to the CKAN open-source community. Also re MySQL case the actual base software has been sold across which would never be possible with CKAN (given legal and actual nature of Open Knowledge Foundation).

[wardi]

@rgrp We agree that money going to CKAN development is awesome. We differ in judging the risks of adopting terms that allow proprietary forks for some.

After adoption I see time spent chasing after current contributors to sign, time removing code from those that won't, time bargaining with new contributors reluctant to sign, time minimizing negative press/commentary and time lawyering about sharing code between such forks.

Maybe there are examples of projects that have thrived after adopting this sort of CLA. Did jquery start without its license assignment agreement? I'm more familiar with projects that went the other way.

[jpmckinney]

@rgrp Can you point to the specific phrases from the articles of association (linked from OKF's governance page) that guarantee that CKAN will be open forever?

Unless there are in fact companies willing to pay huge sums for commercial licenses, I don't think we ought to wring our hands over the possibility. There are an infinite number of extremely unlikely but supremely awesome possibilities in the universe; but it is not reasonable to prepare for all of them.

Anyway, I think what would resolve most issues is if the CKAN Association were constituted as an independent legal entity, like the Drupal Association and other software projects are. Right now, there are no legal protections against OKF abolishing the CKAN Association. I don't think it will happen, but since a legal discussion has been started, we may as well adopt a sensible legal structure, before attending to contributor license agreements.

[hlainchb]

"imagine someone wants to use CKAN in house at their corporation and is willing to pay us a $5m for a license with no open-source requirements"

Can't this be accomplished with a license like MIT or BSD? Why the need to mention "proprietary, or commercial licenses" in the CLA?

Is it that someone might want to incorporate the code into their proprietary software product and redistribute it without retain the accompanying copyright notices? (which is, I think, the only substantial requirement imposed)

[davidread]

Under AGPL, to distribute it, or even just run it as a public service they would have to open source the entire product (i.e. including their proprietary bits).

[nigelbabu]

I believe this CLA was adopted from the jQuery foundation, where jQuery is indeed part of certain proprietary applications and this is actually a legal worry. In our case, this doesn't even apply. I strongly wish for us to either remove this clause or guarantee the re-licensing will be under an open license.

[rossjones]

How much work would it be to try and re-license CKAN under a non-AGPL license? I'm assuming AGPL was chosen for a specific reason, and working around it in CLAs seems like the wrong approach. I'm +1 for removing the clause, and +0 for re-licensing CKAN.

[rufuspollock]

As noted this came from jQuery CLA. Based on discussion over last year and discussion with Steering Group and others I suggest we resolve this by removing these clauses:

It also includes the right to license the Contributions to
others without any restriction on the nature of the sub-licence, including
without limitation: (a) open source licenses like the MIT license; and (b)
binary, proprietary, or commercial licenses. 

And replacing with e.g. following:

It also includes the right to license the Contributions to
others under the existing open-source license for the code which is the AGPL
(GNU Affero General Public License v3 or any later version).

Suggestions and comments welcome.

[rossjones]

I've submitted a PR for the suggested change - https://github.com/ckan/cla/pull/8

There are obviously other outstanding issues that aren't yet closed, we should look to address those as well where they're not finished.

[rufuspollock]

@rossjones great though I think we want to distinguish ckan association from this item (PR #8 has both).