You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Demetrios Kyriakis <de...@googlemail.com> on 2007/11/03 17:26:58 UTC

DataViews - Proposal - move to sourceforge!

Hi,

Since the Cayenne team is not very interested in DataViews, but many users
are, the most simple solution to me looks to move DataViews to a place where
users can contribute much easier.

Because of it's "patch" based contribution restriction, and especially of
the long list of incompatible "licenses", I'm not sure if Apache.org is the
best place to get help from users with as few as possible "barriers".

Also an important step would be to switch the license from Apache to LGPL.
It seems that the Apache license is not too GUI friendly: just looks how few
projects on Apache.org have GUI's and how many good GUI oriented libraries
or tools are LGPL.

Any other ideas on what could be done to re-invigorate DataViews?

Thank you,

Demetrios.
-- 
View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13564433
Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Demetrios Kyriakis <de...@googlemail.com>.

Aristedes Maniatis-2 wrote:
> 
>> Also an important step would be to switch the license from Apache  
>> to LGPL.
>> It seems that the Apache license is not too GUI friendly: just  
>> looks how few
>> projects on Apache.org have GUI's and how many good GUI oriented  
>> libraries
>> or tools are LGPL.
> ... you could still keep the Apache  
> license on the core code. The restriction for including GPL code is  
> all about code released by Apache: that is, code which is part of an  
> official release. 
> 
Now thats a very very good point.

Maybe many problems could be simply solved by having "unofficial releases"
(and servers).
E.g. for some projects where LGPL code would be required, to simply have
"officialy" only the "src" release, and the "binary" (with the LGPL jars in
the packege) to be "unofficial" (but still available so that not to force
every user to build).

Thank you,

Demetrios.
-- 
View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13572628
Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 04/11/2007, at 3:26 AM, Demetrios Kyriakis wrote:

> Also an important step would be to switch the license from Apache  
> to LGPL.
> It seems that the Apache license is not too GUI friendly: just  
> looks how few
> projects on Apache.org have GUI's and how many good GUI oriented  
> libraries
> or tools are LGPL.

Even if you were to fork the project, you could still keep the Apache  
license on the core code. The restriction for including GPL code is  
all about code released by Apache: that is, code which is part of an  
official release. There is no such problem with code distributed  
through sourceforge or anywhere else. So, by keeping the Apache  
license on anything you add, the project still has the possibility of  
being re-included in a core Cayenne release in the future (if the GPL/ 
LGPL parts can be replaced with something equivalent).

Ari Maniatis


-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8



Re: DataViews - Proposal - move to sourceforge!

Posted by Demetrios Kyriakis <de...@googlemail.com>.

Andrus Adamchik wrote:
> 
> Have you actually read all the replies in this thread?
> 
Sure I did. I can't type so quickly to reply to all instantly - so I was
taking them in order (except this ) :).

Demetrios.
-- 
View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13572460
Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Andrus Adamchik <an...@objectstyle.org>.
Have you actually read all the replies in this thread?

Andrus


On Nov 4, 2007, at 1:48 PM, Demetrios Kyriakis wrote:

>
>
> Mike Kienenberger wrote:
>>
>> There's nothing stopping you from forking a branch of DataViews.
>>
> Well, as I mentioned in the subject, I asked/proposed about a  
> *move* not
> fork and of couse this "as official as possible" :).
> Personally I'm not interested in "forking" - I think there's not  
> enough
> "developer free energy" around to invest in forks, and for sure not  
> for
> "political" resons like licensing :).
>
> My request was based on a very simple and pragmatic reason - on  
> sourceforge
> it takes only a single click to give someone commit rights - it's even
> simpler than explaining "house rules" or whatever bureacratic steps  
> Apache
> takes.
>
>
> Mike Kienenberger wrote:
>>
>> However, you cannot change the license to LGPL.
>>
> Wow thank you for the info. I didn't know that Apache license is so
> restrictive.
> I think that LGPL code can be changed by the owners to whatever  
> license they
> wish (if they wish).
> I think I saw this on some dev.java.net forum - Sun.com has LGPL  
> for most
> code there, but they can change it to what they want and when they  
> want.
>
>
> Thank you,
>
> Demetrios.
> -- 
> View this message in context: http://www.nabble.com/DataViews--- 
> Proposal---move-to-sourceforge%21-tf4743504.html#a13571863
> Sent from the Cayenne - Dev mailing list archive at Nabble.com.
>
>


Re: DataViews - Proposal - move to sourceforge!

Posted by Craig L Russell <Cr...@Sun.COM>.
This discussion has gone into legal affairs and sadly, I'm afraid  
that the local wisdom (meself included) is not sufficient to give a  
complete description of what it means to fork an Apache project and  
relicense it as GPL or LGPL. The Apache license is very permissive,  
and relicensing Apache code is permitted.

I respectfully suggest that this thread discontinue here and  
reconvene at

legal-discuss@apache.org

Craig

On Nov 4, 2007, at 12:42 PM, Mike Kienenberger wrote:

>> Mike Kienenberger wrote:
>>> However, you cannot change the license to LGPL.
>
> On 11/4/07, Demetrios Kyriakis <de...@googlemail.com>  
> wrote:
>> Wow thank you for the info. I didn't know that Apache license is so
>> restrictive.
>> I think that LGPL code can be changed by the owners to whatever  
>> license they
>> wish (if they wish).
>> I think I saw this on some dev.java.net forum - Sun.com has LGPL  
>> for most
>> code there, but they can change it to what they want and when they  
>> want.
>
> And the Cayenne code at ASF can be changed by the code owners to
> whatever license they wish if they wish as well.   It has nothing to
> do with Apache.
>
> However, trying to get approval from every owner for the code they
> contributed is next to impossible in any large open source community.
>  If you want, feel free to give it a try.
>
> However, the code that ASF has rights to and maintains must remain
> under the Apache license as that's the license under which the code
> was granted to ASF.   Neither ASF nor people operating on ASF's
> behalf, can give you an LGPL license for Dataviews.   You'll have to
> contact every person who contributed to DataViews to obtain it.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Re: DataViews - Proposal - move to sourceforge!

Posted by Mike Kienenberger <mk...@gmail.com>.
> Mike Kienenberger wrote:
> > However, you cannot change the license to LGPL.

On 11/4/07, Demetrios Kyriakis <de...@googlemail.com> wrote:
> Wow thank you for the info. I didn't know that Apache license is so
> restrictive.
> I think that LGPL code can be changed by the owners to whatever license they
> wish (if they wish).
> I think I saw this on some dev.java.net forum - Sun.com has LGPL for most
> code there, but they can change it to what they want and when they want.

And the Cayenne code at ASF can be changed by the code owners to
whatever license they wish if they wish as well.   It has nothing to
do with Apache.

However, trying to get approval from every owner for the code they
contributed is next to impossible in any large open source community.
 If you want, feel free to give it a try.

However, the code that ASF has rights to and maintains must remain
under the Apache license as that's the license under which the code
was granted to ASF.   Neither ASF nor people operating on ASF's
behalf, can give you an LGPL license for Dataviews.   You'll have to
contact every person who contributed to DataViews to obtain it.

Re: DataViews - Proposal - move to sourceforge!

Posted by Demetrios Kyriakis <de...@googlemail.com>.

Mike Kienenberger wrote:
> 
> There's nothing stopping you from forking a branch of DataViews.
> 
Well, as I mentioned in the subject, I asked/proposed about a *move* not
fork and of couse this "as official as possible" :).
Personally I'm not interested in "forking" - I think there's not enough
"developer free energy" around to invest in forks, and for sure not for
"political" resons like licensing :).

My request was based on a very simple and pragmatic reason - on sourceforge
it takes only a single click to give someone commit rights - it's even
simpler than explaining "house rules" or whatever bureacratic steps Apache
takes.


Mike Kienenberger wrote:
> 
> However, you cannot change the license to LGPL.
> 
Wow thank you for the info. I didn't know that Apache license is so
restrictive.
I think that LGPL code can be changed by the owners to whatever license they
wish (if they wish).
I think I saw this on some dev.java.net forum - Sun.com has LGPL for most
code there, but they can change it to what they want and when they want.


Thank you,

Demetrios.
-- 
View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13571863
Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Craig L Russell <Cr...@Sun.COM>.
If the reason people want to fork is the license, there's not much  
that Apache can do. Projects built at Apache are released with the  
Apache license.

But if the reason is to build a community and there is too high a  
barrier in established Apache projects for committers to become  
productive, this can be solved easily enough. Find the folks who are  
interested and bring them into the incubator along with the dataviews  
code. They can become committers immediately and start working on the  
code in the incubator. When the project is ready for graduation,  
those people who have contributed positively will be easy to  
identify, and presumably they will have earned commit privileges in  
the project they graduate to.

Craig

On Nov 3, 2007, at 11:28 AM, Andrus Adamchik wrote:

> Actually we had a similar discussion some time ago, and also  
> related to DataViews. Forking and relicensing is an easy option:
>
>    http://objectstyle.org/cayenne/lists/cayenne-devel/ 
> 2007/04/0035.html
>
> Whoever wants to work on a fork, I suggest you contact Adrian  
> Wiesmann (who is likely reading this list). I think he already did  
> a fork and placed it on SourceForge (?)
>
> I disagree that Apache license as such is unfriendly to GUI  
> projects (at least I haven't heard any reasonable argument to back  
> that idea), but the fact that most existing libraries converged  
> around (L)GPL could definitely play its role as a high barrier to  
> entry. Although there are notable exceptions - JGoodies uses BSD  
> license.
>
> Finally I have no idea why people are so afraid to contribute to  
> Apache. There are no barriers, except for the ones that any  
> established project would have, namely that the people involved in  
> the project value their reputation built over the years, and  
> therefore require new contributors to go through the karma building  
> process, before giving them write access. I think that's very  
> reasonable.
>
> Andrus
>
>
> On Nov 3, 2007, at 7:23 PM, Mike Kienenberger wrote:
>
>> There's nothing stopping you from forking a branch of DataViews.
>>
>> However, you cannot change the license to LGPL.
>>
>> On 11/3/07, Demetrios Kyriakis <de...@googlemail.com>  
>> wrote:
>>>
>>> Hi,
>>>
>>> Since the Cayenne team is not very interested in DataViews, but  
>>> many users
>>> are, the most simple solution to me looks to move DataViews to a  
>>> place where
>>> users can contribute much easier.
>>>
>>> Because of it's "patch" based contribution restriction, and  
>>> especially of
>>> the long list of incompatible "licenses", I'm not sure if  
>>> Apache.org is the
>>> best place to get help from users with as few as possible  
>>> "barriers".
>>>
>>> Also an important step would be to switch the license from Apache  
>>> to LGPL.
>>> It seems that the Apache license is not too GUI friendly: just  
>>> looks how few
>>> projects on Apache.org have GUI's and how many good GUI oriented  
>>> libraries
>>> or tools are LGPL.
>>>
>>> Any other ideas on what could be done to re-invigorate DataViews?
>>>
>>> Thank you,
>>>
>>> Demetrios.
>>> --
>>> View this message in context: http://www.nabble.com/DataViews--- 
>>> Proposal---move-to-sourceforge%21-tf4743504.html#a13564433
>>> Sent from the Cayenne - Dev mailing list archive at Nabble.com.
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Re: DataViews - Proposal - move to sourceforge!

Posted by Adrian Wiesmann <aw...@somap.org>.
> > Whoever wants to work on a fork, I suggest you contact Adrian  
> > Wiesmann (who is likely reading this list). I think he already did a  
> > fork and placed it on SourceForge (?)
> > 
> Well, as I mentioned, I'm not interested in "forking" but "moving" :).
> I saw Adrian's work - it's not a standalone SF project, but part of some
> other one, and as you
> say - it's a *fork* :).

Here I am :)

To clear a few things up:

- I wanted to be as "official" as possible when I started to work on the
DataViews. Unfortunately nobody was interested to help out back then, so I
went the way which required the least effort from my side -> add to
existing project.

- While "our" DataViews are managed in another project (somap.org), the
licence was not changed and it would still be possible to create a single
JAR from the current version. We did *no assimilation*, we did a move (and
some changes so that the source compiles without the need of having to be
compiled within Cayenne -> private classes etc).

- Talking about licences. Go GPL3 and that should be compatible with
the ASL 2.x.

And last but not least. If anybody is really (I mean REALLY) interested in
working on DataViews, please drop me a note and we will have some chat
about where to head to with DataViews[1]. I am currently working on Gozer
which I see as the "natural evolution" of DataViews. Gozer is about UI,
DataBinding and EventHandling based on Cayenne and is planned to run with
Swing and Click.

Regards,
Adrian

[1] IMHO DataViews lack some functionality. One of which is lack of
support for Swing components like fields and labels.

Re: DataViews - Proposal - move to sourceforge!

Posted by Mike Kienenberger <mk...@gmail.com>.
On 11/4/07, Demetrios Kyriakis <de...@googlemail.com> wrote:
> if you want a tool
> or GUI use LGLP, if you want
> a general library than use BSD or Apache". I got no explanation why is that
> so (beyond "lawyers found this as the best combination"), but it seems that
> developers apply it :).

My opinion:  because people doing commercial work rarely extend a GUI
or tool, but people doing commercial work use libraries all the time.
 LGPL's viral nature is rarely conducive to commercial work, where the
companies you are working for will not give away for free the
application that they paid you to write just because you use a viral
library.   Most companies have no issues giving away common library
code, but they're not going to give away the applications that they
pay their programmers to build on top of that library code.


> #4 - on SF unlike Apache.org most people spend no time on licensing
> discussions (nor really do they care)

SF projects, unlike Apache.org projects, disregard licensing
restrictions because following the licensing rules is rarely fun.
While you and others have opinions on what LGPL means when applied to
java code linkage, you have no legal basis for holding such an
opinion.   ASF, on the other hand, employs attorneys who do have the
legal basis for determining what the LGPL  java linkage licenses mean
and who have discussed the matter with FSF attorneys.  Since ASF can
legally be held responsible for breaking such a license, ASF takes
licensing quite seriously.    ASF has financial assets.   It's
unlikely that YourGUIToolApp developers have any assets worth
pursuing.   But if your YourGUIToolApp ever becomes valuable enough,
then it might be a different story.


Note that I am not an attorney.   Nor do I have anything other than
opinions (without legal basis) on the subject of licenses.   If you
want to discuss it with people who do, use the talk-legal mailing list
at apache.  You and I can debate it, but it won't accomplish anything.
  All we can say is that we follow the Apache rules at Apache Cayenne,
and give you pointers to what those rules are.   There's nothing
useful accomplished by talking about how you wish the rules were
different on our mailing lists -- use the legal mailing lists.

Re: DataViews - Proposal - move to sourceforge!

Posted by Kevin Menard <km...@servprise.com>.
On 11/4/07 8:33 AM, "Demetrios Kyriakis" <de...@googlemail.com>
wrote:

>> 
> Well I can give you a few reasons, but I suppose "true Apache believers"
> will dismiss them and will consider "flame" :). This is not my intention,
> but to give you another point of view - that of *your users*.

The only thing that is a flame is this preceding paragraph.  You would have
done well to omit it.


> #1 - most people do open source work in their free time, and this for fun
> and only as long as it makes fun.
> (Well there might be exceptions - maybe on Apache.org there are more
> "employees" doing open source work in their "work time" than somewhere
> else).

For me, fun is getting something working.  It is rewarding when something
gets accepted, but I can have fun otherwise.  So, to each his own on this
one I guess.

> #2 - submitting patches to an issue tracking system is no fun.
> There's no direct feedback, there's no "instant gratification", and for sure
> it does not compare with a simply making a quick check in and getting
> feedback for your changes.

Once again, getting it working locally should be instant gratification.  You
do have to realize that any commit affects a large number of people.
Additionally, the developers do not have the resources to do a full code
review of every commit.  We try to stay on top of things to keep each other
in check, but there's a general sense of peer respect in that we trust what
each other is committing.  If there are doubts on anything, a discussion
typically takes place on the developer list beforehand and any submissions
are given more consideration at that point.

What you are suggesting would lead to chaos.

Having said that, I've been a long time fan of using a distributed version
control system so that users looking to contribute could still use an SCM
tool.  When Cayenne was hosted on ObjectStyle and I didn't have commit
access yet, I even mirrored a darcs repository.  That may be a good option
for you as well (check out the tailor project).

> #2.1 - in many Apache projects, issues (with patches but with simple code
> snippets too) take months to get into the code - if they ever get. A simple
> browse of the Apache JIRA shows this state: there are even a few projects
> where this takes years :) - Velocity, JAMES, Commons VFS - just to mention a
> few (and your users know them even if they don't express their frustration
> with that state).

We are not any of those projects and thus we cannot comment on them, nor are
the criticisms applicable to us.  If you have an issue with a patch attached
to a JIRA issue not being applied, please bring it up in a separate thread.

> #3 - getting commit rights is waaaay too complicated on Apache.org - on
> sourceforge it takes only one click :). If it's not OK what that developer
> does, the rights can be revoked anytime, and the code rollbacked - nobody
> gets upset and nobody is loosing time - the time frame where the contributor
> is in "fun state" is kept :).

There's a difference between the political and the technical ways of getting
commit access.  I suppose technically there is a bit more work, as an infra
request needs to be set up.  Yeah, a bit more overhead, but honestly, I'm
glad to have a direct conduit to the guys running the repo.  I've never seen
the reliability problems that SF has with its repo.

>From a political perspective, there's really nothing stopping us from
handing out commit rights on a whim.  We don't want to, however, and that
wouldn't change if we were on SF.

> #4 - on SF unlike Apache.org most people spend no time on licensing
> discussions (nor really do they care) or voting with the most strange voting
> ever invented: "veto" for everybody :) :) :). (on Apache JAMES this veto
> this leads to constant blocking in the last 3 years, and on other projects
> to always choose the "least common denominator", or developers being
> Ueber-cautious - this simply kills creativity, and 100% kills fun :) ).

Unfortunately, this is true.  It creates a lot of headaches for a lot of
people, however.  Categorically incorrect licensing is used and it creates
problems for end users.  That's one of the nice things about the ASF
projects -- a guarantee that the code you get can essentially be used any
way you like.


I think it's clear what the options really are:

1) Fork the code and take it to SF.  I know you don't want to fork, but the
current devs are not going to move the project.  Of course, we're not really
doing anything with it either, so there's opportunity for your fork to
succeed.

2) If it really boils down to commit privs, I think Craig is on the right
track.  A proposal for a subproject incubator could be made.

3) If it really boils down to SCM tools, leave things as are and set up a
mercurial/darcs/bzr/whatever mirror and use that to develop against.


And with that, I'm removing myself from the thread unless something new is
added.  It seems like the hide is gone off this dead horse.

-- 
Kevin



Re: DataViews - Proposal - move to sourceforge!

Posted by Demetrios Kyriakis <de...@googlemail.com>.

Andrus Adamchik wrote:
> 
> Actually we had a similar discussion some time ago, and also related  
> to DataViews. Forking and relicensing is an easy option:
> 
>     http://objectstyle.org/cayenne/lists/cayenne-devel/2007/04/0035.html
> 
> Whoever wants to work on a fork, I suggest you contact Adrian  
> Wiesmann (who is likely reading this list). I think he already did a  
> fork and placed it on SourceForge (?)
> 
Well, as I mentioned, I'm not interested in "forking" but "moving" :).
I saw Adrian's work - it's not a standalone SF project, but part of some
other one, and as you
say - it's a *fork* :).


Andrus Adamchik wrote:
> 
> I disagree that Apache license as such is unfriendly to GUI projects  
> (at least I haven't heard any reasonable argument to back that idea),  
> but the fact that most existing libraries converged around (L)GPL  
> could definitely play its role as a high barrier to entry. Although  
> there are notable exceptions - JGoodies uses BSD license.
> 
Yes, sure - the exception that confirms the rule :).
The thumb rule I heard on many JUGs(and forums) is that "if you want a tool
or GUI use LGLP, if you want
a general library than use BSD or Apache". I got no explanation why is that
so (beyond "lawyers found this as the best combination"), but it seems that
developers apply it :).


Andrus Adamchik wrote:
> 
> Finally I have no idea why people are so afraid to contribute to  
> Apache. There are no barriers, except for the ones that any  
> established project would have, namely that the people involved in  
> the project value their reputation built over the years, and  
> therefore require new contributors to go through the karma building  
> process, before giving them write access. I think that's very  
> reasonable.
> 
Well I can give you a few reasons, but I suppose "true Apache believers"
will dismiss them and will consider "flame" :). This is not my intention,
but to give you another point of view - that of *your users*.

#1 - most people do open source work in their free time, and this for fun
and only as long as it makes fun.
(Well there might be exceptions - maybe on Apache.org there are more
"employees" doing open source work in their "work time" than somewhere
else).
#2 - submitting patches to an issue tracking system is no fun.
There's no direct feedback, there's no "instant gratification", and for sure
it does not compare with a simply making a quick check in and getting
feedback for your changes.
#2.1 - in many Apache projects, issues (with patches but with simple code
snippets too) take months to get into the code - if they ever get. A simple
browse of the Apache JIRA shows this state: there are even a few projects
where this takes years :) - Velocity, JAMES, Commons VFS - just to mention a
few (and your users know them even if they don't express their frustration
with that state).
#3 - getting commit rights is waaaay too complicated on Apache.org - on
sourceforge it takes only one click :). If it's not OK what that developer
does, the rights can be revoked anytime, and the code rollbacked - nobody
gets upset and nobody is loosing time - the time frame where the contributor
is in "fun state" is kept :).
#4 - on SF unlike Apache.org most people spend no time on licensing
discussions (nor really do they care) or voting with the most strange voting
ever invented: "veto" for everybody :) :) :). (on Apache JAMES this veto
this leads to constant blocking in the last 3 years, and on other projects
to always choose the "least common denominator", or developers being
Ueber-cautious - this simply kills creativity, and 100% kills fun :) ).

I hope, you don't take this as a flame but as an insight in the perspective
of your users trying to help.

Thank you,

Demetrios.
-- 
View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13572442
Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually we had a similar discussion some time ago, and also related  
to DataViews. Forking and relicensing is an easy option:

    http://objectstyle.org/cayenne/lists/cayenne-devel/2007/04/0035.html

Whoever wants to work on a fork, I suggest you contact Adrian  
Wiesmann (who is likely reading this list). I think he already did a  
fork and placed it on SourceForge (?)

I disagree that Apache license as such is unfriendly to GUI projects  
(at least I haven't heard any reasonable argument to back that idea),  
but the fact that most existing libraries converged around (L)GPL  
could definitely play its role as a high barrier to entry. Although  
there are notable exceptions - JGoodies uses BSD license.

Finally I have no idea why people are so afraid to contribute to  
Apache. There are no barriers, except for the ones that any  
established project would have, namely that the people involved in  
the project value their reputation built over the years, and  
therefore require new contributors to go through the karma building  
process, before giving them write access. I think that's very  
reasonable.

Andrus


On Nov 3, 2007, at 7:23 PM, Mike Kienenberger wrote:

> There's nothing stopping you from forking a branch of DataViews.
>
> However, you cannot change the license to LGPL.
>
> On 11/3/07, Demetrios Kyriakis <de...@googlemail.com>  
> wrote:
>>
>> Hi,
>>
>> Since the Cayenne team is not very interested in DataViews, but  
>> many users
>> are, the most simple solution to me looks to move DataViews to a  
>> place where
>> users can contribute much easier.
>>
>> Because of it's "patch" based contribution restriction, and  
>> especially of
>> the long list of incompatible "licenses", I'm not sure if  
>> Apache.org is the
>> best place to get help from users with as few as possible "barriers".
>>
>> Also an important step would be to switch the license from Apache  
>> to LGPL.
>> It seems that the Apache license is not too GUI friendly: just  
>> looks how few
>> projects on Apache.org have GUI's and how many good GUI oriented  
>> libraries
>> or tools are LGPL.
>>
>> Any other ideas on what could be done to re-invigorate DataViews?
>>
>> Thank you,
>>
>> Demetrios.
>> --
>> View this message in context: http://www.nabble.com/DataViews--- 
>> Proposal---move-to-sourceforge%21-tf4743504.html#a13564433
>> Sent from the Cayenne - Dev mailing list archive at Nabble.com.


Re: DataViews - Proposal - move to sourceforge!

Posted by Mike Kienenberger <mk...@gmail.com>.
There's nothing stopping you from forking a branch of DataViews.

However, you cannot change the license to LGPL.

On 11/3/07, Demetrios Kyriakis <de...@googlemail.com> wrote:
>
> Hi,
>
> Since the Cayenne team is not very interested in DataViews, but many users
> are, the most simple solution to me looks to move DataViews to a place where
> users can contribute much easier.
>
> Because of it's "patch" based contribution restriction, and especially of
> the long list of incompatible "licenses", I'm not sure if Apache.org is the
> best place to get help from users with as few as possible "barriers".
>
> Also an important step would be to switch the license from Apache to LGPL.
> It seems that the Apache license is not too GUI friendly: just looks how few
> projects on Apache.org have GUI's and how many good GUI oriented libraries
> or tools are LGPL.
>
> Any other ideas on what could be done to re-invigorate DataViews?
>
> Thank you,
>
> Demetrios.
> --
> View this message in context: http://www.nabble.com/DataViews---Proposal---move-to-sourceforge%21-tf4743504.html#a13564433
> Sent from the Cayenne - Dev mailing list archive at Nabble.com.
>
>

Re: DataViews - Proposal - move to sourceforge!

Posted by Ahmed Mohombe <am...@yahoo.com>.
> Since the Cayenne team is not very interested in DataViews, but many users
> are, the most simple solution to me looks to move DataViews to a place where
> users can contribute much easier.
> 
> Because of it's "patch" based contribution restriction, and especially of
> the long list of incompatible "licenses", I'm not sure if Apache.org is the
> best place to get help from users with as few as possible "barriers".
Sourceforge is a good place for this however the issue tracking, the forums and the wiki are 
horrible (but one can use them from somewhere else).

> Also an important step would be to switch the license from Apache to LGPL.
> It seems that the Apache license is not too GUI friendly: just looks how few
> projects on Apache.org have GUI's and how many good GUI oriented libraries
> or tools are LGPL.
I don't think this is required. As Aristedes mentioned too, the incompatibility
between Apache license and LGPL is in the "distribution" by Apache.org.
On SF there are no such restrictions - there are many projects there that have
Apache license but have dependencies on (L)GPL code.

> Any other ideas on what could be done to re-invigorate DataViews?
1. Improve Dataviews
1.1. IMHO extending the purpose of the project would be a great idea, i.e. making
DataViews independent from Swing (or not just Swing only).

This way DataViews could be only a DSL (domain specific language) for Rich Data oriented UIs,
with several implementations:
- the actual one with Swing UIs
- several web based implementations (rich data oriented UIs are required there too).
(I have an older proof of concept based on Struts 1.1) and would gladly submit
a Click Framework (http://click.sourceforge.net/) based one (it's based on a very
old Click version but I could update that too).

1.2. Extend the Swing implementation to support JGoodies Binding and Validation.

2. Improving DVModeler would be even more important. What makes Cayenne great is CM (the
productivity gained with it and the low level entry barrier) - this should be true for any
other technology.

IMHO with 1.1 more users would be attracted to DataViews since there are many web frameworks, and 2. 
  would convince users (with the help of a small video/screencast) to give DataViews a try.

Ahmed.