Hi, Great question Joeri and I ended up here almost looking for the same answer also.
The existing Gadget TOS says we can not do anything to modify or remove the Google branding (or potential future ad space etc..) from the gadgets being displayed on a page, but when using these scripts they do not include any branding. eg. Add to iGoogle buttons. What is the legal position on this? My current understanding is the scripts are open source, but using them would violate the Gadgets TOS. :/ Also pointed out here by Jerome >> http://groups.google.com/group/Google-Gadgets-API/browse_thread/thread/bd205fa9d32a6018/577eb3dd6e0ccfbe "...You will not and will not allow on your behalf third parties to (a) make and distribute copies of any aspect of iGoogle (including the API) or accompanying documentation except as permitted by these API Terms and Conditions; (b) attempt to copy, reproduce, alter, modify, reverse engineer, disassemble, decompile, translate, or attempt to discover any prototypes, software, algorithms, or underlying ideas which embody iGoogle or Google API;...". This whole project seems to violate this. :( Can you please clarify, and I also would like to see Joeri's question answered too :-) I am happy to hear this announcement though! Cheers! Vision Jinx On Dec 18, 9:36 am, Joeri Sebrechts <[EMAIL PROTECTED]> wrote: > Good news. > > I'm currently contemplating the design for portlet support in a web > portal environment I'm responsible for development-wise. My initial > thought was rather than reinvent the wheel I would simply implement > google gadget container support and be able to reuse all of the > existing gadgets as well as host our own (which would in turn be > integrateable in other containers like igoogle). > > Obviously shindig would form a good basis for this (although I'd have > to replace the server-side parts with PHP), but I have questions > regarding compatibility with existing gadgets. How well would this > implementation cope with the existing mass of gadgets? I'm especially > thinking about the financial api, which will probably be mandatory if > we want to claim external gadget support to our customers. > > Also, legally it's a bit murky about what we can call this. If I > implement the api that shindig implements, can my company legally say > that we have Google Gadgets support? > > I would be grateful for any ideas on this matter. > > On Dec 12, 6:29 pm, "John Panzer" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > We're happy to announce that we've just performed the first commit to the > > Apache Shindig project, contributing Gadget Container JavaScript and Gadget > > Server Java code. > > > For some high-level context on this, read the related > > post<http://opensocialapis.blogspot.com/2007/12/lets-get-this-shindig-star...>at > > the OpenSocial Blog. > > > In addition, the initial commit comment - copied below - provides > > finer-grained detail on what's just been contributed. We expect to continue > > to flesh out the code and submit a load of features in the upcoming weeks. > > > We're excited to take this first step, and hope you are too. We're looking > > forward to keeping the pace of change high in the upcoming weeks and months. > > > Best, > > John (on behalf of a bunch of people) > > > [commit description follows] > > > Initial commit of Shindig Gadget Container JavaScript and Gadget Server. > > > Includes: > > > - Gadget Container JavaScript. Code embedded into an arbitrary web > > page enabling it to render and manage Gadgets. > > - Support for rendering using gmodules.com or a Shindig Gadget > > Server > > - Basic IFPC (gadget <-> container communication) support via > > inclusion of Google IFPC library > > - Simple layout management: render in DIV (StaticLayoutManager); > > render multiple Gadgets left-aligned in DIV (FloatLeftLayoutManager) > > - UserPrefs support through JS interface > > - Cookie-based UserPrefs implementation > > - _IG_SetTitle container-side support > > - _IG_AdjustIframeHeight container-side support > > - Sample pages demonstrating all the above functionality > > > - Gadget Server (written in Java). Web server that processes Gadget > > requests, parsing their spec XML, processing it through a workflow of > > core > > and extension (<Require>/<Optional>) Features, and serializing output for > > rendering the Gadget to the end user. > > - Core server implementation constructing processing workflows > > out of GadgetFeature objects providing various feature support > > - GadgetFeature interface providing core extensibility mechanism > > for the Gadgets platform; extenders implement GadgetFeature and > > register > > their implementation with GadgetFeatureRegistry > > - Gadget spec XML parser > > - Simple caching API with in-memory Map-based implementations as > > samples > > - Remote content (eg. HTTP) fetcher interface > > - Basic java.net-based RemoteContentFetcher implementation > > - "Hangman" variable substitution support (eg. __MSG_foo__), > > including BIDI, MSG (message bundles) and UP (user prefs) type > > variables > > - Early JavaScript-based Feature support through JsLibrary* > > classes > > - Content proxy including JSON support > > > - A handful of tests for various Server components. > > > - Maven build support. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
