What amuses me is that most of the replies are "How to bypass the GPL so I won't have to give away the source"
Then we have threads against the GPL in other posts and how BSD is great because its morefree and that has nothing to do with "being able to keep the modified source".
Well if the author decided to make it GPL one should respect the choice of the author, on top of not being unethical capitalists.
The code should be made available. It doesn't actually have to be distributed with or "attached to" the product. The option to post the download link elsewhere or available on CD for media cost only.
Don't forget that web services are a great way around the gpl. Just slap a subscription fee on there and don't distribute the server-side code and you can do whatever you want with it and/or charge whatever you want for it without being in violation or giving a competitor a chance to copy you. worked for Google.
gpl client-side code of course you cannot protect in this way (except your trademarks).
this is an important distinction. Everything on the web is copyrighted and you can't just go and grab images/html/css/javascript without permission from the copyright holder.
And view source isn't going to show you much when looking at sites like Gmail where the code is generated by a compiler that makes it as obtuse and unreadable as machinely possible.
GPL requires that users have access to the preferred form for modifying the work. If you're using coffeescript or a state machine graph or whatever, the generated javascript is more like object code than maintainable source.
There was a draft of GPLv3 that included such a clause. This was dropped with the development of Affero GPL license. The final version of GPLv3 dropped all language regarding web services. If you want to use a GPL-like license for a web application, then the AGPL is the license to use.
Any open source software (gpl3, gpl2, bsd licence, mit licence etc etc) cannot be distributed in a commercial or noncommercial manner without also providing the source code. (there are some other requirements aswell as this, notably with GPL that your software must be GPL licensed aswell.).
There is nothing special in any open source/free software licence about commercial vs noncommercial use. All OS/FS treat commercial and noncommercial the same.
As for requiring source code distribution, the GPL 3 is essentially the same as the GPL2 (which is ~20 years old), you have to do it under gpl2 and you have to do it under gpl3.
The MIT and BSD licenses do allow distribution inside of commercial software without providing source code. The only real restrictions are that the MIT license requires you to include their copyright notice somewhere and the BSD license is similar.
I believe the ZLIB license also permits commercial distribution.
Off the top of my head it's only the GPL licenses that require source distribution no matter what.
False.
The whole point of the bsd license is that you are not required to make source available, but that if you do that you need to preserve the bsd notices about the copyright of the orIginal code. I'm over simplifying slightly but gpl is the one with the mandatory code resharing. MIT and bsd do not have that
I might be a bit wrong here, esp. with BSD. :P Mea cupla.
I know that BSD, unlike GPL, does not require that derived code be BSD licenced. And when I was talking about "source code" I was thinking of the original code (not the derived work), but I was wrong about BSD not requiring that you provide the source. Many big users of BSD code (e.g. Apple) provide the BSD source code they use, so I thought it was required.
However, for GPL, "commerical" vs. "noncommercial" is irrelevant.
What? No. You can distribute binaries you compiled from open source code that is licensed under the MIT or BSD licenses, in both commercial and noncommercial contexts. Read the license text, they only require you to include the license with your distribution. Not the source code or any of your modifications.
There are 2 main VOIP protocols right now you can choose from. H323 and SIP. H323 was developed my the telecom industry and its a binary format so its more of a pain in the ass to develop form.
SIP looks like HTML where all the commands it uses, like to register, call, hangup, add someone to the conference, all are in ASCII and are human readable.
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
If you were looking at the data of a SIP REGISTER it would look just like that, whereas H323 would just be a bunch of crazy gibberish without the proper decoding.
What it gains in readability it looses through its typical consortium designed over engineered standard. Same old feature bloat. Just skip to the point where it discusses NAT.
It's one piece of the technology you need to run an VOIP phone service. You could use this, for example, as a building block to get push-to-touch voice livechats on your site.
Idea: Do not use ICE for NAT traversal (it will not always work). Do not use a public SIP server controlled by a third party (ever heard of spam?). Traverse NAT by getting a reachable IP address and running a supernode on it. Run your own _private_ SIP server (e.g. for just friends and family).
It's neat that this can all be made to run in the browser. But keep in mind that one company may end up with monopolistic control over the browser. It's certainly looking like this could happen. Again.
All this stuff runs just fine outside the browser. Supernode and SIP server can run as daemons.
This itself does not provide the mic-capturing technology. That is provided by WebRTC, which this is built upon, and is quickly being implemented by all browser vendors except Apple and Microsoft.
Yes, with the webmedia audio object (maybe present in chrome 20). A dialog bar will appear asking the user if they want to allow access from javascript for their audio (and video) devices. There's some good examples on google+ search for webRTC channel
If you count all of the new javascript APIs as part of HTML5, which most people do, then it is true that you can capture mic input with webRTC which is part of "HTML5".
That syntax came from MIME and has been present in email, newsgroups and the web for as long as I can remember. The server sends content-type headers delimited with MIME attributes, the browser sends accept headers and inside the pages one will often find a meta tag with its content attribute delimited that way.
Anyway this thing relies on javascript too, which I thought was a stretch to call 'pure html5'...so depending on your needs, Flash (which can use mic input) might be just as acceptable as javascript...then again, it might not be.
This is what I did on my dev Chrome to enable WebRTC:
- Type "about:flags" on the address bar and press enter
- Enable the "Enable MediaStream" option
- Click on the "Relaunch now" button at the bottom of the screen
video is actually available as is file sharing. this opens myriads of opportunities (or rather: now we can do with HTML5 what we could do with flash 2 years ago.)
FaceTime on the web is the new black. I been following closely webRTC and this is it. Ride the wave, it'll be pervasive, some will even make money with it. Face to face customer service? Video conferencing? Doctors appointments? Livecasting? Sports? Events?
Downside is, if everybody starts live-casting an apple event, the web will go down in flames.
Ok, but it's just the same things that we could do for some years with Flash. What will change? Before was Flash, now is HTML5? So, what? Just technology? Many users does not notice even what technology you are using
Doesn't Flash webcam video or streaming require proprietery Flash streaming servers that are quite costly? Not to mention probably no longer (actively) supported.
It's doing the same thing, but in a very different way. Flash video uses ancient, terrible codes; requires proprietary Adobe servers (although there's been some good work on this from Wowza, Red5, et al); doesn't use open protocols like SIP.
What will change? Maybe nothing, but it's definitely interesting work. One could, for instance, use this as the endpoint of a SIP PBX without serious effort, which is not the case for a Flash endpoint.
More like non-standardized parts which currently are working drafts only.
But seeing how just saying "this is standard HTML, really!" again and again and again worked for the What WG, I guess there is nothing wrong in browser-vendors attempting to do the same to get their proprietary extensions embedded into the standard as well. At least it's not much worse.
http://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2...