Menu
▾
▴
opensync-users
|
From: Armin B. <arm...@de...> - 2005-07-08 19:46:15
Attachments:
signature.asc
|
Hi, i just finished setting up the libsyncml project space at http://libsyncml.opensync.org. If you are interested at the project or maybe even like to help, go take a look :) All support is always welcome. And i also got the libsyncml project at sf.net donated by Max. Thanks for this. The initial code for the syncml plugin is now also hosted at the opensync project at svn.opensync.org/plugins/syncml/ so the syncml is definetly getting closer! Armin |
|
From: Dan M. <dm...@mo...> - 2005-07-12 01:21:46
|
Armin Bauer wrote: > Hi, > > i just finished setting up the libsyncml project space at > http://libsyncml.opensync.org. > > If you are interested at the project or maybe even like to help, go take > a look :) All support is always welcome. Very cool. I did notice that libsyncml is GPL, while opensync itself is LGPL. Won't this cause a problem for folks that want to ship opensync itself under the LGPL but not the GPL? Dan |
|
From: Dave H. <dav...@mb...> - 2005-07-12 02:26:01
|
Hi Dan, On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > I did notice that libsyncml is GPL, while opensync itself is > LGPL. Won't this cause a problem for folks that want to ship opensync > itself under the LGPL but not the GPL? There is no problem linking GPL and LGPL code. As long as the documentation is clear, then there will no issue. As both licenses require distribution of the source, it should be clear to anyone working on the code what the deal is. Cheers Dave |
|
From: Hubert F. <hfi...@te...> - 2005-07-12 02:38:08
|
On Tue, 2005-07-12 at 12:24 +1000, Dave Hall wrote: > Hi Dan, > > On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > > I did notice that libsyncml is GPL, while opensync itself is > > LGPL. Won't this cause a problem for folks that want to ship opensync > > itself under the LGPL but not the GPL? > > There is no problem linking GPL and LGPL code. > > As long as the documentation is clear, then there will no issue. As > both licenses require distribution of the source, it should be clear to > anyone working on the code what the deal is. But it can be a problem. For example to be shipped in GNOME, it would have to be a LGPL library, because that is a requirement. Or if you want to write a conduit for OpenSync that link against something that is not GPL compatible. These problems should be understood. Hub -- Crazy French - http://www.figuiere.net/hub/ |
|
From: Dave H. <dav...@mb...> - 2005-07-12 02:56:07
|
Hi Hubert, On Mon, 2005-07-11 at 22:36 -0400, Hubert Figuiere wrote: > On Tue, 2005-07-12 at 12:24 +1000, Dave Hall wrote: > > Hi Dan, > > > > On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > > > I did notice that libsyncml is GPL, while opensync itself is > > > LGPL. Won't this cause a problem for folks that want to ship opensync > > > itself under the LGPL but not the GPL? > > > > There is no problem linking GPL and LGPL code. > > > > As long as the documentation is clear, then there will no issue. As > > both licenses require distribution of the source, it should be clear to > > anyone working on the code what the deal is. > > But it can be a problem. For example to be shipped in GNOME, it would > have to be a LGPL library, because that is a requirement. > Or if you want to write a conduit for OpenSync that link against > something that is not GPL compatible. I spoke to Dan on #calendar on irc.mozilla.org to discuss the what he really meant. There is no issue if you build a conduit which links to non free code, as long as you don't distribute a binary version. You (or anyone else) can build it from source and have no issues. Alternatively you could remove the libsyncml code and distribute a binary version. Either way it is a pita for a vendor of non free software who wants to link to opensync with libsyncml support. I see the point people are making. Sorry for misunderstanding the original question. Cheers Dave |
|
From: Helge H. <hel...@op...> - 2005-07-12 08:00:48
|
On Jul 8, 2005, at 21:45, Armin Bauer wrote: > i just finished setting up the libsyncml project space at > http://libsyncml.opensync.org. Is this library suitable for server side implementations as well or is it focused on clients? > And i also got the libsyncml project at sf.net donated by Max. Thanks > for this. Personally I would be surprised if Max had something against relicensing the code under LGPL if its currently under GPL. I agree with the others that this would be quite important. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org |
|
From: Armin B. <arm...@de...> - 2005-07-12 09:20:25
Attachments:
signature.asc
|
Helge Hess wrote: > On Jul 8, 2005, at 21:45, Armin Bauer wrote: > >> i just finished setting up the libsyncml project space at >> http://libsyncml.opensync.org. > > > Is this library suitable for server side implementations as well or is > it focused on clients? > The library consists of several layers. The lowest layers are the transport like http client, http server, obex client etc The next layer is responisble for parsing the data and dispatching them. The highest layers consists of objects which can be registered with a session at a specific path. At the moment there are: - a authentication object that receives incoming SyncHdrs and authenticates the user if necessary - a devinf object - a syncml Ds server which implements the server part of the ds protocol and which receives commands like alert, sync, map etc - a syncml ds client which implements the client part of ds (not yet implemented) so the library will be usable as both server and client by using different parts of the library >> And i also got the libsyncml project at sf.net donated by Max. Thanks >> for this. > > > Personally I would be surprised if Max had something against relicensing > the code under LGPL if its currently under GPL. > I agree with the others that this would be quite important. > the only thing i used is the libsyncml project space, not the code. So far all code in the libsyncml library is writen by myself. I choose the GPL for a simple reason: I dont want that the library is used for a commercial product without the duty to return something to the community which could either be open sourcing their own code (so that i can be linked against GPL code) or by buying a commercial license. Just out of curiosity, is there anything that would _require_ a LGPL license or is it just that the GPL is too restrictive? > Greets, > Helge |
|
From: Helge H. <hel...@op...> - 2005-07-12 09:31:48
|
On Jul 12, 2005, at 11:20, Armin Bauer wrote: > the only thing i used is the libsyncml project space, not the code. So > far all code in the libsyncml library is writen by myself. OK, I misunderstood that. > I choose the GPL for a simple reason: I dont want that the library is > used for a commercial product without the duty to return something to > the community which could either be open sourcing their own code (so > that i can be linked against GPL code) or by buying a commercial > license. You probably meant proprietary, not commercial. If the proprietary product improves the library itself it needs to deliver the bugfixes and enhancement to that even with LGPL. And increasing the user base for the library is IMHO a good thing (a lot more people can use your library if its LGPL). But its your decision, I suppose you plan to make money with commercial licenses. > Just out of curiosity, is there anything that would _require_ a LGPL > license or is it just that the GPL is too restrictive? Not being able to use the library in a server with a commercial plugin at the same time is certainly quite a big drawback. I would prefer something LGPL to avoid artificial workarounds for that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org |
|
From: Armin B. <arm...@de...> - 2005-07-12 09:52:12
Attachments:
signature.asc
|
Helge Hess wrote: > On Jul 12, 2005, at 11:20, Armin Bauer wrote: > >> the only thing i used is the libsyncml project space, not the code. So >> far all code in the libsyncml library is writen by myself. > > > OK, I misunderstood that. > >> I choose the GPL for a simple reason: I dont want that the library is >> used for a commercial product without the duty to return something to >> the community which could either be open sourcing their own code (so >> that i can be linked against GPL code) or by buying a commercial license. > > > You probably meant proprietary, not commercial. If the proprietary > product improves the library itself it needs to deliver the bugfixes and > enhancement to that even with LGPL. And increasing the user base for the > library is IMHO a good thing (a lot more people can use your library if > its LGPL). Yes i meant propietary of course. > > But its your decision, I suppose you plan to make money with commercial > licenses. Yes, i think it would not be wise not to try. But if money would come in from commercial licenses it would definetly be used for the project (like paying server/bandwidth or buying test equipment etc). So i think the whole GPL vs. LGPL boils down to the question: Which is better for the project? A possible higher userbase with companies using the library which might return something in the future or a maybe lower userbase but a possible source of income for the project? > >> Just out of curiosity, is there anything that would _require_ a LGPL >> license or is it just that the GPL is too restrictive? > > > Not being able to use the library in a server with a commercial plugin > at the same time is certainly quite a big drawback. > I would prefer something LGPL to avoid artificial workarounds for that. > > Greets, > Helge |
|
From: Patrick O. <Pat...@gm...> - 2005-07-18 17:23:14
|
On Tue, 2005-07-12 at 11:20 +0200, Armin Bauer wrote: > Helge Hess wrote: > > Is this library suitable for server side implementations as well or is > > it focused on clients? > > > > The library consists of several layers. [..] > so the library will be usable as both server and client by using > different parts of the library Will it support both slow and fast synchronization? I had considered implementing SyncML client support for Opie a while ago, but the Opie PIM API would not support keeping track of local changes, so each synchronization would have to be done via slow sync and for that the server needs to detect changes. This is not listed in your list above; on the other hand, I am not sure whether this wouldn't belong into the SyncML server on top of the library layers. In that case let me rephrase my question: will OpenSync on top of libsyncml support a slow sync of contact and calender entries? Regarding the Opie SyncML client, your libsyncml is one option. The other, older (more mature?) option is the C++ Sync4j client library (www.sync4j.org). I have not actually used that lib because my initial attempts of just syncing my Sony Ericcson K750 with the Sync4j server failed: http://forge.objectweb.org/tracker/index.php?func=detail&aid=303703&group_id=96&atid=100096 That has dampened my enthusiasm a bit, especially because none of the Sync4j developers has reacted. I hope OpenSync and libsyncml will fare better; please, continue your effort and actually release something that works, it is appreciated ;-) -- Bye, Patrick Ohly -- Pat...@gm... pa...@co... (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) |
|
From: Hubert F. <hfi...@te...> - 2005-07-12 14:19:05
|
Armin Bauer wrote: > So i think the whole GPL vs. LGPL boils down to the question: > Which is better for the project? A possible higher userbase with > companies using the library which might return something in the future > or a maybe lower userbase but a possible source of income for the project? My opinion: If you want OpenSync to be adopted by projects like GNOME, libraries cannot be GPL. This is part of the policy of GNOME. I myself asked the question about a project I'm working on. I was really willing to make the library GPL, but for the sole reason of being able to use it in GNOME, I decided for LGPL. That still allow proprietary vendor to link against it. Just my CDN $.02 Hub |
|
From: Armin B. <arm...@de...> - 2005-07-13 15:09:54
Attachments:
signature.asc
|
Ok, after i thought a bit about it and your persuasion work i changed the license to LGPL. :) Hubert Figuiere wrote: > Armin Bauer wrote: > >> So i think the whole GPL vs. LGPL boils down to the question: >> Which is better for the project? A possible higher userbase with >> companies using the library which might return something in the future >> or a maybe lower userbase but a possible source of income for the >> project? > > > My opinion: > > If you want OpenSync to be adopted by projects like GNOME, libraries > cannot be GPL. This is part of the policy of GNOME. > > I myself asked the question about a project I'm working on. I was really > willing to make the library GPL, but for the sole reason of being able > to use it in GNOME, I decided for LGPL. That still allow proprietary > vendor to link against it. > > Just my CDN $.02 > > Hub |
|
From: Hubert F. <hfi...@te...> - 2005-07-13 15:12:23
|
Armin Bauer wrote: > Ok, after i thought a bit about it and your persuasion work i changed > the license to LGPL. :) > Just don't make any mistake. I was not trying to persuade you. Just trying to give some fact, as I myself faced the problem recently, given might be the more important to you. Hub |
|
From: Cornelius S. <sch...@kd...> - 2005-07-13 18:18:02
|
On Wednesday 13 July 2005 17:09, Armin Bauer wrote: > Ok, after i thought a bit about it and your persuasion work i changed > the license to LGPL. :) I think it's a good decision. I see a broad adoption as critical for the OpenSync project. If device vendors or other third party developers would be put off by the GPL, this would probably harm the project more than the missed opportunity to sell some licenses. I'm sure there are other ways to base a business model on OpenSync. One question though: You use libwbxml, which changed its license from LGPL to GPL. Is there a way around that? Because it would be pretty pointless to have a non-GLP libsyncml, if it still requires a GPL library. -- Cornelius Schumacher <sch...@kd...> |
|
From: Armin B. <arm...@de...> - 2005-07-13 18:25:33
Attachments:
signature.asc
|
Cornelius Schumacher wrote: > On Wednesday 13 July 2005 17:09, Armin Bauer wrote: > >>Ok, after i thought a bit about it and your persuasion work i changed >>the license to LGPL. :) > > > I think it's a good decision. I see a broad adoption as critical for the > OpenSync project. If device vendors or other third party developers > would be put off by the GPL, this would probably harm the project more > than the missed opportunity to sell some licenses. I'm sure there are > other ways to base a business model on OpenSync. > > One question though: You use libwbxml, which changed its license from > LGPL to GPL. Is there a way around that? Because it would be pretty > pointless to have a non-GLP libsyncml, if it still requires a GPL > library. > thats true of course. i see 3 possible solutions: - persuade the developer of libwbxml to change back to LGPL :) - dont change anything and live with it that we link against GPL - create a fork from version 0.8.9 (the current version is 0.9.0). I dont think that making the necessary changes to libwbxml would be too hard. (Of course i would not like this option out of respect for the developer of libwbxml) Any other possibilities? Armin |
|
From: Eduardo P. H. <eha...@co...> - 2005-07-13 18:49:22
|
Hi, On Wed, Jul 13, 2005 at 08:24:47PM +0200, Armin Bauer wrote: >=20 > Cornelius Schumacher wrote: <snip> > > > >One question though: You use libwbxml, which changed its license from > >LGPL to GPL. Is there a way around that? Because it would be pretty > >pointless to have a non-GLP libsyncml, if it still requires a GPL > >library. > > >=20 > thats true of course. >=20 > i see 3 possible solutions: > - persuade the developer of libwbxml to change back to LGPL :) > - dont change anything and live with it that we link against GPL > - create a fork from version 0.8.9 (the current version is 0.9.0). I > dont think that making the necessary changes to libwbxml would be too > hard. (Of course i would not like this option out of respect for the > developer of libwbxml) I'm afraid the third option is the better one. I doubt we would convince the libwbxml developer (IIRC, I know people who have tried it, but I am not sure if they really contacted him). The second choice doesn't seem reasonable. I don't like having to fork, and I would like to have a better choice, but it seems we don't have a better one (except the first one, if we manage to convince him :). Anyway, I expect that the libwbxml author considered the risk of someone doing this when he decided to change the license of libwbxml. We have another option: write a wbxml library from scratch, but this doesn't seem to make sense as we already have a LGPL library available. >=20 > Any other possibilities? I don't see any, unfortunately. >=20 > Armin --=20 Eduardo |
|
From: Armin B. <arm...@de...> - 2005-07-13 19:07:00
Attachments:
signature.asc
|
Eduardo Pereira Habkost wrote: > Hi, > > On Wed, Jul 13, 2005 at 08:24:47PM +0200, Armin Bauer wrote: > >>Cornelius Schumacher wrote: > > <snip> > >>>One question though: You use libwbxml, which changed its license from >>>LGPL to GPL. Is there a way around that? Because it would be pretty >>>pointless to have a non-GLP libsyncml, if it still requires a GPL >>>library. >>> >> >>thats true of course. >> >>i see 3 possible solutions: >>- persuade the developer of libwbxml to change back to LGPL :) >>- dont change anything and live with it that we link against GPL >>- create a fork from version 0.8.9 (the current version is 0.9.0). I >>dont think that making the necessary changes to libwbxml would be too >>hard. (Of course i would not like this option out of respect for the >>developer of libwbxml) > > > I'm afraid the third option is the better one. > > I doubt we would convince > the libwbxml developer (IIRC, I know people who have tried it, but I am > not sure if they really contacted him). > > The second choice doesn't seem reasonable. > > I don't like having to fork, and I would like to have a better choice, > but it seems we don't have a better one (except the first one, if we > manage to convince him :). > > Anyway, I expect that the libwbxml author considered the risk of someone > doing this when he decided to change the license of libwbxml. > > We have another option: write a wbxml library from scratch, but this > doesn't seem to make sense as we already have a LGPL library available. > I dont think that writing from scratch is a good idea since the exisiting LGPL version of libwbxml is almost complete so the changes wouldnt be too large... so a fork should be pretty easy. The questions is of course how distributions would be handled since we then would need to get the new (LGPL) library into all distros under a new name. So i think convincing is by far the most convincing option :) > >>Any other possibilities? > > > I don't see any, unfortunately. > > >>Armin > > |
|
From: Maciek B. <ma...@bo...> - 2005-07-13 19:25:15
|
On Wednesday 13 July 2005 20:19, Cornelius Schumacher wrote: > One question though: You use libwbxml, which changed its license from > LGPL to GPL. Is there a way around that? Because it would be pretty > pointless to have a non-GLP libsyncml, if it still requires a GPL > library. A question: what SyncML client stil uses wbxml these days? I don't know of any, to be honest. In that case, we could live with the LGPL fork (which is not going to be really used after all)... ./Maciek |
|
From: Armin B. <arm...@de...> - 2005-07-13 20:45:43
Attachments:
signature.asc
|
Maciek Borowka wrote: > On Wednesday 13 July 2005 20:19, Cornelius Schumacher wrote: > >>One question though: You use libwbxml, which changed its license from >>LGPL to GPL. Is there a way around that? Because it would be pretty >>pointless to have a non-GLP libsyncml, if it still requires a GPL >>library. > > > A question: what SyncML client stil uses wbxml these days? > uh... i think its the other way round. which client _isnt_ using wbxml these days? All mobile devices i know how can't even speak xml. They parse the wbxml directly to save memory and bandwidth. > I don't know of any, to be honest. In that case, we could live with the LGPL > fork (which is not going to be really used after all)... > > ./Maciek > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Opensync-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-users |
|
From: Maciek B. <ma...@bo...> - 2005-07-14 06:30:08
|
On Wednesday 13 July 2005 22:45, Armin Bauer wrote: > > > > A question: what SyncML client stil uses wbxml these days? > > uh... i think its the other way round. which client _isnt_ using wbxml > these days? All high end Symbian based phones? They speak pure XML. > All mobile devices i know how can't even speak xml. They parse the wbxml > directly to save memory and bandwidth. I googled some more and it seems you are right: there is a numer of devices using wbxml (SE T610, Nokia 6600). Well, sorry for the noise. ./Maciek |
|
From: Armin B. <arm...@de...> - 2005-07-18 21:53:05
Attachments:
signature.asc
|
Patrick Ohly wrote: > On Tue, 2005-07-12 at 11:20 +0200, Armin Bauer wrote: > >>Helge Hess wrote: >> >>>Is this library suitable for server side implementations as well or is >>>it focused on clients? >>> >> >>The library consists of several layers. > > [..] > >>so the library will be usable as both server and client by using >>different parts of the library > > > Will it support both slow and fast synchronization? I had considered > implementing SyncML client support for Opie a while ago, but the Opie > PIM API would not support keeping track of local changes, so each > synchronization would have to be done via slow sync and for that the > server needs to detect changes. yes libsyncml supports slow-sync. This is requirement by the syncml protocol and the library fully implements this > > This is not listed in your list above; on the other hand, I am not sure > whether this wouldn't belong into the SyncML server on top of the > library layers. In that case let me rephrase my question: will OpenSync > on top of libsyncml support a slow sync of contact and calender entries? > definetly. opensync has a part that is called "Hashtables". It basically works like this: you go through all data you have and create a hash of it (this can either be a hash like the md5 or timestamps or whatever you can come up with that changes when the object is changed) then you call the hashtable with the uid and the hash of the object. opensync then compares the hash against the old stored hash. - if the uid is not in the hashtable the object is new - if the uid is in the table, but the hash dont match, the object was changed - if the uid is in the table and the hash is the same the object was not changed - afterwards you go through all uids that were not reported in the table. These objects are deleted Fortunately, opensync abstracts all this for you :) You can see a implementation of this with the file-sync plugin where this is used to see which files were changed since the last sync. you can see it here: http://www.opensync.org/file/plugins/file-sync/src/file_sync.c > Regarding the Opie SyncML client, your libsyncml is one option. > The other, older (more mature?) option is the C++ Sync4j client > library (www.sync4j.org). I have not actually used that lib > because my initial attempts of just syncing my Sony Ericcson K750 > with the Sync4j server failed: > http://forge.objectweb.org/tracker/index.php?func=detail&aid=303703&group_id=96&atid=100096 > the main problem is see with sync4j is that it uses java which makes it a lot less usable for the open source community in my opinion. so my approach is to write it in a low level language and the provide high level wrappers so that it is usable from python or java. > That has dampened my enthusiasm a bit, especially because none > of the Sync4j developers has reacted. I hope OpenSync and libsyncml > will fare better; please, continue your effort and actually release > something that works, it is appreciated ;-) > |
|
From: Patrick O. <Pat...@gm...> - 2005-07-19 21:08:12
|
On Mon, 2005-07-18 at 23:52 +0200, Armin Bauer wrote: > > This is not listed in your list above; on the other hand, I am not sure > > whether this wouldn't belong into the SyncML server on top of the > > library layers. In that case let me rephrase my question: will OpenSync > > on top of libsyncml support a slow sync of contact and calender entries? > > > > definetly. opensync has a part that is called "Hashtables". It basically > works like this: [...] > you can see it here: > http://www.opensync.org/file/plugins/file-sync/src/file_sync.c Great, so if I'm lucky it'll just work :-) However, I don't have much time at my hands that I could use for this, so I'd prefer to wait for a first working release candidate of OpenSync/libsyncml before starting to compile and test it. I hope this is okay. > the main problem is see with sync4j is that it uses java which makes it > a lot less usable for the open source community in my opinion. so my > approach is to write it in a low level language and the provide high > level wrappers so that it is usable from python or java. The client library itself is written in C++, which should integrate pretty well into other languages, too. I agree with you about the server, but wouldn't mind running it as it is either. -- Bye, Patrick Ohly -- Pat...@gm... pa...@co... (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X