Menu
▾
▴
opensync-devel
|
From: Emanoil K. <del...@ya...> - 2011-01-24 23:57:33
|
Can you have a look int omy comments on http://www.opensync.org/ticket/754 regards --- On Fri, 1/14/11, Chris Frey <cd...@fo...> wrote: > From: Chris Frey <cd...@fo...> > Subject: Re: [Opensync-devel] OpenSync priorities > To: ope...@li... > Date: Friday, January 14, 2011, 9:27 PM > On Sat, Jan 08, 2011 at 12:30:44PM > -0800, Emanoil Kotsev wrote: > > 2. libopensync > > > > http://www.opensync.org/ticket/1442 > > http://www.opensync.org/ticket/1444 - a > problem in the parser (converter) breaks sync of contact > data > > > Can you grab the latest vformat plugin from SVN and give it > a try? > > If it works, can you close the above tickets for me? :-) > > Thanks, > - Chris > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. > Understand > malware threats, the impact they can have on your business, > and how you > can protect your company and customers by using code > signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > |
|
From: Michael B. <mic...@cm...> - 2011-01-04 16:12:48
Attachments:
smime.p7s
|
Hi Patrick, I think an important foot note is the question which goals the projects have. I am personally (as IT manager of a university) see three general needs in terms of synchronization: 1. a groupware server (with Active Sync support) 2. a sync solution on mobile devices (for Linux mobiles) 3. a local desktop solution to backup devices A fourth nice-to-have need is a synchronization of a device with a groupware server via a local software. This would avoid the usage of over-the-air transport which sometimes still costs money. I think this is some kind of bridge mode. The first need is not the goal of OpenSync and SyncEvolution. The third need is the goal of both solutions. So the question is which priority have the other needs? Which general design ideas like plugins, engines, formats or peer-to-peer exist and how does they perform in the different use cases? Disclaimer: The following answers just represent my actual limited knowledge ;) 1.) SyncEvolution explicitly targets the second need. 2.) SyncEvolution can handle the fourth need but I think this was not the usage which the developers have in mind. 3.) OpenSync is not primarily designed for the second need but it would work. Just like SyncEvolution and the fourth need. 4.) OpenSync is definitely designed for the fourth need. A desktop driven sync solution which makes the whole equipment happy in one step. The numbers are just present to make referencing more easier. I know these are simplifications but they are a good starting point for a discussion ;) So there are some important aspects beside the pure technology (complexity vs. peer-to-peer). Such aspects are major use cases and design priorities like user experience and usage philosophies. Additionally I assume that nobody understand both software stacks completely ;) Perhaps we should shape the projects a little bit to not just discuss about a slow-moving development process but to understand the perspectives and challenges. I know that usually such discussions are off list but a mailing list is a good archiving and transparent method. I hope you can accept this. So yes, I think it was the right decision from Patrick and Daniel to post this on the list. Best regards Michael -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Chris F. <cd...@fo...> - 2011-01-07 20:54:07
|
On Tue, Jan 04, 2011 at 05:12:39PM +0100, Michael Bell wrote: > Perhaps we should shape the projects a little bit to not just discuss > about a slow-moving development process but to understand the > perspectives and challenges. > > I know that usually such discussions are off list but a mailing list is > a good archiving and transparent method. I hope you can accept this. So > yes, I think it was the right decision from Patrick and Daniel to post > this on the list. Anyone who wishes to document OpenSync could use this format as well. Start with the problems that need to be solved, and then show how they are solved via the engine. - Chris |
|
From: Lukas Z. <lu...@pl...> - 2011-01-05 15:43:56
|
Hello all, Coincidentally right now I am looking into what could be the long-term future of my efforts that went into libsynthesis, now that I am no longer with Synthesis, but again independent and "free" :-) I very much welcome efforts to join forces to make sync better, as I must admit that despite all efforts in the last 10 years, interoperable PIM sync is still only a dream for most users. The only solutions that work for non-geeks that are not backed up by a corporate IT support are the (more or less) proprietary end-to-end solutions, all but interoperable. At the same time I am convinced that standardized sync (far beyond PIM) is a concept that is of paramount importance for cloud computing. Selling our souls (ahem, data) to single points of (technical, commercial, political) failure such as Google, Facebook or even Dropbox can't be a long term solution. I see these as the Compuserves and Datex-P's of today, important to get things started. But if cloud computing is to be more than a hype, it will need a open, reliable, generic, pragmatic sync mechanism eventually, like inter-computer data exchange needed TCP/IP to take off. So while I'm completely a SyncML guy as far as my actual work (libsynthesis) is concerned, the thing that brought me to SyncML in 2000 was the hope for truly interoperable sync, and not vice versa. Today, libsynthesis is certainly useful for doing SyncML, which will remain a part of picture for some years, if only to support legacy devices. But I'm totally open to ideas that go beyond SyncML, and probably refactoring libsynthesis to make parts of it more genererally usable (vXXX formatting in particular) for other protocols. What I'm not sure at the moment at the concept level is if unifying the currently available (IMHO all more or less "legacy") sync protocols directly into a single engine is really the way to go. This thought feels a bit like creating the super-legacy engine. Maybe we need a structure where a really next gen sync mechanism builds the core, and the OpenSyncs, libsynthesises and Syncevolutions are degraded to plugins on an outer ring into that architecture to provide legacy sync. I mean, even we had perfect integration of SyncML, CalDAV, ActiveSync etc. today, I feel it would still not cover everyday sync needs I have today, let alone in the future. With the explosion of endpoints (devices) on one side and data sources (services, databases) on the other I doubt that point-to-point sync has a bright future. I have the impression what we need could be more similar to git than to SyncML. This is of course vague thinking and far from anything realizable in short term. But when talking about combining efforts, I think we need also to talk about the big context for all this. Down from that meta level, two comments to messages in this thread: On Jan 4, 2011, at 17:23 , Georg C. F. Greve wrote: >> SyncML has had interoperability issues due to its loose definition. >> Vendors also got stuck supporting the same old data formats and devices, >> instead of adapting to more modern needs like iCalendar 2.0. > > Both points are true. I would also say that SyncML has the conceptual flaw of > assuming dumber devices than todays devices actually are. The devices might be faster and have more memory, but unfortunately some backends are still as dumb as ever regarding *the* (IMHO) single most important feature for smooth sync, especially when multi-point sync comes into the picture, which is a creator-assigned, 100% persistent UID. SyncML tried to work around this, and most of the complexity and also of reliability issues in SyncML comes from the fact that identity has to be *derived* by comparing payload. And in consequence, this shifted resposibility for success or failure onto the loosely specified vXXX-formats, which were not designed for nor reliable enough for that (with the exception maybe of iCalendar 2.0 which most implementations don't have). There's also a conceptual contradiction in this, because SyncML on one hand requires identity to be derived from the payload and on the other hand demands very much flexibility in handling of that payload (very dumb endpoints with very few fields vs. sophisticated endpoints with many details). IMHO it's an either-or: Either identity is derived from payload (SHA checksums like in git or dropbox) which implies that all peers need to store the entire paylod 1:1, or identity is a (G)UID assigned by the creator of a record and guaranteed to remain unchanged over its entire lifetime - then peers might be allowed to only store abstractions or subsets of the actual data. SyncML tried to do both at the same time - the price paid is the ever fragile slow sync with its potential for great duplicate mess. On Jan 4, 2011, at 11:36 , Daniel Gollub wrote: > I'm still open to adapt OpenSync and it's plugin to make more use of common > code - e.g. vcard handling of libsynthesis, maybe even seperating libsynthesis > in sometihng like libvxx to provide a common code base for vformats not only > for syncing application. I would be also happy if one day someone prepares > patches which replace OSyncEngine with something based on libsynthesis. > > libsynthesis is definitely more mature code regarding vformat handling and the > engine with regards of syncml. Not quite sure with regards generic > synchronization. You're absolutely right - libsynthesis is not designed for generic sync. Currently I also think that extracting the vformat (and rfc2822 btw.) handling and the script engine into more generically usable libraries would be worthwhile. Lukas |
|
From: Michael B. <mic...@cm...> - 2011-01-07 14:51:37
Attachments:
smime.p7s
|
Hi Lukas, On 01/05/11 16:26, Lukas Zeller wrote: > > I mean, even we had perfect integration of SyncML, CalDAV, ActiveSync > etc. today, I feel it would still not cover everyday sync needs I > have today, let alone in the future. With the explosion of endpoints > (devices) on one side and data sources (services, databases) on the > other I doubt that point-to-point sync has a bright future. I have > the impression what we need could be more similar to git than to > SyncML. I have the same feeling and therefore I created a playground - OldSync. This is just a technology study. The idea was that there are some basically good ideas like pipes, workflows and distributed repositories (hg, mercurial) which preserve a history. The idea was that every sync is a peer-to-peer sync but I always synchronized a device or the filesystem with a filesystem. If the data is in a repository (git, mercurial) then you have a backup and you can synchronize in a distributed way (native git/hg push/pull). Additionally such systems have a very flexible diff backends. So you need normalization but not always an own merger (at minimum for text based data). > This is of course vague thinking and far from anything realizable in > short term. But when talking about combining efforts, I think we need > also to talk about the big context for all this. I had just a rough idea too. I only want to express that I have the same impression like you. Best regards Michael -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Chris F. <cd...@fo...> - 2011-01-07 21:07:31
|
On Wed, Jan 05, 2011 at 04:26:11PM +0100, Lukas Zeller wrote: > You're absolutely right - libsynthesis is not designed for generic sync. > Currently I also think that extracting the vformat (and rfc2822 > btw.) handling and the script engine into more generically usable > libraries would be worthwhile. There has been a bit of talk about making a useful generic vformat library. This would be useful for me as well. I notice that there seems to be a difference in development and licensing strategies between OpenSync and libsynthesis. Anyone can contribute to OpenSync and not have to sign anything, while it appears that contributing to libsynthesis requires signing a contributor agreement. This is off-putting to some developers. I have some experience wrestling with vformat.c and incorporating it into the Barry plugin, as well as into the Barry library itself now. This is wasteful duplication, and it would be nice to see vformat support available generically. Are you interested in any help with this that does not involve signing a contributor agreement? - Chris |
|
From: Emanoil K. <del...@ya...> - 2011-01-08 13:12:48
|
Hello, to all of you.
Thank you for your time contributing to this discussion. I have to admit that I couldn't accomplish my goal to have a working sync with kde4 and my mobile, but I am very glad that all of you are discussing the future now.
In accordance to the message below I have a feeling that a lot in the concept of the opensync engine is similar to what I have researched in my studies in AI called autonomous agents or agent based architecture, though it's not exactly the same... opensync is somehow like a prototype for a coordinator (the hub). So if we were to borrow some wisdom from OAA (open agent architecture) we were to make the handling of the object types more autonomous or take the sync and merge functionality outside the engine (like default plugins filters or similar). My idea is that an obj can ask who can merge and get answer from the merger that will take over the job ...
This is just an idea that I had recently but it fits in some way to the desire for taking vformat out of the engine ... and probably other components too.
I have not investigated the whole architecture of the library but just had a look here and then during my work on the akonadi plugin and the testing of libsyncml.
--- On Fri, 1/7/11, Chris Frey <cd...@fo...> wrote:
> > You're absolutely right - libsynthesis is not designed
> for generic sync.
> > Currently I also think that extracting the vformat
> (and rfc2822
> > btw.) handling and the script engine into more
> generically usable
> > libraries would be worthwhile.>
> There has been a bit of talk about making a useful generic
> vformat
> library. This would be useful for me as well.
>
> I notice that there seems to be a difference in development
> and licensing
> strategies between OpenSync and libsynthesis. Anyone
> can contribute
> to OpenSync and not have to sign anything, while it appears
> that
> contributing to libsynthesis requires signing a contributor
> agreement.
> This is off-putting to some developers.
>
> I have some experience wrestling with vformat.c and
> incorporating it
> into the Barry plugin, as well as into the Barry library
> itself now.
> This is wasteful duplication, and it would be nice to see
> vformat
> support available generically.
>
> Are you interested in any help with this that does not
> involve signing
> a contributor agreement?
>
Licensing of synthesis was also my consideration. Interesting to know how Patrick has solved it into his project. I don't remember if I had to sign a license agreement when running syncevo the first time
kind regards
|
|
From: Lukas Z. <lu...@pl...> - 2011-01-08 13:52:23
|
Hello, On Jan 8, 2011, at 14:12 , Emanoil Kotsev wrote: > In accordance to the message below I have a feeling that a lot in the concept of the opensync engine is similar to what I have researched in my studies in AI called autonomous agents or agent based architecture, though it's not exactly the same... opensync is somehow like a prototype for a coordinator (the hub). So if we were to borrow some wisdom from OAA (open agent architecture) we were to make the handling of the object types more autonomous or take the sync and merge functionality outside the engine (like default plugins filters or similar). My idea is that an obj can ask who can merge and get answer from the merger that will take over the job ... Note that this is much closer to how libsynthesis actually works than it might seem. Of course it is now all integrated into one "engine", but the actual sync and merge is NOT done on vformat, but on abstracted data items. With some refactoring, sync and merge could be separated from formatting and talking to a peer. Tight integration is needed between the vformat converters and the information a "engine" might have about the current peer. Because vformats (especially the old, but widespread ones) are too weak in specification and often too sloppily implemented to be handled without quite a bit of context about the sender/recipient. There's no such thing as a converter that can be fed only a vformat and produces sensible, normalized output (or vice versa). Best Regards, Lukas |
|
From: Michael B. <mb...@de...> - 2011-01-08 14:17:49
|
On Sat, Jan 08, 2011 at 05:12:40AM -0800, Emanoil Kotsev wrote: > > Are you interested in any help with this that does not involve > > signing a contributor agreement? > > > > Licensing of synthesis was also my consideration. Interesting to know > how Patrick has solved it into his project. I don't remember if I had > to sign a license agreement when running syncevo the first time Chris was talking about contributor agreements, not license agreements. It is about when you donate code to the project, they want you to sign over some parts of your copyright so they can potentially relicense the code to their liking (either to another open source license, or dual-license it with a proprietary license for their clients). This does not affect users of the software. Michael |
|
From: deloptes <del...@ya...> - 2011-01-08 15:03:32
|
Michael Banck wrote: > On Sat, Jan 08, 2011 at 05:12:40AM -0800, Emanoil Kotsev wrote: >> > Are you interested in any help with this that does not involve >> > signing a contributor agreement? >> > >> >> Licensing of synthesis was also my consideration. Interesting to know >> how Patrick has solved it into his project. I don't remember if I had >> to sign a license agreement when running syncevo the first time > > Chris was talking about contributor agreements, not license agreements. > It is about when you donate code to the project, they want you to sign > over some parts of your copyright so they can potentially relicense the > code to their liking (either to another open source license, or > dual-license it with a proprietary license for their clients). This > does not affect users of the software. > > thanks I just understood this later :-) |
|
From: Lukas Z. <lu...@pl...> - 2011-01-08 13:38:33
|
Hello Chris, On Jan 7, 2011, at 22:04 , Chris Frey wrote: > I notice that there seems to be a difference in development and licensing > strategies between OpenSync and libsynthesis. Anyone can contribute > to OpenSync and not have to sign anything, while it appears that > contributing to libsynthesis requires signing a contributor agreement. > This is off-putting to some developers. The thing is, there's simply no money except our own (2 people) funding our work in libsynthesis, so we need the closed derived work (products we sell) to keep it going. That's why we have the contributor agreement. Without it, we cannot use contributions to libsynthesis ourselves which would essentially split the project into a internal and a public version. We'll not do that with the version we provide the infastructure for, but of course anyone who feels too much restrained by a contributor agreement could start maintaining a separate fork. > I have some experience wrestling with vformat.c and incorporating it > into the Barry plugin, as well as into the Barry library itself now. > This is wasteful duplication, and it would be nice to see vformat > support available generically. > > Are you interested in any help with this that does not involve signing > a contributor agreement? The above explanation holds true for the classic libsynthesis. I can well imagine (however not guarantee anything at this time) that a separated vformat library could be handled differently. Unless it means directly killing my own income, I'm always open for open :-) Lukas |
|
From: Michael B. <mb...@de...> - 2011-01-08 14:33:32
|
On Sat, Jan 08, 2011 at 02:38:17PM +0100, Lukas Zeller wrote: > Hello Chris, > > On Jan 7, 2011, at 22:04 , Chris Frey wrote: > > > I notice that there seems to be a difference in development and licensing > > strategies between OpenSync and libsynthesis. Anyone can contribute > > to OpenSync and not have to sign anything, while it appears that > > contributing to libsynthesis requires signing a contributor agreement. > > This is off-putting to some developers. > > The thing is, there's simply no money except our own (2 people) > funding our work in libsynthesis, so we need the closed derived work > (products we sell) to keep it going. AFAICT, the public part of libsynthesis is LGPL, right? Does it have an "or later" clause for the versioning of the license? In any case, having it LGPL should make it possible to develop and sell proprietary products on top of libsynthesis, as long as you don't need to modify libsynthesis itself for it. > That's why we have the contributor agreement. Without it, we cannot > use contributions to libsynthesis ourselves which would essentially > split the project into a internal and a public version. We'll not do > that with the version we provide the infastructure for, but of course > anyone who feels too much restrained by a contributor agreement could > start maintaining a separate fork. There's a couple of things you could do (or maybe you did already, I did not check your contributor agreement) to make libsynthesis more appealing to external developers: 1. You could relicense it to BSD. That would allow you to use your modified version of the code (plus any external future contributions) in proprietary products. Of course, it would allow the same to possible competitors, not sure you have any. In that case, you could drop the contributor agreement. 2. Relicense the code to say "LGPL 2.1 or later". That would remove potential concerns that in the future libsynthesis will be incompatible with LGPLv4 libraries, if a new version of the LGPL gets released ever. 2. If not already the case, you could modify the contributor agreement to guarantee the free software community that the public version of the code will always be in the spirit of the LGPL as published by the Free Software Foundation. This is how the FSF contributor agreement works (except it also guarantess the FSF will not sell proprietary versions either, I think). That will remove potential concerns that you might relicense the code to GPL or some other, possibly incompatible license to whatever the contributor uses themselves to interact with libsynthesis. Michael |
|
From: Lukas Z. <lu...@pl...> - 2011-01-09 14:43:09
|
Hello Michael, On Jan 8, 2011, at 15:33 , Michael Banck wrote: >> The thing is, there's simply no money except our own (2 people) >> funding our work in libsynthesis, so we need the closed derived work >> (products we sell) to keep it going. > > AFAICT, the public part of libsynthesis is LGPL, right? Does it have an > "or later" clause for the versioning of the license? Presently it is dual licensed under LGPL 2.1 and 3.0 > In any case, having it LGPL should make it possible to develop and sell > proprietary products on top of libsynthesis, as long as you don't need > to modify libsynthesis itself for it. Except that for iOS, which happens to be the source of funding for my work on libsynthesis, that does not work, because iOS apps need to be statically linked with all libraries (except those provided by the system). >> That's why we have the contributor agreement. Without it, we cannot >> use contributions to libsynthesis ourselves which would essentially >> split the project into a internal and a public version. We'll not do >> that with the version we provide the infastructure for, but of course >> anyone who feels too much restrained by a contributor agreement could >> start maintaining a separate fork. > > There's a couple of things you could do (or maybe you did already, I did > not check your contributor agreement) to make libsynthesis more > appealing to external developers: > > 1. You could relicense it to BSD. That would allow you to use your > modified version of the code (plus any external future contributions) in > proprietary products. Of course, it would allow the same to possible > competitors, not sure you have any. In that case, you could drop the > contributor agreement. True, but quite a big risk to take. I've invested 10 years into this and didn't get a single penny funding except for selling products based on this code, in a narrow niche. > 2. Relicense the code to say "LGPL 2.1 or later". That would remove > potential concerns that in the future libsynthesis will be incompatible > with LGPLv4 libraries, if a new version of the LGPL gets released ever. Worth considering, sure, but it does not solve the problem that we still need a contributor agreement. > 2. If not already the case, you could modify the contributor agreement > to guarantee the free software community that the public version of the > code will always be in the spirit of the LGPL as published by the Free > Software Foundation. Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and states that "Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license". Best Regards, Lukas Zeller |
|
From: Chris F. <cd...@fo...> - 2011-01-09 22:40:46
|
On Sun, Jan 09, 2011 at 03:42:54PM +0100, Lukas Zeller wrote: > On Jan 8, 2011, at 15:33 , Michael Banck wrote: > > In any case, having it LGPL should make it possible to develop and sell > > proprietary products on top of libsynthesis, as long as you don't need > > to modify libsynthesis itself for it. > > Except that for iOS, which happens to be the source of funding for > my work on libsynthesis, that does not work, because iOS apps need > to be statically linked with all libraries (except those provided by > the system). It is my understanding that LGPL libraries can be linked statically to closed source applications, as long as all the object files of the closed source app are provided along with the LGPL library, so that the recipient can re-link to a modified LGPL library. Other library licenses may be blocking this, but not the LGPL. - Chris |
|
From: Michael B. <mb...@de...> - 2011-01-09 15:03:41
|
Hi, On Sun, Jan 09, 2011 at 03:42:54PM +0100, Lukas Zeller wrote: > On Jan 8, 2011, at 15:33 , Michael Banck wrote: > > There's a couple of things you could do (or maybe you did already, I did > > not check your contributor agreement) to make libsynthesis more > > appealing to external developers: > > > > 1. You could relicense it to BSD. That would allow you to use your > > modified version of the code (plus any external future contributions) in > > proprietary products. Of course, it would allow the same to possible > > competitors, not sure you have any. In that case, you could drop the > > contributor agreement. > > True, but quite a big risk to take. I've invested 10 years into this > and didn't get a single penny funding except for selling products > based on this code, in a narrow niche. I am not saying you would get funding, I am just saying you could still sell your products that way, and have the code open to everybody. Of course, nobody can guarantee you that you would get more external contributors if you did so, but libsynthesis would certainly be more interesting to contribute to. > > 2. Relicense the code to say "LGPL 2.1 or later". That would remove > > potential concerns that in the future libsynthesis will be incompatible > > with LGPLv4 libraries, if a new version of the LGPL gets released ever. > > Worth considering, sure, but it does not solve the problem that we > still need a contributor agreement. Right, but maybe some people would be more willing to sign it. > > 2. If not already the case, you could modify the contributor agreement > > to guarantee the free software community that the public version of the > > code will always be in the spirit of the LGPL as published by the Free > > Software Foundation. > > Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and > states that "Any contribution we make available under any license will > also be made available under a suitable FSF (Free Software Foundation) > or OSI (Open Source Initiative) approved license". Well, the SCA certainly doesn't have the best image. However, that is mostly due to the potential to take code (partly) proprietary. You already did that, so that is probably clear to prospective contributors. I see how it would be difficult to get outside contributions that way. Michael |
|
From: Lukas Z. <lu...@pl...> - 2011-01-09 16:58:58
|
Hi Michael, On Jan 9, 2011, at 16:03 , Michael Banck wrote: >> True, but quite a big risk to take. I've invested 10 years into this >> and didn't get a single penny funding except for selling products >> based on this code, in a narrow niche. > > I am not saying you would get funding, I am just saying you could still > sell your products that way, and have the code open to everybody. Of > course, nobody can guarantee you that you would get more external > contributors if you did so, but libsynthesis would certainly be more > interesting to contribute to. No doubt. But if my business, which has alone funded all of libsynthesis, goes down the drain in the process, that wouln't help the project much. I'm not saying that I disagree with you on the goal to make software open, but I'm saying that there's risk involved. None of the less strict licenses than GPL would exist at all if there wasn't always the problem of how to fund the developer's lives somehow. I big companies, that's going around many corners and thus is not always so obvious, but I'm facing a pretty bare-bone situation here. Make basic income happen anytime soon, and things would look different :-) >>> 2. Relicense the code to say "LGPL 2.1 or later". That would remove >>> potential concerns that in the future libsynthesis will be incompatible >>> with LGPLv4 libraries, if a new version of the LGPL gets released ever. >> >> Worth considering, sure, but it does not solve the problem that we >> still need a contributor agreement. > > Right, but maybe some people would be more willing to sign it. Maybe. But maybe the point is something different - as much as I agree with the goals of free software, I'm not so sure about the total insurance attitute that sometimes accompanies it. I mean, if the current licensing terms are a problem for someone who would like to actually *do* something, please let me know. But expecting from me to risk 10 (full time!) years first, so that maybe eventually somebody could feel more inclined to considering contributing with zero risk... Not really. >> Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and >> states that "Any contribution we make available under any license will >> also be made available under a suitable FSF (Free Software Foundation) >> or OSI (Open Source Initiative) approved license". > > Well, the SCA certainly doesn't have the best image. However, that is > mostly due to the potential to take code (partly) proprietary. You > already did that, Not quite - we just couldn't risk making all our code OS without commercially risking our heads and in consequence the entire project. So we had to find ways to *keep* part of the code proprietary, and in particular work around the incompatibility of LGPL and iOS static linking requirements. That's something quite different from *taking* code proprietary. > so that is probably clear to prospective contributors. > > I see how it would be difficult to get outside contributions that way. You might be right - but then I haven't had a single complaint from anyone who actually wanted to contribute and found the terms were restricting. The current licensing model and contributor agreement is a result of active communication and negotiation between actively interested parties, and so will be future changes thereof. Lukas |
|
From: Chris F. <cd...@fo...> - 2011-01-09 23:04:36
|
On Sun, Jan 09, 2011 at 05:58:42PM +0100, Lukas Zeller wrote: > But maybe the point is something different - as much as I agree with > the goals of free software, I'm not so sure about the total insurance > attitute that sometimes accompanies it. I mean, if the current licensing > terms are a problem for someone who would like to actually *do* something, > please let me know. But expecting from me to risk 10 (full time!) years > first, so that maybe eventually somebody could feel more inclined to > considering contributing with zero risk... Not really. My original email in this thread was meant to let you know. :-) To me, a contributor agreement, of any kind, says to the community that the LGPL is good enough for them, but not good enough for the author. Basically, it is a big sign saying that the author wants to work alone. For example, I never dreamed of contributing to MySQL, even though I used the free version regularly. About the most I might have done was report a bug. I only did that once in an area that affected me, but I didn't bother working up a patch. The contributor agreement / closed nature of MySQL was a real factor in deciding not to pursue writing a patch. And personally, this goes for the FSF as well. I'm a bit more odd in that case, though. There's only so much time in the day, and sometimes seemingly small issues like licenses and paperwork or lack of trust sway the balance in certain directions. And sometimes money sways it in the other. Of course, there are business reasons why the dual license / contributor agreement path is taken, and if actual money is being made, hey, that works. And in some cases the suits force these decisions on the programmers too. But the money is instead of contributions. For some, that tradeoff is well worth it, and I acknowledge that. - Chris |
|
From: Lukas Z. <lu...@pl...> - 2011-01-10 15:18:14
|
Hello Chris, On Jan 10, 2011, at 0:04 , Chris Frey wrote: > On Sun, Jan 09, 2011 at 05:58:42PM +0100, Lukas Zeller wrote: >> But maybe the point is something different - as much as I agree with >> the goals of free software, I'm not so sure about the total insurance >> attitute that sometimes accompanies it. I mean, if the current licensing >> terms are a problem for someone who would like to actually *do* something, >> please let me know. But expecting from me to risk 10 (full time!) years >> first, so that maybe eventually somebody could feel more inclined to >> considering contributing with zero risk... Not really. > > My original email in this thread was meant to let you know. :-) Yes, I apprechiate that! I am just trying to explain a bit why we came to the current licensing / contributor model. What I have a hard time with is getting thrown into the same pot with multinational companies, as a two man, entirely self funded, all risk private micro venture. I beg to realize that this makes a difference, and not all options IBM can safely take are automatically feasible for us. > To me, a contributor agreement, of any kind, says to the community that > the LGPL is good enough for them, but not good enough for the author. LGPL alone simply did not fit our situation. They have their shlib border way to define derived work, and according to that, all our commercial products would have to become opensource. As much as I would like to be able to dedicate all of my work entirely to opensource, I haven't arrived at an arrangement that would allow me to do so, without committing commercial suicide. I'm not saying such an arrangement is impossible, but I'm saying I haven't found it yet. Ideas welcome. We've considered all sorts of ways, and arrived at LGPL+CA exactly for the reason because the community does not like derived licenses, but wants FSF original licenses (or so we were told at that time in 2009). > Basically, it is a big sign saying that the author wants to work alone. It could be read as such when looked at it without any context. I hope however I could give the context to explain that this interpretation is more that wrong regarding libsynthesis - the reason is the real-world history of the project. A full-time venture of two people over 10 years now, with (I repeat) no cent public money burnt in the process. Sacrificing the business that pays for it to correct the impurity of the current licensing is just out of proportions, and would hurt everyone, us and the community alike. I'd understand the criticism more if we chose GPL, so forcing everyone else to open their complete applications while we could keep them closed. But with LGPL we're offering the same potential for building commercial apps to everyone. The only reason that's not "good enough" for us is that our (pre-existing!) products are statically linked with some or all code of what today's libsynthesis is. It's just not possible to rewrite all of them (the day has 24 hours here as well). Users adpting libsynthesis in its OS form can't possibly have these sorts of dependencies, so what the CA provides us extra is a non-value for everyone except us. > For example, I never dreamed of contributing to MySQL, even though I > used the free version regularly. About the most I might have done was > report a bug. I only did that once in an area that affected me, but I > didn't bother working up a patch. The contributor agreement / closed > nature of MySQL was a real factor in deciding not to pursue writing a > patch. Aagain I beg to take scale into account. If we were anywhere near the size of MySQL AB at that time, or had shareholders only waiting to draw away profit from your contributions, I'd understand the concern. I know, I'm stressing the point a bit, but essentially this is what makes tiny companies that take their own risk reluctant to try with open source. You get compared with the most powerful commercial entities, and expected to exceed their abilities to take risks (they all have CAs or tailored licenses, but you may not). > There's only so much time in the day, and sometimes seemingly small > issues like licenses and paperwork or lack of trust sway the balance > in certain directions. And sometimes money sways it in the other. > Of course, there are business reasons why the dual license / contributor > agreement path is taken, and if actual money is being made, hey, that > works. And in some cases the suits force these decisions on the programmers > too. But the money is instead of contributions. Nobody can contribute anything without his or her living supported by money. So anybody has to take care about that, somehow. I find it a bit strange that making that money "elsewhere" (hidden from the community) should be more noble, and thus more worth contributions. Both approaches are IMHO equal compromises needed in today's economy. To correct that means digging into how wages, taxes, money in general do or should work, a discussion I'm most interested in but is definitely OT here. Lukas Zeller |
|
From: Chris F. <cd...@fo...> - 2011-01-10 20:14:19
|
On Mon, Jan 10, 2011 at 04:17:51PM +0100, Lukas Zeller wrote: > Yes, I apprechiate that! I am just trying to explain a bit why we came > to the current licensing / contributor model. What I have a hard time > with is getting thrown into the same pot with multinational companies, > as a two man, entirely self funded, all risk private micro venture. I > beg to realize that this makes a difference, and not all options IBM > can safely take are automatically feasible for us. It's not my intention to judge you or your business model. It appears to be working for you, and I'm glad that you are making a living at it. I'm just trying to point out how it looks from the outside. And unfortunately, with the contributor agreement, the priority of helping with libsynthesis does tend to fall to the bottom of my (rather long) list. We can only do what makes sense to each of us. Best wishes, - Chris |
Thanks for helping keep SourceForge clean.
X