[sip-comm-dev] Open source versions of JMFInit and JMFReigstry?


#1

I know that this isn't a fun topic, but the Apache license on this project indicates to me that the contributors want to see their work have broad impact. So: I see a Sun Microsystems copyright in two .java
source files with the legend "All rights reserved". Is it true? Or rather: how can it be true? My guess is that these two files are from a Sun example application showing how to use JMF. The only sensible path is cut, paste, modify. But this sensible path wouldn't be legal, given the "All rights reserved" bit. Ok the legal path wouldn't be sensible. Unfortunately lawyers at my company can read "All rights reserved" plainly, so unless Sun agreed to release this code under Apache 2.0, that is not "All rights reserved", I wouldn't be able to use sip-communicator. Is there an open source version of these files?

Thanks,
John.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

JOHN J. BARTON wrote:

I know that this isn't a fun topic, but the Apache license on this project indicates to me that the contributors want to see their work have broad impact. So: I see a Sun Microsystems copyright in two .java
source files with the legend "All rights reserved". Is it true?

It is. We have extracted these files from JMF as they were in an anonymous pacakage and thus unusable from the application. They were integrated into the program only as a temporary solution until someone finds the time to implement them in a sip-communicator specific fashion. Well that moment hasn't come yet but the problem is on our todo list. Of course - should anyone want to do that - you are free to contribute.

Apart from implementing those files urself u could also simply - get rid of them. They are not really that critical.

By the way speaking of licenses - we've been thinking about shifting to lgpl and would want to know if that bothers anyone. We should however discuss that in a separate mail. So stay tuned

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi guys,

As some of you might know we are currently working on a major architecture shift of the sip-communicator. Next version will be OSGI based (using the OSCAR open source implementation).

This pretty much means that from now on the sip-communicator will be a bunch of plug-ins (osgi bundles) which offer implement and use different services.

Until now the sip-communicator and its code have been available under the Apache 1.1 license. We are however considering using an LGPL license for the next release.

In a few words this means that: You will be able to right your own bundles for the sip-communicator and release them (or not) under whatever license u may wish. You could also modify sip-communicator's bundles and use them internally (i.e. without distributing them) without releasing ur code. If however u'd need to change a sip-communicator bundle (i.e. fix bugs or optimize it ) and distribute it afterwards you will have to make your changes available to the public.

Is that fine with all of you?

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

Hi guys,

As some of you might know we are currently working on a major
architecture shift of the sip-communicator. Next version will be OSGI
based (using the OSCAR open source implementation).

This pretty much means that from now on the sip-communicator will be a
bunch of plug-ins (osgi bundles) which offer implement and use different
services.

Until now the sip-communicator and its code have been available under
the Apache 1.1 license. We are however considering using an LGPL license
for the next release.

In a few words this means that: You will be able to right your own
bundles for the sip-communicator and release them (or not) under
whatever license u may wish. You could also modify sip-communicator's
bundles and use them internally (i.e. without distributing them) without
releasing ur code. If however u'd need to change a sip-communicator
bundle (i.e. fix bugs or optimize it ) and distribute it afterwards you
will have to make your changes available to the public.

Is that fine with all of you?

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#5

As far as I can see sip-communicator does not yet support offer/answer processing, per RFC 3264, correct? But it seems easy to add.

Reading RFC 3261 (SIP), two exchanges need support, offer in INVITE, answer in 2XX or offer in 2XX and answer in ACK.

Offer in INVITE works now. Answer in 2XX or offer in 2XX would seem to mean changing SipCommunicator.handleAnswerRequest() to replace

sdpData = mediaManager.generateSdpDescription();

with something like

       String offer = interlocutor.getCall().getRemoteSdpDescription();
       if (offer == null || offer.length() == 0) {
          sdpData = mediaManager.generateSdpDescription();
       } else {
          sdpData = getMediaManger().getSDPAnswer(offer);
       }

where mediaManager.getSDPAnwser() parses the offer, compares to available media resources, and builds answer. Answer in ACK seems to already be supported in CallProcessing.processAck() which sets the remote sdp description.

Does this seem like a reasonable approach? Or is the offer/answer in their somewhere?

John.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Emil Ivov wrote:

Until now the sip-communicator and its code have been available under the Apache 1.1 license. We are however considering using an LGPL license for the next release.
...

Is that fine with all of you?

I'm curious about the reasons for the change. What advantage does LGPL give to you compared to Apache?

For reasons I am not too clear on, IBM considers "GPL/LGPL" as one category. I personally don't know of any IBM products that ship with GPL code. There are some that include Apache code.

John.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#7

Yup seems like a good fix. Thanks!

Would you be interested and do you have the possibility to contribute the getSDPAnswer(offer) method? Otherwise we'll have to wait for a week or so until I find the time to do it myself.

Emil

P.S. btw, why don't u subscribe to the list so that I don't have to approve every mail of yours? You r contributing good stuff so - no reason to stay out. If signing an agreement is what bothers you, then i could manually add ur address. Let me know if that's the case

JOHN J. BARTON wrote:

···

As far as I can see sip-communicator does not yet support offer/answer processing, per RFC 3264, correct? But it seems easy to add.

Reading RFC 3261 (SIP), two exchanges need support, offer in INVITE, answer in 2XX or offer in 2XX and answer in ACK.

Offer in INVITE works now. Answer in 2XX or offer in 2XX would seem to mean changing SipCommunicator.handleAnswerRequest() to replace

sdpData = mediaManager.generateSdpDescription();

with something like

      String offer = interlocutor.getCall().getRemoteSdpDescription();
      if (offer == null || offer.length() == 0) {
           sdpData = mediaManager.generateSdpDescription();
      } else {
           sdpData = getMediaManger().getSDPAnswer(offer);
      }

where mediaManager.getSDPAnwser() parses the offer, compares to available media resources, and builds answer. Answer in ACK seems to already be supported in CallProcessing.processAck() which sets the remote sdp description.

Does this seem like a reasonable approach? Or is the offer/answer in their somewhere?

John.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hello John

I'm curious about the reasons for the change. What advantage does LGPL give to you compared to Apache?

Well, it requires any third parties to release optimizations they have made to existing core functionalities.

For reasons I am not too clear on, IBM considers "GPL/LGPL" as one category.

I see. Actually I've also read some articles more or less "against" LGPL, (like this one for example:
http://weblogs.java.net/blog/johnreynolds/archive/2005/02/a_cautionary_lg_1.html
). But we'd like to get more code protection than Apache v 1.1 could give us.

I personally don't know of any IBM products that ship with GPL code. There are some that include Apache code.

Well, should IBM ever be interested in shipping the SIP Communicator with one of their products, their license preferences would most probably be taken into account. Yet, to my knowledge this is not the case for the time being. I imagine that your interest is driven by a need for an application to be used internally and in that case you could do all the changes you want to whatever you want and not release it, provided it stays internal. In the mean time it'll be quite hard to chose a license that suites all major companies and a bit naive to do it just because they might one day be interested in the SIP Communicator.

Of course, if you are aware of a license that provides both code protection and ease of commercial integration - I'd be happy to hear it.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#9

Emil Ivov wrote:

Hello John

I'm curious about the reasons for the change. What advantage does LGPL give to you compared to Apache?

Well, it requires any third parties to release optimizations they have made to existing core functionalities.

For reasons I am not too clear on, IBM considers "GPL/LGPL" as one category.

I see. Actually I've also read some articles more or less "against" LGPL, (like this one for example:
http://weblogs.java.net/blog/johnreynolds/archive/2005/02/a_cautionary_lg_1.html

). But we'd like to get more code protection than Apache v 1.1 could give us.

Another goal you might consider is maximizing contributions to your project.

I personally don't know of any IBM products that ship with GPL code. There are some that include Apache code.

Well, should IBM ever be interested in shipping the SIP Communicator with one of their products, their license preferences would most probably be taken into account. Yet, to my knowledge this is not the case for the time being. I imagine that your interest is driven by a need for an application to be used internally and in that case you could do all the changes you want to whatever you want and not release it, provided it stays internal. In the mean time it'll be quite hard to chose a license that suites all major companies and a bit naive to do it just because they might one day be interested in the SIP Communicator.

True, but GPL would prevent even internal use.

Of course, if you are aware of a license that provides both code protection and ease of commercial integration - I'd be happy to hear it.

You might have a look at "Toward true open source" By: Tom Walker
http://software.newsforge.com/software/04/07/15/163208.shtml

You also might take a look at the Eclipse Public License. It removes one sentence from the Common Public License. CPL was defined by the company I work for; nevertheless it offers a useful balance.

···

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#10

>
> Well, should IBM ever be interested in shipping the SIP Communicator
> with one of their products, their license preferences would most
> probably be taken into account. Yet, to my knowledge this is not the
> case for the time being. I imagine that your interest is driven by a
> need for an application to be used internally and in that case you could
> do all the changes you want to whatever you want and not release it,
> provided it stays internal. In the mean time it'll be quite hard to
> chose a license that suites all major companies and a bit naive to do it
> just because they might one day be interested in the SIP Communicator.

True, but GPL would prevent even internal use.

No, this is not a microsoft style EULA :slight_smile:
The GPL/LGPL and any other open source software licence are talk about
re-distribution of the code. As long as you use the code, you dont have
to redistribute anything. And more, you can use the code, and modify -
and link with any other code as you wish. Because this is the meaning of
open source. However, if you want to distribute your new program, than
you have to be very careful, to obey the licence, and distribute the
source also - of the entire program/library.

BR,
  Zsombor

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

JOHN J. BARTON wrote:

Another goal you might consider is maximizing contributions to your project.

Absolutely. That's what we're trying to achieve by moving to a plug-in oriented architecture.

True, but GPL would prevent even internal use.

Not true. As Zsombor already pointed out neither GPL nor LGPL specify any limitations on internal usage.

You might have a look at "Toward true open source" By: Tom Walker
http://software.newsforge.com/software/04/07/15/163208.shtml

The author makes some good points but I find the article a bit too generalizing. Open source is written by many different people for many different reasons. It is somewhat utopic to believe that all of them would feel fine with a public domain license (or lack there of).

You also might take a look at the Eclipse Public License. It removes one sentence from the Common Public License. CPL was defined by the company I work for; nevertheless it offers a useful balance.

Hm ... As much as I'd like it - we don't really have the community eclipse has neither its industrial support. We thought that LGPL would be good for us as it would allow commercial entities to use the software and write commercial/closed plugins (I was not aware that companies tend to put it in the same category as GPL) and yet not allow someone else to make a closed fork of the communicator, and compete with us. We need all the feedback we can get in order to provide a decent peice of software.

I am not against unrestrictive licenses at all but I believe that in this particual case, a small project as the sip-communicator would do better with a more restrictive one. I believe this could help us avoid having public attention split over the SC and the commercial clones it might have.

It is of course very probable that I may have it all wrong. Could you please give us some examples of a case where a CPL, EPL or any other BSD like license would do good to the project whereas LGPL would have made that impossible?

Comments from anyone else are moste welcome (come on guys - speak up. i don't want to find myself a couple of years from now cursing myself for chosing sth when everyone else seemed to prefer sth else).

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#12

Emil Ivov wrote:

JOHN J. BARTON wrote:

[snip]

True, but GPL would prevent even internal use.

Not true. As Zsombor already pointed out neither GPL nor LGPL specify any limitations on internal usage.

The limitation is built in to the GPL requirement that all code linked to it be open sourced. Lawyers see the (remote) possibility of a line of GPL being copied into a commercial product, leading to a lawsuit that drains the company assets causing everyone to lose their jobs. Yes, the chances are low, but the cost is high, so the risk is not negligable Internal us is ok with GPL not ok with IBM.

It is of course very probable that I may have it all wrong. Could you please give us some examples of a case where a CPL, EPL or any other BSD like license would do good to the project whereas LGPL would have made that impossible?

Projects succeed under all of these licenses; the only time I have seen projects fail because of licenses is when the license is one-off or unclear. Eclipse, Apache, Mozilla are all quite successful with commercial-use allowed licenses. The many flavors of GNU are also successful. They do attract different communities.

John.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#13

The limitation is built in to the GPL requirement that all code linked to it be open sourced.

Yup and this limitation does not exist with LGPL. That's the reason we are attracted by it. Anyway, I see what you mean. I guess that in LGPL too there are lines that lawyers don't like.

Lawyers see the (remote) possibility of a line of GPL being copied into a commercial product, leading to a lawsuit that drains the company assets causing everyone to lose their jobs. Yes, the chances are low, but the cost is high, so the risk is not negligable Internal us is ok with GPL not ok with IBM.

I get your point. Sigh. I guess you have that problem with all big companies where lawyers are obliged to generilize and label a license EVIL because it is unsuitable in, say, 60% of the cases and they couldn't possibly examine every particular case an employee needs code under such a license ...

But then, there is the dual licensing model! It would be probably best for sip-communicator.org to consider this model. MySQL and Asterisk seem to be doing it that way.

http://www.mysql.com/company/legal/licensing/faq.html

I know that for IBM (or alike) employees it would not be as easy to use it as a BSD-like one .... but it's better than nothing, isn't it.

Any thoughts?

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#14

Hello All,

   Thank you for your efforts to make the sip-communicator in a better shape... keep on !! I have just compiled the latest version of sip-communicator .. I have seen some errors while compiling on sun solaris (Java 1.5) ...
I thought to share this information with you so as not to stay hindered (like I was before) just because of compilation errors.

1- First error says .. your target is 1.5 and not 1.2 .. (so I changed this in the build file .. see line 271)
2- Second error says you have been using "enum" ... it looks as a reserved word in Java 1.5 .. (so I have renamed all occurences in the code .. which were 15 ).

Thanks

Amer

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Hello Amer,

1- First error says .. your target is 1.5 and not 1.2 .. (so I changed this in the build file .. see line 271)

2- Second error says you have been using "enum" ... it looks as a reserved word in Java 1.5 .. (so I have renamed all occurences in the code .. which were 15 ).

Yup noticed those ... will fix them soon (actually these are warnings and not errors aren't they? any way .. need to be fixed in either case)

Thanks for reporting
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Hello All,

   So far sip-communicator is not working for me .. !! I have this exception on both machines .. when trying to accept a call .. !! The exception appears on both UA's ... !!! Both machines have jdk 1.4 .... !! I want to run sip-communicator on jdk 1.4. Any one has an idea ??

net.java.sip.communicator.media.MediaException: Apparently all media descriptions failed to initialise!
SIP COMMUNICATOR won't be able to open a media stream!
  at net.java.sip.communicator.media.MediaManager.openMediaStreams(MediaManager.java:466)
  at net.java.sip.communicator.SipCommunicator.callStateChanged(SipCommunicator.java:758)
  at net.java.sip.communicator.sip.Call.fireCallStatusChangedEvent(Call.java:250)
  at net.java.sip.communicator.sip.Call.setState(Call.java:156)
  at net.java.sip.communicator.sip.CallProcessing.processInviteOK(CallProcessing.java:245)
  at net.java.sip.communicator.sip.SipManager.processResponse(SipManager.java:1754)
  at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:241)
  at gov.nist.javax.sip.EventScanner.run(EventScanner.java:357)
  at java.lang.Thread.run(Thread.java:552)

Before this I had another exception ... saying .. ilegal number of frames .. etc. so I changed the parameter for audio .. instead of 44100 .. I put 32000. I do not get this exception any more. Instead I get the exception .. above.

Thanks

Amer

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net