You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Ross Gardler <rg...@apache.org> on 2009/07/21 23:20:36 UTC
A few more IP issues and code preparation
Whilst we are waiting for the relevant legal documents to be filed
perhaps the Wookie team would like to prepare the code for import.
There are four incompatibly licensed dependencies (assuming the notice
file is up to date):
c3p0
Java Transactions API
MySQL Connector
Hibernate
These cannot be brought in to ASF infrastructure and thus must be
removed from the repository and build instructions updated
accordingly. We'll have to replace these dependencies during
incubation. I note that during the proposal stage Scott mentioned that
moving to CouchDB might make sense. we can explore this once the
initial code import is complete.
Since my initial evaluation of the code I have identified a few other
potential conflicts:
I am unsure of our ability to Apache License the Moodle, Elgg and
Wordpress plugins since each of these containers is GPL and I have no
idea if the viral nature of the GPL is invoked by these plugins. It is
a contentious issue. The FSF general claim that modules are "touched"
by the GPL whereas Linux says they are not (and I'd suggest that Linux
Kernel modules are closer to the GPL code than a typical Moodle plugin
for example).
I also note that there is some code from Apple which is not under a
licence I am familiar with. See
http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/shared/mac-resources/WidgetResources/AppleClasses/AppleAnimator.js?revision=1.1&view=markup
I'm also not sure about the widgets in
http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/widgets/
I'm pretty sure the code for (at least some of) these come from the
Google Wave project, what licence are they under and do they contain
any code from other third parties.
I'd like to hear the thoughts of the mentors on handling these issues.
I'd also appreciate it if mentors can look over the code to see if
there are any items I've missed (note the lib files are in an unusual
place: http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/WEB-INF/lib/
)
Finally, one for the committers may like to prepare the codebase for
importation into the repository. Other than the above IP issues the
packages will need to be renamed org.apache.wookie.*
Ross
--
Ross Gardler
OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk
Re: Progress on IP issues and code preparation
Posted by Ross Gardler <rg...@apache.org>.
2009/7/26 Scott Wilson <sc...@gmail.com>:
> Here's an update on progress on outstanding items:
>
> 1. Incompatibly-licensed dependencies
>
> These have been removed from the repository; I've added properties in
> build.xml that the developer will need to set to identify where these are
> located to build and deploy wookie. Also put a note in the README about
> these. Kris is putting a checking stage into the build.
>
Perfect
> 2. Plugins
>
> We haven't touched these in the repo; I suggest we just don't move them into
> the incubator SVN but move them into "wookie extras" when we get that set
> up. The rails plugin is actually a bit out of date anyway, it would probably
> be easier to start again with current rails and current wookie.
Gavin, when we do the SVN import will we be able to exclude certain
directories or should we move these out of the existing SVN into a
branch of the existing repo for transition.
Scott, the reason for my question above is that we need to be able to
import the full history of the project which is our first port of call
if there is ever a challenge on the IP in the code base in the future.
> 3. Widgets
>
> Removed Apple JS libs from the repo;
> Added Creole.js to licenses/all_licenses.txt (and inside the config.xml
> "license" element for WookieWiki.wgt)
> Added JQuery to licenses/all_licenses.txt
> Replaced the Skype emoticons in Natter with some CC-BY licensed ones and
> added attribution & license in the config.xml "license" element
Cool.
> TODO: contact Wave team re sample code in Sudoku & Poetry gadgets
>
> I think we should go with Ross's suggestion and leave waveword out as it
> could have legal issues. However we can reuse the turn-based-wave-games JS
> lib I created for it for something less problematic in future. For now I've
> left it in repo, but we should make sure we don't copy it over into the
> incubator SVN.
Ditto my question above.
> 4. Packaging
>
> Moved all packages to org.apache.wookie
Great
> TODO change all the src headers to use apache 2.0 license
OK
> 5. CLAs
>
> I faxed mine in on Friday, I presume Paul and Kris are on the case with
> theirs. I'll chase the University of Bolton CCLA tomorrow.
Gavin and I will keep our eyes open for these being put into SVN, at
this point Gavin will be able to create your apache IDs. An give you
access to the SVN.
Whilst we wait for full clearance on the code we can start work on the
Wookie site. I'll post a different mail about that.
> TODO contact Stef and Phil
Yep.
Ross
> On 21 Jul 2009, at 23:37, Ross Gardler wrote:
>
>> 2009/7/21 Scott Wilson <sc...@gmail.com>:
>>>
>>> On 21 Jul 2009, at 22:20, Ross Gardler wrote:
>>>
>>>> Whilst we are waiting for the relevant legal documents to be filed
>>>> perhaps the Wookie team would like to prepare the code for import.
>>>>
>>>> There are four incompatibly licensed dependencies (assuming the notice
>>>> file is up to date):
>>>>
>>>> c3p0
>>>> Java Transactions API
>>>> MySQL Connector
>>>> Hibernate
>>>>
>>>> These cannot be brought in to ASF infrastructure and thus must be
>>>> removed from the repository and build instructions updated
>>>> accordingly. We'll have to replace these dependencies during
>>>> incubation. I note that during the proposal stage Scott mentioned that
>>>> moving to CouchDB might make sense. we can explore this once the
>>>> initial code import is complete.
>>>
>>> Removing Hibernate+MySQL+c3p0+JTA will require a bit of a rethink on the
>>> ORM
>>> front - maybe we can use OpenJPA, or just get rid of ORM and use plain
>>> JDBC
>>> & SQL. CouchDB could be interesting for the actual widget instance
>>> preference and state data.
>>>
>>> However its a fair chunk of work removing these dependencies - is it best
>>> if
>>> we fix these outside the incubator and then move the code when its
>>> working,
>>> or submit the code as-is but with just the libraries and build info
>>> removed
>>> (i.e., not working) and then fix it in the incubator?
>>
>> The problem is not that your code depends on them, it is that because
>> of the licence incompatibilities we cannot distribute from ASF
>> infrastructure. So there is no need to break things completely. I
>> recommend:
>>
>> - Remove the libs.
>>
>> - Add a step to the build instructions saying the libs need to be
>> manually downloaded and placed in the lib directory
>>
>> - make build.xml check for their existence and failing with a sensible
>> message
>>
>> This means that anyone building Wookie will be aware that there are
>> licence incompatibilities and must act accordingly if they
>> redistribute. In other words, there are no hidden surprises in our
>> distribution.
>>
>>
>>>> Since my initial evaluation of the code I have identified a few other
>>>> potential conflicts:
>>>>
>>>> I am unsure of our ability to Apache License the Moodle, Elgg and
>>>> Wordpress plugins since each of these containers is GPL and I have no
>>>> idea if the viral nature of the GPL is invoked by these plugins. It is
>>>> a contentious issue. The FSF general claim that modules are "touched"
>>>> by the GPL whereas Linux says they are not (and I'd suggest that Linux
>>>> Kernel modules are closer to the GPL code than a typical Moodle plugin
>>>> for example).
>>>
>>> I think its a reasonable question to ask whether the Apache Wookie
>>> project
>>> should include the plugins, or just the engine. If not the plugins could
>>> be
>>> handled outside in a separate project, or (my preference, but difficult
>>> in
>>> practice) they can be taken on by the container projects themselves.
>>
>> The rails one can certainly come into the ASF and would act as an
>> example. I'd like to see a project socialsite and/or Wicket and/or
>> roller plugin developed pretty quickly as examples. I'll return to the
>> other plugins at the end of this mail.
>>
>>>> I also note that there is some code from Apple which is not under a
>>>> licence I am familiar with. See
>>>>
>>>>
>>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/shared/mac-resources/WidgetResources/AppleClasses/AppleAnimator.js?revision=1.1&view=markup
>>>>
>>>> I'm also not sure about the widgets in
>>>>
>>>>
>>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/widgets/
>>>> I'm pretty sure the code for (at least some of) these come from the
>>>> Google Wave project, what licence are they under and do they contain
>>>> any code from other third parties.
>>>
>>> The Apple files included in shared/mac-resources can be removed - this
>>> was a
>>> convenience for when running converted Apple Dashboard during early
>>> testing,
>>> but isn't appropriate for inclusion now.
>>
>> OK. That's a simple solution then.
>>
>>> Looking at the Widgets in the /widgets folder:
>>>
>>> * WookieWiki.wgt uses Creole.js, which uses an MIT-style license.
>>
>> MIT is fine - but you may need to add an entry to the NOTICE file.
>>
>>> * Sudoku.wgt uses some Google JS code which has no identifiable license.
>>
>> Assuming this is the code from the wave API samples I'd suggest a mail
>> to the API group asking them to clarify the license situation. Almost
>> certainly they will put it under a permissive licence since it is
>> sample code.
>>
>> http://groups.google.com/group/google-wave-api
>>
>> Can you, or one of the committers please follow this up.
>>
>>> * WaveWord.wgt uses some code from
>>> http://www.themaninblue.com/experiment/SSCrabble/ of indeterminate
>>> license,
>>> and JQuery which is dual MIT and GPL.
>>
>> JQuery is fine as we can take it under MIT.
>>
>> The other code is a concern for two reasons. The first is that there
>> is no clear licence, this can probably be resolved with a quick email.
>> However, there is every possibility that the code infringes on Mattel
>> trademarks.
>>
>> It may be better to leave this widget in another location, see end of this
>> mail.
>>
>>> * Test.wgt doesn't use any outside code (its for testing API compliance
>>> with
>>> specs).
>>>
>>> * YouDecide.wgt doesn't use any outside code.
>>
>> Good.
>>
>>> Inside the /WebContent/wservices folder are widgets included in a default
>>> build:
>>>
>>> * Natter uses some Apple code; this can be removed as its just chrome.
>>> JQuery again. And the smileys are actually Skype emoticons under the
>>> Skype
>>> Component license:
>>> https://developer.skype.com/Download/SkypeEmoticons however I think these
>>> actually aren't being used under the license appropriately and would need
>>> to
>>> be replaced with some genuinely open emoticon images. If anyone knows of
>>> any
>>> this would be very handy!
>>
>> I often use http://www.famfamfam.com/lab/icons/silk/ for icons, I'm
>> pretty sure there are some emoticons in there to. CC-BY-SA licence
>>
>>> None of the other widgets (weather, vote, chat, forum) use any external
>>> code.
>>
>> Excellent.
>>
>>>> I'd like to hear the thoughts of the mentors on handling these issues.
>>>> I'd also appreciate it if mentors can look over the code to see if
>>>> there are any items I've missed (note the lib files are in an unusual
>>>> place:
>>>>
>>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/WEB-INF/lib/
>>>> )
>>
>> My suggestion for the plugins and widgets of questionable licence is
>> to do as Scott suggests and start a separate google
>> code/sourceforge/whatever repository to house incompatibly licensed
>> plugins (which are actually plugins for containers rather than for
>> Wookie - the name is confusing) and widgets.
>>
>> Lets call it wookie-extras
>>
>> Committers on Wookie should be given commit on wookie-extras too, but
>> committers on wookie-extras do not automatically get commit on wookie.
>> we can have a lower barrier to commit on wookie-extras and treat it as
>> a kind of incubating site for widgets.
>>
>> Ross
>
>
--
Ross Gardler
OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk
Progress on IP issues and code preparation
Posted by Scott Wilson <sc...@gmail.com>.
Here's an update on progress on outstanding items:
1. Incompatibly-licensed dependencies
These have been removed from the repository; I've added properties in
build.xml that the developer will need to set to identify where these
are located to build and deploy wookie. Also put a note in the README
about these. Kris is putting a checking stage into the build.
2. Plugins
We haven't touched these in the repo; I suggest we just don't move
them into the incubator SVN but move them into "wookie extras" when we
get that set up. The rails plugin is actually a bit out of date
anyway, it would probably be easier to start again with current rails
and current wookie.
3. Widgets
Removed Apple JS libs from the repo;
Added Creole.js to licenses/all_licenses.txt (and inside the
config.xml "license" element for WookieWiki.wgt)
Added JQuery to licenses/all_licenses.txt
Replaced the Skype emoticons in Natter with some CC-BY licensed ones
and added attribution & license in the config.xml "license" element
TODO: contact Wave team re sample code in Sudoku & Poetry gadgets
I think we should go with Ross's suggestion and leave waveword out as
it could have legal issues. However we can reuse the turn-based-wave-
games JS lib I created for it for something less problematic in
future. For now I've left it in repo, but we should make sure we don't
copy it over into the incubator SVN.
4. Packaging
Moved all packages to org.apache.wookie
TODO change all the src headers to use apache 2.0 license
5. CLAs
I faxed mine in on Friday, I presume Paul and Kris are on the case
with theirs. I'll chase the University of Bolton CCLA tomorrow.
TODO contact Stef and Phil
S
On 21 Jul 2009, at 23:37, Ross Gardler wrote:
> 2009/7/21 Scott Wilson <sc...@gmail.com>:
>>
>> On 21 Jul 2009, at 22:20, Ross Gardler wrote:
>>
>>> Whilst we are waiting for the relevant legal documents to be filed
>>> perhaps the Wookie team would like to prepare the code for import.
>>>
>>> There are four incompatibly licensed dependencies (assuming the
>>> notice
>>> file is up to date):
>>>
>>> c3p0
>>> Java Transactions API
>>> MySQL Connector
>>> Hibernate
>>>
>>> These cannot be brought in to ASF infrastructure and thus must be
>>> removed from the repository and build instructions updated
>>> accordingly. We'll have to replace these dependencies during
>>> incubation. I note that during the proposal stage Scott mentioned
>>> that
>>> moving to CouchDB might make sense. we can explore this once the
>>> initial code import is complete.
>>
>> Removing Hibernate+MySQL+c3p0+JTA will require a bit of a rethink
>> on the ORM
>> front - maybe we can use OpenJPA, or just get rid of ORM and use
>> plain JDBC
>> & SQL. CouchDB could be interesting for the actual widget instance
>> preference and state data.
>>
>> However its a fair chunk of work removing these dependencies - is
>> it best if
>> we fix these outside the incubator and then move the code when its
>> working,
>> or submit the code as-is but with just the libraries and build info
>> removed
>> (i.e., not working) and then fix it in the incubator?
>
> The problem is not that your code depends on them, it is that because
> of the licence incompatibilities we cannot distribute from ASF
> infrastructure. So there is no need to break things completely. I
> recommend:
>
> - Remove the libs.
>
> - Add a step to the build instructions saying the libs need to be
> manually downloaded and placed in the lib directory
>
> - make build.xml check for their existence and failing with a
> sensible message
>
> This means that anyone building Wookie will be aware that there are
> licence incompatibilities and must act accordingly if they
> redistribute. In other words, there are no hidden surprises in our
> distribution.
>
>
>>> Since my initial evaluation of the code I have identified a few
>>> other
>>> potential conflicts:
>>>
>>> I am unsure of our ability to Apache License the Moodle, Elgg and
>>> Wordpress plugins since each of these containers is GPL and I have
>>> no
>>> idea if the viral nature of the GPL is invoked by these plugins.
>>> It is
>>> a contentious issue. The FSF general claim that modules are
>>> "touched"
>>> by the GPL whereas Linux says they are not (and I'd suggest that
>>> Linux
>>> Kernel modules are closer to the GPL code than a typical Moodle
>>> plugin
>>> for example).
>>
>> I think its a reasonable question to ask whether the Apache Wookie
>> project
>> should include the plugins, or just the engine. If not the plugins
>> could be
>> handled outside in a separate project, or (my preference, but
>> difficult in
>> practice) they can be taken on by the container projects themselves.
>
> The rails one can certainly come into the ASF and would act as an
> example. I'd like to see a project socialsite and/or Wicket and/or
> roller plugin developed pretty quickly as examples. I'll return to the
> other plugins at the end of this mail.
>
>>> I also note that there is some code from Apple which is not under a
>>> licence I am familiar with. See
>>>
>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/shared/mac-resources/WidgetResources/AppleClasses/AppleAnimator.js?revision=1.1&view=markup
>>>
>>> I'm also not sure about the widgets in
>>>
>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/widgets/
>>> I'm pretty sure the code for (at least some of) these come from the
>>> Google Wave project, what licence are they under and do they contain
>>> any code from other third parties.
>>
>> The Apple files included in shared/mac-resources can be removed -
>> this was a
>> convenience for when running converted Apple Dashboard during early
>> testing,
>> but isn't appropriate for inclusion now.
>
> OK. That's a simple solution then.
>
>> Looking at the Widgets in the /widgets folder:
>>
>> * WookieWiki.wgt uses Creole.js, which uses an MIT-style license.
>
> MIT is fine - but you may need to add an entry to the NOTICE file.
>
>> * Sudoku.wgt uses some Google JS code which has no identifiable
>> license.
>
> Assuming this is the code from the wave API samples I'd suggest a mail
> to the API group asking them to clarify the license situation. Almost
> certainly they will put it under a permissive licence since it is
> sample code.
>
> http://groups.google.com/group/google-wave-api
>
> Can you, or one of the committers please follow this up.
>
>> * WaveWord.wgt uses some code from
>> http://www.themaninblue.com/experiment/SSCrabble/ of indeterminate
>> license,
>> and JQuery which is dual MIT and GPL.
>
> JQuery is fine as we can take it under MIT.
>
> The other code is a concern for two reasons. The first is that there
> is no clear licence, this can probably be resolved with a quick email.
> However, there is every possibility that the code infringes on Mattel
> trademarks.
>
> It may be better to leave this widget in another location, see end
> of this mail.
>
>> * Test.wgt doesn't use any outside code (its for testing API
>> compliance with
>> specs).
>>
>> * YouDecide.wgt doesn't use any outside code.
>
> Good.
>
>> Inside the /WebContent/wservices folder are widgets included in a
>> default
>> build:
>>
>> * Natter uses some Apple code; this can be removed as its just
>> chrome.
>> JQuery again. And the smileys are actually Skype emoticons under
>> the Skype
>> Component license:
>> https://developer.skype.com/Download/SkypeEmoticons however I think
>> these
>> actually aren't being used under the license appropriately and
>> would need to
>> be replaced with some genuinely open emoticon images. If anyone
>> knows of any
>> this would be very handy!
>
> I often use http://www.famfamfam.com/lab/icons/silk/ for icons, I'm
> pretty sure there are some emoticons in there to. CC-BY-SA licence
>
>> None of the other widgets (weather, vote, chat, forum) use any
>> external
>> code.
>
> Excellent.
>
>>> I'd like to hear the thoughts of the mentors on handling these
>>> issues.
>>> I'd also appreciate it if mentors can look over the code to see if
>>> there are any items I've missed (note the lib files are in an
>>> unusual
>>> place:
>>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/WEB-INF/lib/
>>> )
>
> My suggestion for the plugins and widgets of questionable licence is
> to do as Scott suggests and start a separate google
> code/sourceforge/whatever repository to house incompatibly licensed
> plugins (which are actually plugins for containers rather than for
> Wookie - the name is confusing) and widgets.
>
> Lets call it wookie-extras
>
> Committers on Wookie should be given commit on wookie-extras too, but
> committers on wookie-extras do not automatically get commit on wookie.
> we can have a lower barrier to commit on wookie-extras and treat it as
> a kind of incubating site for widgets.
>
> Ross
Re: A few more IP issues and code preparation
Posted by Ross Gardler <rg...@apache.org>.
2009/7/21 Scott Wilson <sc...@gmail.com>:
>
> On 21 Jul 2009, at 22:20, Ross Gardler wrote:
>
>> Whilst we are waiting for the relevant legal documents to be filed
>> perhaps the Wookie team would like to prepare the code for import.
>>
>> There are four incompatibly licensed dependencies (assuming the notice
>> file is up to date):
>>
>> c3p0
>> Java Transactions API
>> MySQL Connector
>> Hibernate
>>
>> These cannot be brought in to ASF infrastructure and thus must be
>> removed from the repository and build instructions updated
>> accordingly. We'll have to replace these dependencies during
>> incubation. I note that during the proposal stage Scott mentioned that
>> moving to CouchDB might make sense. we can explore this once the
>> initial code import is complete.
>
> Removing Hibernate+MySQL+c3p0+JTA will require a bit of a rethink on the ORM
> front - maybe we can use OpenJPA, or just get rid of ORM and use plain JDBC
> & SQL. CouchDB could be interesting for the actual widget instance
> preference and state data.
>
> However its a fair chunk of work removing these dependencies - is it best if
> we fix these outside the incubator and then move the code when its working,
> or submit the code as-is but with just the libraries and build info removed
> (i.e., not working) and then fix it in the incubator?
The problem is not that your code depends on them, it is that because
of the licence incompatibilities we cannot distribute from ASF
infrastructure. So there is no need to break things completely. I
recommend:
- Remove the libs.
- Add a step to the build instructions saying the libs need to be
manually downloaded and placed in the lib directory
- make build.xml check for their existence and failing with a sensible message
This means that anyone building Wookie will be aware that there are
licence incompatibilities and must act accordingly if they
redistribute. In other words, there are no hidden surprises in our
distribution.
>> Since my initial evaluation of the code I have identified a few other
>> potential conflicts:
>>
>> I am unsure of our ability to Apache License the Moodle, Elgg and
>> Wordpress plugins since each of these containers is GPL and I have no
>> idea if the viral nature of the GPL is invoked by these plugins. It is
>> a contentious issue. The FSF general claim that modules are "touched"
>> by the GPL whereas Linux says they are not (and I'd suggest that Linux
>> Kernel modules are closer to the GPL code than a typical Moodle plugin
>> for example).
>
> I think its a reasonable question to ask whether the Apache Wookie project
> should include the plugins, or just the engine. If not the plugins could be
> handled outside in a separate project, or (my preference, but difficult in
> practice) they can be taken on by the container projects themselves.
The rails one can certainly come into the ASF and would act as an
example. I'd like to see a project socialsite and/or Wicket and/or
roller plugin developed pretty quickly as examples. I'll return to the
other plugins at the end of this mail.
>> I also note that there is some code from Apple which is not under a
>> licence I am familiar with. See
>>
>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/shared/mac-resources/WidgetResources/AppleClasses/AppleAnimator.js?revision=1.1&view=markup
>>
>> I'm also not sure about the widgets in
>>
>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/widgets/
>> I'm pretty sure the code for (at least some of) these come from the
>> Google Wave project, what licence are they under and do they contain
>> any code from other third parties.
>
> The Apple files included in shared/mac-resources can be removed - this was a
> convenience for when running converted Apple Dashboard during early testing,
> but isn't appropriate for inclusion now.
OK. That's a simple solution then.
> Looking at the Widgets in the /widgets folder:
>
> * WookieWiki.wgt uses Creole.js, which uses an MIT-style license.
MIT is fine - but you may need to add an entry to the NOTICE file.
> * Sudoku.wgt uses some Google JS code which has no identifiable license.
Assuming this is the code from the wave API samples I'd suggest a mail
to the API group asking them to clarify the license situation. Almost
certainly they will put it under a permissive licence since it is
sample code.
http://groups.google.com/group/google-wave-api
Can you, or one of the committers please follow this up.
> * WaveWord.wgt uses some code from
> http://www.themaninblue.com/experiment/SSCrabble/ of indeterminate license,
> and JQuery which is dual MIT and GPL.
JQuery is fine as we can take it under MIT.
The other code is a concern for two reasons. The first is that there
is no clear licence, this can probably be resolved with a quick email.
However, there is every possibility that the code infringes on Mattel
trademarks.
It may be better to leave this widget in another location, see end of this mail.
> * Test.wgt doesn't use any outside code (its for testing API compliance with
> specs).
>
> * YouDecide.wgt doesn't use any outside code.
Good.
> Inside the /WebContent/wservices folder are widgets included in a default
> build:
>
> * Natter uses some Apple code; this can be removed as its just chrome.
> JQuery again. And the smileys are actually Skype emoticons under the Skype
> Component license:
> https://developer.skype.com/Download/SkypeEmoticons however I think these
> actually aren't being used under the license appropriately and would need to
> be replaced with some genuinely open emoticon images. If anyone knows of any
> this would be very handy!
I often use http://www.famfamfam.com/lab/icons/silk/ for icons, I'm
pretty sure there are some emoticons in there to. CC-BY-SA licence
> None of the other widgets (weather, vote, chat, forum) use any external
> code.
Excellent.
>> I'd like to hear the thoughts of the mentors on handling these issues.
>> I'd also appreciate it if mentors can look over the code to see if
>> there are any items I've missed (note the lib files are in an unusual
>> place:
>> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/WEB-INF/lib/
>> )
My suggestion for the plugins and widgets of questionable licence is
to do as Scott suggests and start a separate google
code/sourceforge/whatever repository to house incompatibly licensed
plugins (which are actually plugins for containers rather than for
Wookie - the name is confusing) and widgets.
Lets call it wookie-extras
Committers on Wookie should be given commit on wookie-extras too, but
committers on wookie-extras do not automatically get commit on wookie.
we can have a lower barrier to commit on wookie-extras and treat it as
a kind of incubating site for widgets.
Ross
Re: A few more IP issues and code preparation
Posted by Scott Wilson <sc...@gmail.com>.
On 21 Jul 2009, at 22:20, Ross Gardler wrote:
> Whilst we are waiting for the relevant legal documents to be filed
> perhaps the Wookie team would like to prepare the code for import.
>
> There are four incompatibly licensed dependencies (assuming the notice
> file is up to date):
>
> c3p0
> Java Transactions API
> MySQL Connector
> Hibernate
>
> These cannot be brought in to ASF infrastructure and thus must be
> removed from the repository and build instructions updated
> accordingly. We'll have to replace these dependencies during
> incubation. I note that during the proposal stage Scott mentioned that
> moving to CouchDB might make sense. we can explore this once the
> initial code import is complete.
Removing Hibernate+MySQL+c3p0+JTA will require a bit of a rethink on
the ORM front - maybe we can use OpenJPA, or just get rid of ORM and
use plain JDBC & SQL. CouchDB could be interesting for the actual
widget instance preference and state data.
However its a fair chunk of work removing these dependencies - is it
best if we fix these outside the incubator and then move the code when
its working, or submit the code as-is but with just the libraries and
build info removed (i.e., not working) and then fix it in the incubator?
>
> Since my initial evaluation of the code I have identified a few other
> potential conflicts:
>
> I am unsure of our ability to Apache License the Moodle, Elgg and
> Wordpress plugins since each of these containers is GPL and I have no
> idea if the viral nature of the GPL is invoked by these plugins. It is
> a contentious issue. The FSF general claim that modules are "touched"
> by the GPL whereas Linux says they are not (and I'd suggest that Linux
> Kernel modules are closer to the GPL code than a typical Moodle plugin
> for example).
I think its a reasonable question to ask whether the Apache Wookie
project should include the plugins, or just the engine. If not the
plugins could be handled outside in a separate project, or (my
preference, but difficult in practice) they can be taken on by the
container projects themselves.
> I also note that there is some code from Apple which is not under a
> licence I am familiar with. See
> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/shared/mac-resources/WidgetResources/AppleClasses/AppleAnimator.js?revision=1.1&view=markup
>
> I'm also not sure about the widgets in
> http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/widgets/
> I'm pretty sure the code for (at least some of) these come from the
> Google Wave project, what licence are they under and do they contain
> any code from other third parties.
The Apple files included in shared/mac-resources can be removed - this
was a convenience for when running converted Apple Dashboard during
early testing, but isn't appropriate for inclusion now.
Looking at the Widgets in the /widgets folder:
* WookieWiki.wgt uses Creole.js, which uses an MIT-style license.
* Sudoku.wgt uses some Google JS code which has no identifiable license.
* WaveWord.wgt uses some code from http://www.themaninblue.com/experiment/SSCrabble/
of indeterminate license, and JQuery which is dual MIT and GPL.
* Test.wgt doesn't use any outside code (its for testing API
compliance with specs).
* YouDecide.wgt doesn't use any outside code.
Inside the /WebContent/wservices folder are widgets included in a
default build:
* Natter uses some Apple code; this can be removed as its just chrome.
JQuery again. And the smileys are actually Skype emoticons under the
Skype Component license: https://developer.skype.com/Download/SkypeEmoticons
however I think these actually aren't being used under the license
appropriately and would need to be replaced with some genuinely open
emoticon images. If anyone knows of any this would be very handy!
None of the other widgets (weather, vote, chat, forum) use any
external code.
>
> I'd like to hear the thoughts of the mentors on handling these issues.
> I'd also appreciate it if mentors can look over the code to see if
> there are any items I've missed (note the lib files are in an unusual
> place: http://tencompetence.cvs.sourceforge.net/viewvc/tencompetence/wp6/org.tencompetence.widgetservice/WebContent/WEB-INF/lib/
> )
>
> Finally, one for the committers may like to prepare the codebase for
> importation into the repository. Other than the above IP issues the
> packages will need to be renamed org.apache.wookie.*
OK, we'll get on it
>
> Ross
>
>
> --
> Ross Gardler
>
> OSS Watch - supporting open source in education and research
> http://www.oss-watch.ac.uk