So can we move the rest of the plugin to apache-extras.org too? Eugen told to move SugarCRM within the next 2 weeks. I can cover ATutor as I was also the one that committed it. What about Joomla, can it be moved? The last changes to Joomla are committed by Maxim. Zimbra changes have been committed by me, can I move it or are the argeuments against it?
Jitsi is LGPL. A possible plugin is also GPL or LGPL. Can it be moved to apache-extras.org as long as Legal details are not resolved? Teambox/Bitrix, what license can be applied to teambox/bitrix plugin? Teambox/Bitrix is not Open Source software. License of Teambox/Bitrix Plugin is not clear. Can it be moved to apache-extras.org until the authors have an answer on the legal side? Facebook Connect => Can I move it to apache-extras.org as I have committed it. Any objections on that? Thanks! Sebastian 2012/10/12 [email protected] <[email protected]> > The same applies to Drupal according to their FAQ: > http://drupal.org/licensing/faq/#q7 > > So my guess is that we should rather try to find a consens that does not > require the Apache Foundation to discuss with Drupal or Moodle Community > about changing their point of view. > > Sebastian > > 2012/10/12 [email protected] <[email protected]> > > Maixm: I share your point of view, I am not the one that you need to >> argument against :) >> However the GPL folks are quite confident that they are right: >> http://markmail.org/message/33hztgfyfxdb3jef >> >> "If the program dynamically links plug-ins, and they make function calls >> to each >> other and share data structures, we believe they form a single program, >> which >> must be treated as an extension of both the main program and the >> plug-ins. This >> means the plug-ins must be released under the GPL or a GPL-compatible free >> software license, and that the terms of the GPL must be followed when >> those >> plug-ins are distributed." >> >> I don't know if this argumentation is correct, as did Jukka say: It has >> kind of a "viral" factor. >> But as he did further explain: We do accept the wishes of other >> communities beyond the laws. And the Moodle community really wants for >> example plugins to be released under the GPL. >> >> *Even if we ignore that angle for a moment, my perspective has always >> been that it's simply not possible to develop code "100% from scratch" in >> the real world. Developers always copy existing code, and thus the new code >> needs to follow the same license.* >> Quote from Martin >> Dougiamas<https://moodle.org/user/view.php?id=1&course=5>Founder Moodle at: >> https://moodle.org/mod/forum/discuss.php?d=135896 >> >> Actually the Plugin loader at Moodle.org even checks if the plugin has >> GPL license file. They do not allow other plugins to be uploaded. >> >> Sebastian >> >> >> 2012/10/12 Maxim Solodovnik <[email protected]> >> >>> I always thought calling any methods under any license does not add any >>> restrictions to your code. >>> Google was able to implement Java and it was not violation :) >>> >>> >>> On Fri, Oct 12, 2012 at 2:15 PM, [email protected] < >>> [email protected]> wrote: >>> >>> > * limit GPL-licensed plug-ins to minimal API calls (over http);* >>> > => I don't know how that would practically be implemented? You cannot >>> call >>> > Drupal functions via HTTP, or access the Drupal/Moodle/Joomla user >>> session >>> > object and ask about user- or access rights via HTTP. >>> > Those plugin specific API calls always will be part of the plugin >>> itself >>> > and never performed via HTTP. >>> > >>> > My idea was more like: >>> > >>> > >>> http://code.google.com/a/apache-extras.org/p/openmeetings-moodle-plugin/source/browse/trunk/openmeetings_gateway.php >>> > and: >>> > >>> > >>> http://code.google.com/a/apache-extras.org/p/openmeetings-moodle-plugin/source/browse/trunk/lib/openmeetings_rest_service.php >>> > >>> > Those are files that are shared among all plugins. We could bundle >>> those >>> > files and make a general integration SDK and distribute it under the >>> Apache >>> > License as they do not contain any Drupal/Moodle/Joomla/platform xyz >>> > specific code. >>> > >>> > The plugins could use this SDK plus add the platform specific code and >>> then >>> > distribute at apache-extras.org. >>> > >>> > Sebastian >>> > >>> > 2012/10/11 Alexei Fedotov <[email protected]> >>> > >>> > > So my take on this is the following: >>> > > >>> > > 1) limit GPL-licensed plug-ins to minimal API calls (over http); >>> > > 2) move any complex logic to our side (to Openmeetings services, or >>> > > standalone services which do more elaborate calls to Openmeetings). >>> > > >>> > > We are pretty close to this anyway. >>> > > >>> > > >>> > > On Thu, Oct 11, 2012 at 10:17 PM, [email protected] < >>> > > [email protected]> wrote: >>> > > >>> > > > The general "echo" is rather negative. >>> > > > >>> > > > For example Sam Ruby's answer a time ago was: >>> > > > *The operative phrase here being "the terms of the GPL must be >>> followed >>> > > > when those plug-ins are distributed." This really sounds more like >>> > > > something that would be made available at Apache Extras:* >>> > > > Quoted from: http://markmail.org/message/33hztgfyfxdb3jef >>> > > > >>> > > > Other follow up that, for example Jukka Zitting did say: >>> > > > *I agree with that argument against the viral nature of GPL, but in >>> > > general >>> > > > the ASF has tended to honor the wishes of upstream copyright owners >>> > also >>> > > > beyond the requirements of copyright law.* >>> > > > Quoted from: http://markmail.org/message/je5hzdocsloofidd >>> > > > >>> > > > So if the Vice President of Legal Affairs of the Apache Foundation >>> and >>> > > the >>> > > > chair of the Apache Incubator thinks that it would be rather >>> better to >>> > > > release those plugins outside of the ASF I think chances to release >>> > them >>> > > > inside require very good arguments and lot of time. >>> > > > >>> > > > I agree to your position that it _should_ be possible to release >>> under >>> > > the >>> > > > Apache License, but I think we should not make the graduation of >>> our >>> > > > project depending on the legal status of the plugins. >>> > > > If the final decision is that its okay to release them under the >>> Apache >>> > > > License => Great! We can still move them to Apache at any time. >>> > > > >>> > > > After all this looks like some kind of blocker that keeps us away >>> from >>> > > > moving forward. apache-extras.org might be a good way to resolve >>> this >>> > > and >>> > > > keep concentrating on enhancing our core product. >>> > > > >>> > > > Sebastian >>> > > > >>> > > > 2012/10/11 Maxim Solodovnik <[email protected]> >>> > > > >>> > > > > I always thought that since our code contains zero lines of code >>> > under >>> > > > > incompatible license we are free to release it under ASF. I do >>> > remember >>> > > > > this was confirmed by last email from legal team >>> > > > > On Oct 11, 2012 9:24 PM, "[email protected]" < >>> > > [email protected]> >>> > > > > wrote: >>> > > > > >>> > > > > > Hi, >>> > > > > > >>> > > > > > before we try to organize a Vote for graduation it might makes >>> > sense >>> > > to >>> > > > > > clean up plugins from the SVN that have unclear legal status. >>> > > > > > >>> > > > > > I started to move Moodle to apache-extras.org and Drupal. >>> Cause >>> > the >>> > > > > > discussion already has gone quite far that it is not >>> acceptable to >>> > > > > > distribute them at the ASF. >>> > > > > > >>> > > > > > What do you think? >>> > > > > > >>> > > > > > Sebastian >>> > > > > > >>> > > > > > -- >>> > > > > > Sebastian Wagner >>> > > > > > https://twitter.com/#!/dead_lock >>> > > > > > http://www.webbase-design.de >>> > > > > > http://www.wagner-sebastian.com >>> > > > > > [email protected] >>> > > > > > >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > Sebastian Wagner >>> > > > https://twitter.com/#!/dead_lock >>> > > > http://www.webbase-design.de >>> > > > http://www.wagner-sebastian.com >>> > > > [email protected] >>> > > > >>> > > >>> > >>> > >>> > >>> > -- >>> > Sebastian Wagner >>> > https://twitter.com/#!/dead_lock >>> > http://www.webbase-design.de >>> > http://www.wagner-sebastian.com >>> > [email protected] >>> > >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
