License?

I'm not an expert on Open Source licenses. What do we choose to accomplish this? (From http://www.librarything.com/wiki/index.php/LibraryThing_JSON_Books_API)

*We are looking for a license that requires that all software built to process the JSON Books API be open source, so members can build on each other's work. The LT software that produces the API is not be open-sourced, but all the JS we're writing to process it is.
*Anyone using the API on a web page relinquishes the right to keep that page private. We reserve the right to check out your code and bring it back for other users to use—a basic part of open-source development.
*The license should not impact the data one way or another.
*Every widget must include at least one link to LibraryThing, waived at request.

Open source licenses are mainly distribution licenses. Even if I used GPL software in writing something there is no need to open-source what I write as long as I do not distribute it and use it purely on a personal basis. There has been confusion when using GPL/LGPL based licenses on what constitutes distribution for web-based stuff. Many are clamouring for clarification.

Anyone using the API on a web page relinquishes the right to keep that page private

I'm not sure what that means. Does that mean everyone who uses it must inform LT? Cannot password protect it? Cannot use it on an intranet?

The attribution clause (although not covered precisely by current licenses) shouldn't prove a problem. It will (most likely) require a custom license if you want to make it a condition rather than rely on community values.

Because of the web based nature of the entire API I would say that a custom license is going to be necessary. Here is a link to an O'Reilly Radar discussion about this issue.

You aren't releasing source, so it's not really an open source license that you are looking for.

You are releasing an interface description, or specification, which is another beast entirely. #2 is right, you are probably going to need a custom license based on what you describe above. Which means you probably need to call up your lawyer as well.

It would probably be a good idea to list out the use cases (i.e., the classes of situations where people would make use of the API) and what you think are the requirements for each. As in, "Individual user displays their catalog data on their blog." "Library displays aggregated ratings information in their catalog."

Also, the fact that CK uses a Creative Commons license limits what you can prevent people from doing with that data even if it comes through the API. You can't add a "can't display the data privately" restriction to the CC license. The rights granted by CC are irrevocable.

IANAL, but I somewhat doubt "You agree to abide by whatever license we eventually chose." would make one happy.

Your position is not as weak as licensing a specification per #3. You are licensing a service.

In addition to what #2 said about distribution in the context of GPL, I should point out that there are plenty of good open-source licenses with no distribution restrictions. They indemnify the original source, or maybe require attribution. I always go with the MIT license, for reasons of personal history with this whole mess. But really it does not have much to do with your situation.

Perhaps the best thing to do is allow revocation of access to the service for any reason, even caprice. Then list causes that you can think of now that might serve as reasons. One point is that, should something go wrong, you aren't going to sue, are you? You're going to turn off the account.

Copied from the blog (not by me, by "anonymous"):

First reactions:
- you really should separate this into two requests - one for the standard libray (which takes limited parameters - perhaps just a version number), and then a quite separate request which produces the JSON data. (Think of applications that make multiple requests on the same page - currently they will have clashing copies of the code you try and serve with each set of data).
- study how other APIs do namespacing - basically have one global object which contains all your functions, so calls take the form LibraryThing.coverImage(), rather than having the prefix LT_API_
- actually the API isn't very useful, since it simply tells the user about the books some particular user has, given their (laregly secret) ID. Where are the useful API calls such as given an ISBN tell me about the book; find all books matching certain criteria; find the id's of users who have a certain book etc. The real innovation in using APIs comes when the connections between the data can be explored - and this API does not allow any of that to be used

Whilst I see what you are trying to do with the licence, it goes further than any licence I have come across, and will I think make many programmers stay well away from the API. When you licence data, it's most unusual (and probably unworkable) to impose licencing restrictions on the code that accesses that data.

What I think you should look at is:
- the LibraryThing library can be open source
- the data can be licenced how you see fit (for example "no commercial use")
- code that processes the data is unfettered - thats the way to get real innovation in the way people use the data. Many will choose to share their techniques, but forcing it will simply make them avoid it.

Responses to above:

you really should separate this into two requests - one for the standard libray (which takes limited parameters - perhaps just a version number), and then a quite separate request which produces the JSON data. (Think of applications that make multiple requests on the same page - currently they will have clashing copies of the code you try and serve with each set of data).

This is all fair, but note that there's a parameter to avoid including the library at all, so you can do what you want to do.

Having it included by default has two purposes--first to make it a single, simple call, and second to underscore that the data is intended for use in a browser.

I need to explain the latter a bit. Basically, it is not at all clear whether or not the Amazon terms--under which LibraryThing gets much of its data--allows LibraryThing to distribute Amazon-derived data via an API. We are pretty sure that a full-fledged API to all our data would be a sort of API to their API, and not allowed.

At the same time, many services have offered export functionality, RSS feeds and widgets. We feel we're on safe ground there, legally and with regard to what Amazon will actually do.

study how other APIs do namespacing - basically have one global object which contains all your functions, so calls take the form LibraryThing.coverImage() rather than having the prefix LT_API_

Yes, that's how we do LibraryThing for Libraries, and it makes sense. I consider LT_API_ simpler for novice programmers to understand--using unusually named functions rather than bending JS's OO capabilities like this. I know many don't see it this way--I'm the most anti-OO person at LT. I think you're right this is a small concession, but my overall thrust is to go for simpler, easily-undersood solutions that more people will understood. I am very conscious, for example, of the generally level of JS knowledge in most library catalog/web departments.

actually the API isn't very useful, since it simply tells the user about the books some particular user has, given their (laregly secret) ID. Where are the useful API calls such as given an ISBN tell me about the book; find all books matching certain criteria; find the id's of users who have a certain book etc. The real innovation in using APIs comes when the connections between the data can be explored - and this API does not allow any of that to be used

You're right. That's the problem described above, however. I can't make a general API to LibraryThing data--one that could be used by a derivative service. It would be an API to Amazon's API.

I can expose non-Amazon data more generously. Certainly each book can retrieve work-level for itself. I'm open to ideas on how to bridge that gap.

code that processes the data is unfettered - thats the way to get real innovation in the way people use the data. Many will choose to share their techniques, but forcing it will simply make them avoid it.

Yes, you're right. We need a "revoke at any time" for the data, however. I'd also like something that says that, if public, it's public. That is, I don't want users getting mad at me if I say that this blog is doing something interesting, and pointing to it.

I went ahead and namespaced the whole thing. I put it under LibraryThing.bookAPI. That way it won't conflict with our LibraryThing for Libraries namespace. I can change the work API we already made and put it under LibraryThing.workAPI too.

I did the change without versioning. The API is less than 12 hours old, so there can't be much code written off it. It doesn't appear to break MMcM's cover-flip thing, which is the only use I've seen so far.

Tim

Have you evaluated the GNU Affero Public License v3? Its target is web services: http://www.gnu.org/licenses/agpl-3.0.html

That would be a license for the LibraryThing *code* separate from your licenses on the data. And it's an already written license, so you would help limit the explosion in licenses.

Affero is designed to close the ASP loophole in GPL code running on a server but not otherwise publicly released. (Take the code from a GPL site; make your own site; sell the service, but keep the code.)
That is not what we have here: LT core is closed source.

I think all we need is a standard viral open-source license for all JS developed around this. So, what do we choose? I'm sure others know the answer here. I do not.

Could the GNU Affero license be applied only to the JS library? If necessary, the LibraryThing copyright holders could apply an exception to allow using/"linking" with the LibraryThing services, much as many GNU GPL packages contain an exception to allow using/linking with OpenSSL.

But seriously, if it's just the JS library, and the library only provides access to a user's individual library, why the fuss? Is it really useful for other services? If not, the necessary developer key should be sufficient to protect LT's servers from abuse. Then just slapping any simple license (e.g. modified BSD or MIT) would be the path of least fuss.

I have history from the early days, so I will just ask once and not initiate a protracted debate.

But, can we please avoid contaminating licenses on our script code?

Yes, I agree. What's the standard "strong" (viral) copyleft license for software?

Basically, I want it so that we can all use MMcM's code—and incorporate it into the standard library—without asking. I'd like it even if you wrote the code totally separate from the code we're using.

So you want to ensure you can use other people's work without either a) asking or b) their already choosing to share it? That smells bad. Why not just ask people to license their code similarly to yours? This is a fairly friendly community built around sharing already.

Do you honestly expect people to create "widgets" that will destroy your business if they aren't shared? Especially since the widgets only look into a single person's library...

But the "standard" copyleft is the GNU General Public License. That will apply to any "derived work", although the definition of "derived work" varies.

No, I'm just looking for a way that, if MMcM posts his thing, we don't need to ask and then receive permission to copy any of his code. If you're working on this problem, your code is everyone's. I don't really see this as some sort of "protection," but as a way past formalities.

#15

I think you are wrong about the GPL. It will not apply for several reasons
a) the user will not be distributing the code - it will be either personal use or they will be utilising it as a service (this latter problem is the one that the Affero license tries to solve)
b) the user isn't necessarily taking any code from LT and changing it. They are just using a public interface specification. This isn't enough to be considered a derived work IMO.

What is really needed is a new type of license for using an open interface (whether this is JSON or SOAP or what have you).

Personally I would go for a plain English no-nonsense license as I think that people will play fair on the whole. Basically tidy up the words that already exist with a few more details about key use (is using someone else's key a problem - because some people will); and a clause about revocation of keys.

If it's JavaScript and it's on a public page, then the user *is* distributing their code. If it's completely inaccessible to others, then how would anyone at LibraryThing even know there's something worth copying? Tempest in a teapot.

Only thing that realistically can be regulated there is the number of queries. In the non-public setting, LT would need to communicate with the author anyways. The only middle ground is a server-side app, but then the server likely would run into key usage restrictions anyways.

Since LT has international users, LT may run into license problems in other countries if the license is too fancy.

Seriously, just *ask* users to place their code under a non-restrictive license, and provide a few easy strings people can paste into their code (e.g. this is covered by the modifed bsd, and link to the OSI page with that license). In this community that's built around open sharing, I'd be shocked if people didn't do so. (Citizens of some countries cannot fully transfer all copyrights, so don't ask for that. Just a license that allows LT's commercial use.)

Trying to add a fancy license to a usage key is asking for user confusion and trouble.

These days, I normally put the MIT license on things I do in my spare time. It is quite permissive: it does not affect code with which it is blended and does not require source distribution; it also allows a transition to a new original work. (Here I side with Scheifler.)

If I did that, you would be able to use the code without asking.

When someone copied the code, the simplest thing for them to do would be to tack on their copyright and keep the same license. But they could do something else.

One strategy would be to license the data simply: play by the rules or we take away your key. Then make one of the rules be that your script is licensed by a generally accepted open source license.
(a) Your script means the part that interfaces with LT, not your whole site, if that's what you've got.
(b) Someone with the religion can license their script with GPL. Others who make a script based on it don't need permission, but they do assume the additional obligations. In this case, those aren't logistically burdensome, since using the script necessarily means making its source available for download.

I said this before, but not loudly enough. "You agree in advance to abide by any future changes to this license." in the T&C is a non-starter. The only reason anyone would agree to it is that it's so obviously unenforceable.

Ever bought a book on Amazon or used Google?

You understand and agree that if you use the Services after the date on which the Universal Terms or Additional Terms have changed, Google will treat your use as acceptance of the updated Universal Terms or Additional Terms.

I interpret this as fundamentally different, but I am no lawyer.

Your version allows redefinition of the terms of past usage, even if one stops when they are published.

Ah. Ok. I'm glad to make that change. Anything else?

In fact, we were planning on, if there were changes (other than additions for new services), you'd have to re-agree. But

That was all that stopped me. Thanks.

If I were a library IT manager and my end-users might be automatically agreeing for me, I might want to be it more explicitly. But I'm not.