Terms of Use

5 views
Skip to first unread message

Doug Kaye

unread,
Dec 10, 2009, 8:41:41 PM12/10/09
to spokenw...@googlegroups.com
I'm still playing catch-up after three weeks in Africa, house guests, etc. And while working on the APIs is near the top of my to-do list, I have made some progress. I've just updated the API docs (http://docs.google.com/View?id=dfstbcg_4djzxbkfd) to refer to the updated API Terms of Use (http://www.spokenword.org/apiTermsOfUse).

Yes, The Terms of User are long, but they're also necessary. And if you don't like something in there, blame Netflix. Our Terms of Use are to a great extent based on theirs. :-)

But seriously, if you have any questions about the Terms of Use or suggestions about how they can be improved, just let me know.

   ...doug

Ken Kennedy

unread,
Dec 11, 2009, 3:57:26 PM12/11/09
to spokenw...@googlegroups.com
I'llll...have to think seriously about these, Doug. I'm sure they're probably "standard", but, for example:

-----

3.2: " You will not, and will not permit any person, directly or indirectly, to reverse engineer, disassemble, reconstruct, decompile, translate, modify, copy, or, other than as explicitly permitted hereunder, create derivative works of the Conversations Network service, including, without limitation, the API, or any aspect or portion thereof, including without limitation, source code and algorithms."

Heck...I've come close to giving you advice on how to improve the DDL of the tables behind the scenes here, commented on algorithms, etc. In addition, your APIs aren't exactly revolutionary...I believe some of it was based on ideas from other APIs like Friendfeed, etc. That being said...I guess 3.2 (iv) somehow magically gives away my rights to my feedback, though. Nice. Lawyers are clever, aren't they? (I realize that's something that was probably part of the Netflix ToS; not suggesting you're being nefarious).

I'm just not a fan of this sort of thing.

-----

3.2 Conversations Network Property. As between you and the Conversations Network, the Conversations Network retains all right, title and interest, including without limitation all intellectual property rights, in and to ... (ii) the Content available through the API;

Some of the content available through the API is CC-licensed (descriptions of many podcasts, for example). I don't have any idea how this affects that content, but I really don't want to have to try and figure that out.

-----

1.9 Advertising. The Conversations Network reserves the right to include advertising or any other materials in any portion of the API. Any such advertising shall be not modified, obscured or deleted in your Application.

If I'm trying to keep track of my listening via queues at CN, and you insert advertising into the JSON data stream, I'm gonna be honest...I'm not going to display it to myself. (or anyone else, if I use a Google App Engine app or something to manage this). If that's a deal-breaker, I guess we'd better bring that up now.

-----

I guess part of this comes from the fact that you're taking terms of use from a commerical entity (Netflix), whose content is fairly restricted copyright-wise, and applying them to the non-profit CN and content that is in some cases CC-licensed. But I'll honestly need to think about whether I'm going to inadvertently step on some of these provisions.

If it comes to not using the API, I may still try to figure out a way to at least push my ratings up to the site. But I may have to bail on the rest of my work to actually use collections as listening queues, etc. Nothing personal, but I may not want to wade through the potential minefield of this legalese just to have a cache of the RSS feeds available with an (admittedly nice) API already built on top. That part I can already do.






--

You received this message because you are subscribed to the Google Groups "SpokenWord.org APIs" group.
To post to this group, send email to spokenw...@googlegroups.com.
To unsubscribe from this group, send email to spokenword-ap...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spokenword-api?hl=en.



--
Ken Kennedy
Contact info: http://kenzoid.com/me/contact

Doug Kaye

unread,
Dec 11, 2009, 4:29:06 PM12/11/09
to spokenw...@googlegroups.com
Great feedback, Ken.  I'll be reviewing it.

   ...doug

Ken Kennedy

unread,
Dec 11, 2009, 4:32:01 PM12/11/09
to spokenw...@googlegroups.com
Thanks, Doug! I honestly didn't mean that in an overly cranky way...just dredging through that sort of legalese normally makes my stomach a little queasy *grin*, and I've been listening to a lot of podcasts recently where this sort of thing is brought up (Cory Doctorow's book tour, primarily), so I'm sensitized. I have no doubt that you're trying to do the right thing.

--

You received this message because you are subscribed to the Google Groups "SpokenWord.org APIs" group.
To post to this group, send email to spokenw...@googlegroups.com.
To unsubscribe from this group, send email to spokenword-ap...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spokenword-api?hl=en.

Doug Kaye

unread,
Dec 11, 2009, 4:36:20 PM12/11/09
to spokenw...@googlegroups.com
I hear you, Ken. But APIs are very different from normal Terms of Service. The reason are (a) bad use can crash the site, (b) you've got almost direct access to the database, and (c) app developers are expected to present SW to the world, hence the issues about brands, trademarks, etc.

Having said that, our regular Terms of Service will probably make your stomach queasy, too! http://www.spokenword.org/termsOfService

   ...doug

Thilo Planz

unread,
Dec 11, 2009, 7:30:21 PM12/11/09
to spokenw...@googlegroups.com
>
> 3.2: " You will not, and will not permit any person, directly or indirectly,
> to reverse engineer, disassemble, reconstruct, decompile, translate, modify,
> copy, or, other than as explicitly permitted hereunder, create derivative
> works of the Conversations Network service, including, without limitation,
> the API, or any aspect or portion thereof, including without limitation,
> source code and algorithms."


I make the source code for my Spokenstars site available on an
open-source code hosting site.

Is that a problem?

Thilo

Ken Kennedy

unread,
Dec 13, 2009, 6:14:54 PM12/13/09
to spokenw...@googlegroups.com
My code is also available under a F/OSS license, and at an open source code hosting site.

--

You received this message because you are subscribed to the Google Groups "SpokenWord.org APIs" group.
To post to this group, send email to spokenw...@googlegroups.com.
To unsubscribe from this group, send email to spokenword-ap...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spokenword-api?hl=en.


Doug Kaye

unread,
Dec 20, 2009, 1:30:28 PM12/20/09
to spokenw...@googlegroups.com
On Fri, Dec 11, 2009 at 12:57 PM, Ken Kennedy <ken...@gmail.com> wrote:
I'llll...have to think seriously about these, Doug. I'm sure they're probably "standard", but, for example:

3.2: " You will not, and will not permit any person, directly or indirectly, to reverse engineer, disassemble, reconstruct, decompile, translate, modify, copy, or, other than as explicitly permitted hereunder, create derivative works of the Conversations Network service, including, without limitation, the API, or any aspect or portion thereof, including without limitation, source code and algorithms."

Heck...I've come close to giving you advice on how to improve the DDL of the tables behind the scenes here, commented on algorithms, etc. In addition, your APIs aren't exactly revolutionary...I believe some of it was based on ideas from other APIs like Friendfeed, etc. That being said...I guess 3.2 (iv) somehow magically gives away my rights to my feedback, though. Nice. Lawyers are clever, aren't they? (I realize that's something that was probably part of the Netflix ToS; not suggesting you're being nefarious).

I'm just not a fan of this sort of thing.

We must be reading entirely different things. There's nothing in the language that says our code is special or unique. It just says that you can't copy the code or make a "derivative work". That doesn't keep you from creating your own API to your own service. We own our code and you own yours. And Twitter and Netflix own their code. I just don't see what you're concerned about. Try explaining it again.

As for ownership of feedback, that really is standard. It's not about keeping you from doing something. It's about allowing us to use your feedback to improve our APIs without you later demanding payment or royalties for your suggestions. Again, what is the problem you see? I don't see the issue?
 

3.2 Conversations Network Property. As between you and the Conversations Network, the Conversations Network retains all right, title and interest, including without limitation all intellectual property rights, in and to ... (ii) the Content available through the API;

Some of the content available through the API is CC-licensed (descriptions of many podcasts, for example). I don't have any idea how this affects that content, but I really don't want to have to try and figure that out.

Yes, we need to adjust that language to deal with the fact that we don't actually own any of the content that comes through the API. We'll fix it!


1.9 Advertising. The Conversations Network reserves the right to include advertising or any other materials in any portion of the API. Any such advertising shall be not modified, obscured or deleted in your Application.

If I'm trying to keep track of my listening via queues at CN, and you insert advertising into the JSON data stream, I'm gonna be honest...I'm not going to display it to myself. (or anyone else, if I use a Google App Engine app or something to manage this). If that's a deal-breaker, I guess we'd better bring that up now.

We're saying that we reserve the right to change what we do. There's nothing to say that you have to continue to use our APIs if we change them. You always have the right to stop using the service, but we always have the right to change it. What's so unreasonable about that? We have no intention to insert ads, but why should we commit to never making changes? What's the threat to you?


I guess part of this comes from the fact that you're taking terms of use from a commerical entity (Netflix), whose content is fairly restricted copyright-wise, and applying them to the non-profit CN and content that is in some cases CC-licensed. But I'll honestly need to think about whether I'm going to inadvertently step on some of these provisions.

Again, we'll fix the ToU to separate our APIs (which are not CC) from the content (which is owned by others). Nothing we do affects the copyright or licensing of the thirs-party content, so that's a complete non-issue. As for our APIs, we own 'em. You can use 'em. What else is it that you want? The APIs themselves are not public domain or CC-licensed, but I don't see why that's a problem. Do you?

 
If it comes to not using the API, I may still try to figure out a way to at least push my ratings up to the site. But I may have to bail on the rest of my work to actually use collections as listening queues, etc. Nothing personal, but I may not want to wade through the potential minefield of this legalese just to have a cache of the RSS feeds available with an (admittedly nice) API already built on top. That part I can already do.

That's up to you, of course. But I don't see why you'd abandon a project based on what might change versus (a) what exists now, and (b) what might change in some obscure scenario. Don't get hung up on the Netflix heritage. I only mentioned that for interest. Go by the words themselves, not where they came from. As for the rating data, unlike others services, we give you the right o extract that information at any time. You can also export your collections at any time.


Do you use any other APIs like Twitter or Facebook? Would you do so? We'll fix the errors in our Terms of Use that you and others have pointed out, but I think you'd agree that we're much more likely to be fair and reasonable with how we deal with the issues you're concerned about than most other vendors.

And I hope you won't be afraid of the APIs just because the Terms of Use include "legalese". Try to stand in our shows and read them with that perspective. I think you'll find that we can't offer the APIs without the protections this document includes.

In any case, don't stop sending those comments.


   ...doug

Doug Kaye

unread,
Dec 20, 2009, 1:33:42 PM12/20/09
to spokenw...@googlegroups.com

Not at all. Your code is your code and ours is ours. There's nothing in the ToU that gives us any rights to your code.

   ...doug
 

Doug Kaye

unread,
Dec 20, 2009, 1:38:10 PM12/20/09
to spokenw...@googlegroups.com
For those who may be freaking out about our API Terms of Use, if it helps you feel any better, know that our lawyers are from the team that do a lot of work for Create Commons and EFF. Openness and fairness aren't at odds with contracts. The reason CC exists isn't to eliminate licenses, but rather to standardize them. Take a look at a full-length CC license and you'll see that it has no shortage of legalese.

    ...doug

Doug Kaye, Executive Director
The Conversations Network
A 501(c)(3) Non-Profit
do...@rds.com
v: 415.868.5461
twitter: dougkaye
facebook.com/doug.kaye

Ken Kennedy

unread,
Dec 21, 2009, 11:33:23 AM12/21/09
to spokenw...@googlegroups.com
On Sun, Dec 20, 2009 at 1:38 PM, Doug Kaye <do...@rds.com> wrote:
For those who may be freaking out about our API Terms of Use, if it helps you feel any better, know that our lawyers are from the team that do a lot of work for Create Commons and EFF. Openness and fairness aren't at odds with contracts. The reason CC exists isn't to eliminate licenses, but rather to standardize them. Take a look at a full-length CC license and you'll see that it has no shortage of legalese.


I for one am not freaking out, Doug, *grin*, but while knowing that the lawyers are from CC and EFF is nice, it doesn't make things magically OK. I'm definitely familiar with full CC licenses; CC is indeed about standardizing usage and licensing...but it's also (and importantly) about granting rights over and above the standard. As they say...from "all rights reserved" to "some rights reserved". It's an expansion of my rights from the standard ones allowed by copyright, not a restriction.

I don't hate "legalese" for the sake of it, but instead for the fact that it's mostly there to restrict things. I trust you personally, Doug, I just have to heave a big *sigh* as I read through an entire section of "Proprietary Rights" and try and figure out what that means, how it affects me, how it interacts with the CC-licensed data that pumps through the system, etc.

You mentioned the Twitter and Facebook APIs in the other thread, and no, I'm not a big user of either, paritially for the same reasons. On the other hand, there's the Friendfeed API, which TOS wise, seems pretty simple.

Again, there's no real huge issue, but to me there does seem, to me, to be a bit of a different "feel" to that TOS than there is to most of the Spokenword and ITC sites and work. I'm sure it will work out.

Doug Kaye

unread,
Dec 21, 2009, 2:20:48 PM12/21/09
to spokenw...@googlegroups.com
I don't want to beat this to death either, Ken, but I do want to be clear. Our ToU agreement has *nothing* to do with any rights you may have (or not have) to the third-party programs. We (The Conversations Network) are not representing that we have any rights that we can pass along to you. If we were to copy the media files and deliver them from our servers (as some sites do) that would be a different matter. But we don't do that.

The ToU are about the APIs, not the content. The agreement has nothing whatsoever to do (quoting you) "with the CC-licensed data that pumps through the system, etc."

Having said that, there is the issue of the metadata: the descriptions, titles, filenames, etc. This is comparatively a vague area. In most cases (typically non-CC licensed) we don't have explicit rights to use this data. But we're going on the basis that we (and you, too) have certain implicit rights. For example, when YouTube publishes a video with the option to embed their player, there are certain implicit rights. Actually, in the case of YouTube those rights are explicit in their own ToU, so that's not the best example. A better example would be a more amateur podcast that is published via RSS with no explicit Terms of Use. In that case, we do not have the rights to copy and republish the media file. That is clear. But we do have the right to "review" the programs, which (in our interpretation) includes the right to republish the title, description, keywords, etc. We believe you have that right, too, but that's for you to interpret on your own. The same would be true if you got that metadata directly from the publisher. We're not suggesting that we increase or decrease the rights you may have to those programs or metadata. The publication via RSS implies, in our interpretation, certain implied rights in the same way that publishing a book implies certain rights (fair use, etc.).

So (to all, not just Ken) please keep in mind that our Terms of Use are with regard to our API not any data or media you may receive through it that comes from third parties. And we *will* make this clearer in the next version.

   ...doug

Doug Kaye

unread,
Dec 21, 2009, 2:45:02 PM12/21/09
to spokenw...@googlegroups.com
BTW, the reason for continuing this discussion is that it's very important to us that the Terms of Use be right. We don't want to have an agreement that forces users to accept grudgingly or without understanding it. I doubt there's anything we would want in the ToU that you would truly object to, so if it seems that way then there's either (a) an error in our document, or (b) a misunderstanding as to what it means.

Thanks for your patience.

   ...doug

Ken Kennedy

unread,
Dec 21, 2009, 3:21:34 PM12/21/09
to spokenw...@googlegroups.com
Not beating to death either, *grin*, but just to clarify...the "CC-licensed data that pumps through the system" that I was talking about WAS the metadata...in particular at least, descriptions, for example.  I know you don't copy the media files; you do the (at least sometimes CC-licensed) metadata, though. That's what I was talking about.

But clarifying it to the API resolves that issue.

--

You received this message because you are subscribed to the Google Groups "SpokenWord.org APIs" group.
To post to this group, send email to spokenw...@googlegroups.com.
To unsubscribe from this group, send email to spokenword-ap...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spokenword-api?hl=en.
Reply all
Reply to author
Forward
0 new messages