Problem being that without a license, nobody else is permitted to distribute your software. Depending on your and their local laws, they might not be allowed to copy or run it. And if the software causes any damages, you're quite likely liable for them. So, to protect both yourself and the recipient, always specify an explicit license.
The other part is that licenses need not be complicated. The Simplified BSD and MIT licenses are about as trivial as it gets: keep this label, and don't sue me bro. The GNU GPL is much longer, because it's approaching a harder problem: making sure that people who extend your software don't limit their users.
Quick correction: Unless I miss my guess, the API access setting also controls access from non-friends (e.g. network or arbitrary facebook user). So it probably ought to say "what types of information other people can see about you through their applications".
Would double-check that, but I apparently can't connect to FB right now. And, well, work.
Let me summarize that, just to make sure we're on the same page:
Alice friends Bob
Charlie writes an app
Alice installs Charlie's app
Charlie's app gets access to all of Alice's data, private or not
Charlie's app also gets access to all of Bob's information that Alice can see.
Charlie's app could record or disclose this information to people other than as allowed by the FB privacy settings.
This particular tempest seems to focus on the last point. If so, my initial comment should have been more caustic.
First, "limit what types of information your friends can see about you through applications" is mind-numbingly obvious. If friend (check) tries to see (check) my information (check) through an application (check), it will work: No (button).
Other usage of the information falls afoul of the application author's agreement with Facebook, and doesn't disclose more than the person running the application could anyway.
The fact that I gave someone a "friend" designation shouldn't mean that any application they run should be able to data mine my information without my permission.
Again, e-mails, IM profiles, web sites... any other time you give information to people, their applications could disclose it. Because, wait for it, APPLICATIONS RUN WITH THEIR PRIVILEGES.
Stop inventing scare scenarios about remote infection.
The problem is that such an app should not be able to see everything that user's friends have designated as private, because that app is not anyone's "friend".
Again, unlike real applications. Where the application gets all the access of the running user.
The Facebook apps shouldn't get higher privileges than actual human beings.
I see no indication that this particular piece of paranoia is true. Please point me to evidence that a friend's application can ever have more access than the friend does.
Now, a developer has written a Linux 'Utility' based on the Facebook paranoia, which graphically illustrates all the information a normal application can get its grubby little hands on. It opens your e-mail, and prints out all the stuff your friends have sent you. Then it opens your IM program, and prints out all your friends' profiles. And their web sites. And, like, OMG, the links to their favorite games they sent you!
Seriously folks. We're getting riled up over the idea that applications run with the privileges of their users? And that they can access the same data their users can? That this is somehow novel because it involves a few web services?
Stop. Please.
Enabling least-privileged security within FB would likely be pretty easy. Getting each app author to include a declarative description of the required information would probably be feasible. Actually communicating the requested information to end users would be a complete, utter, unmitigated nightmare. And don't even think about configurable levels of functionality, unless you want runtime errors out the wazoo.
I'll concede your point regarding inline code and (potentially) headers, although these are only relevant to compiled code - interpreted code would not be affected.
I missed that you were assuming the extending developer was not also distributing the dynamic library. Not sure that would change anything, as we still wind up arguing 'derivative work' vs 'mere aggregation'.
I would be surprised if object design and function organisation were covered by copyright. This would have a dangerous knock-on effect on those attempting to create an alternative API, for example.
Actually, I think we're dangerously close to agreeing. Given clean-room development, a bare procedural API has to be free of protected elements.
However, let's take something like a Qt application. Structure, UI, call flow, data types, etc. all use pieces from the library.
I strongly suspect that the application source would itself constitute a derivative work.
Which leads back to "if the internals of your application are dictated by a GPL'd library".
Suing users of a library, users that may not bound by its license (because the GPL prior to version 3 is not a use license) seems like a nasty thing to do.
Let's keep developers building atop GPL libraries separate from users. Users implies, well, use, rather than derivation and redistribution.
Extending copyright to interfaces is worse than software patents. If it becomes the accepted standard, you can say bye bye to software freedom.
Except that Copyright is weighted against accidental infringement, and comes with all sorts of fair use provisions. And that clean-room development is nothing new.
In short, this non-lawyer thinks you're entirely off base:)
Actually, I'd add three more categories to that: public domain, shareware, and in-house. The contract-bound proprietary is the most "normal", unfortunately.
If a closed-source program dynamically links with a GPL'd library, and that library isn't distributed by the developer, then it doesn't matter what the GPL says because no copyright infringement occurs.
Your assertion is probably incorrect. Headers, object design, function organization, and inline code are usually considered to be protected by Copyright. Derivative work does not have a magic switch for linking type: including protected content in your application creates a derivative work. I believe the FSF also disagrees with your interpretation.
The GPL is not a contract; it can only permit what is otherwise prohibited by copyright. What you're proposing is that the judge use the guise of 'intent' to extend the reach of copyright.
Actually, what I'm proposing is that you ask the authors before doing things likely to provoke licensing disagreements.
Some people share something freely, with the requirement that anyone building atop it does likewise. They're zealots.
Other people require you to agree to a contract before looking at their program. Disallow reverse engineering. Disallow redistribution. Disallow extension, enhancement, improvement, porting, circumvention. They're normal.
Quite aside from the legal meaning of the GPL, you could always ask the authors what they intended. If they want to prevent proprietary applications from using the library, as promoted by , that should influence your decision.
IMO, if the internals of your application are dictated by a GPL'd library -- *regardless* of how that library is linked, integrated, called, or plugged in -- your application is a derivative work. To separate them, put the library aside. Do a proper design. Gather scenarios you need the plugin to support. Document them. Write a new API. Document it. Collect some alternative libraries. Verify that you were not unduly influenced by the GPL'd one.
Whenever one of these articles comes up, I'm always curious about maximums for:
- active accounts
- concurrent users
- concurrent users per server
- interacting users
It seems to me that we should differentiate between multiplayer and massively multiplayer based on the last one. And on the degree of interaction. After all, a bunch of single-player games and a chat box isn't an MMOG... I hope.
Re:Authentication goes both ways.
on
R.I.P. FTP
·
· Score: 1
Yes, yes, we all see your geek card. Now stop waving it around.
Manually verifying fingerprints is the kind of voodoo which utterly and completely fails to protect normal users. In fact, I was probably being too optimistic to imply that key conflict warnings would deter unsafe behavior.
Apply a trivial malware DNS hijack. Against a full-blown PKI. And we're still screwed, because most users don't understand the threat, and click through warning after warning.
Re:Authentication goes both ways.
on
R.I.P. FTP
·
· Score: 2, Informative
Most SSH clients will verify that you are connecting to the _same_ server as last time. However they can not verify the actual identity of that server.
(Well, server with the same key as last time you connected to that domain name or IP, but close enough)
Can you clarify this? I've written several programs that generate IL (including one full-blown compiler for a JavaScript-like language) and I don't recall having to do any gymnastics.
I suspect you are sticking to the sane subset.
Generating code for structs requires care. Generating code for generics is downright tricky. And generating code for generic transparent proxies of combinations of generic interfaces made me want to throw chairs.
Glad you're having a better experience. I'm still going to avoid the wall 'o text necessary to hammer everything in detail, so please forgive my terseness. Everything qualified by "last time I used it":
Dynamic code on.NET CE, especially involving generics, fails in many entertaining ways. It's comparable to Java ME, but with more silently-wrong behaviors.
Auto properties fail completely in structs, and can't be used as ref or out parameters. No way to implement only one accessor. No way to hook in change notifications. So basically, nice placeholders until you get to writing the real code.
Aliasing causes many hilarious logic errors. Doubly so when multiple threads are cooperating.
Which might be why the grizzled C++ coders pay attention to it...
You've got exceptions, you get partial execution. You've got reference parameters, you've got side effects. Well, barring doing all the assignments at the bottom of the method. Which defeats the purpose of the syntactic sugar.
Actually, the IL gymnastics mostly get pushed into Microsoft's court. The compilers spit out the easy subset, and the.NET runtime then tries to optimize it. This is a far harder problem than native-compiling Java bytecode, so I have some sympathy for the epic failure.
So yes, disaster. Tremendous effort invested to solve problems in Java. Then more effort to solve the problems from those solutions. Each round piling on more complexity. As much as the sluggish JCP annoys me, they *do* know when to say no.
In part I agree with you. In designing C# (and.NET in general), Microsoft correctly identified a lot of the hiccups of Java development.
Unfortunately, IMO, their solutions were a disaster.
Erasure-based generics are annoying, but the CE-incompatible hacks of runtime generation are worse. Writing getter/setter for trivial properties is annoying, but limited and buggy syntactic sugar is worse. Having all objects be pointers is annoying, but making structs silently stack-allocated is worse. Needing to use arrays to fake reference parameters is annoying, but side-effects on partial execution are worse. Having to scrunch different languages in to a Java-tailored bytecode is annoying, but the gymnastics required by MSIL are worse.
And it's not like we (or the GP) are asking for a lot. We're not asking them to be expert software engineers. Basic programming skills like that should be trivial for anyone in CS/CE/IS/EE. Hell, I'd expect most ME and CE students to be able to do simple programming like that these days, especially if you didn't care about the language they did it in.
Should be, I agree. Yet combining a technical specialty with basic coding leaves one recruiting from a very limited pool.
Even when that technical specialty is coding, it seems a pretty small pool.:)
Slashdot Mirror
Not a lawyer. IMO.
Problem being that without a license, nobody else is permitted to distribute your software. Depending on your and their local laws, they might not be allowed to copy or run it. And if the software causes any damages, you're quite likely liable for them. So, to protect both yourself and the recipient, always specify an explicit license.
The other part is that licenses need not be complicated. The Simplified BSD and MIT licenses are about as trivial as it gets: keep this label, and don't sue me bro. The GNU GPL is much longer, because it's approaching a harder problem: making sure that people who extend your software don't limit their users.
Quick correction: Unless I miss my guess, the API access setting also controls access from non-friends (e.g. network or arbitrary facebook user). So it probably ought to say "what types of information other people can see about you through their applications".
Would double-check that, but I apparently can't connect to FB right now. And, well, work.
Let me summarize that, just to make sure we're on the same page:
This particular tempest seems to focus on the last point. If so, my initial comment should have been more caustic.
First, "limit what types of information your friends can see about you through applications" is mind-numbingly obvious. If friend (check) tries to see (check) my information (check) through an application (check), it will work: No (button).
Other usage of the information falls afoul of the application author's agreement with Facebook, and doesn't disclose more than the person running the application could anyway.
The fact that I gave someone a "friend" designation shouldn't mean that any application they run should be able to data mine my information without my permission.
Again, e-mails, IM profiles, web sites... any other time you give information to people, their applications could disclose it. Because, wait for it, APPLICATIONS RUN WITH THEIR PRIVILEGES.
Stop inventing scare scenarios about remote infection.
The problem is that such an app should not be able to see everything that user's friends have designated as private, because that app is not anyone's "friend".
Again, unlike real applications. Where the application gets all the access of the running user.
The Facebook apps shouldn't get higher privileges than actual human beings.
I see no indication that this particular piece of paranoia is true. Please point me to evidence that a friend's application can ever have more access than the friend does.
Now, a developer has written a Linux 'Utility' based on the Facebook paranoia, which graphically illustrates all the information a normal application can get its grubby little hands on. It opens your e-mail, and prints out all the stuff your friends have sent you. Then it opens your IM program, and prints out all your friends' profiles. And their web sites. And, like, OMG, the links to their favorite games they sent you!
Seriously folks. We're getting riled up over the idea that applications run with the privileges of their users? And that they can access the same data their users can? That this is somehow novel because it involves a few web services?
Stop. Please.
Enabling least-privileged security within FB would likely be pretty easy. Getting each app author to include a declarative description of the required information would probably be feasible. Actually communicating the requested information to end users would be a complete, utter, unmitigated nightmare. And don't even think about configurable levels of functionality, unless you want runtime errors out the wazoo.
I'll concede your point regarding inline code and (potentially) headers, although these are only relevant to compiled code - interpreted code would not be affected.
I missed that you were assuming the extending developer was not also distributing the dynamic library. Not sure that would change anything, as we still wind up arguing 'derivative work' vs 'mere aggregation'.
I would be surprised if object design and function organisation were covered by copyright. This would have a dangerous knock-on effect on those attempting to create an alternative API, for example.
Actually, I think we're dangerously close to agreeing. Given clean-room development, a bare procedural API has to be free of protected elements.
However, let's take something like a Qt application. Structure, UI, call flow, data types, etc. all use pieces from the library. I strongly suspect that the application source would itself constitute a derivative work.
Which leads back to "if the internals of your application are dictated by a GPL'd library".
Most of that property smells funny and is full of bugs. They probably should be giving it away :)
Ah, the freedom to deny others freedom. I value everyone's freedom to learn and extend more.
Suing users of a library, users that may not bound by its license (because the GPL prior to version 3 is not a use license) seems like a nasty thing to do.
Let's keep developers building atop GPL libraries separate from users. Users implies, well, use, rather than derivation and redistribution.
Extending copyright to interfaces is worse than software patents. If it becomes the accepted standard, you can say bye bye to software freedom.
Except that Copyright is weighted against accidental infringement, and comes with all sorts of fair use provisions. And that clean-room development is nothing new.
In short, this non-lawyer thinks you're entirely off base :)
Actually, I'd add three more categories to that: public domain, shareware, and in-house. The contract-bound proprietary is the most "normal", unfortunately.
If a closed-source program dynamically links with a GPL'd library, and that library isn't distributed by the developer, then it doesn't matter what the GPL says because no copyright infringement occurs.
Your assertion is probably incorrect. Headers, object design, function organization, and inline code are usually considered to be protected by Copyright. Derivative work does not have a magic switch for linking type: including protected content in your application creates a derivative work. I believe the FSF also disagrees with your interpretation.
The GPL is not a contract; it can only permit what is otherwise prohibited by copyright. What you're proposing is that the judge use the guise of 'intent' to extend the reach of copyright.
Actually, what I'm proposing is that you ask the authors before doing things likely to provoke licensing disagreements.
I've always found that position funny...
Some people share something freely, with the requirement that anyone building atop it does likewise. They're zealots.
Other people require you to agree to a contract before looking at their program. Disallow reverse engineering. Disallow redistribution. Disallow extension, enhancement, improvement, porting, circumvention. They're normal.
Dude, what?
Pardon, fumbled the link.
Why you shouldn't use the Lesser GPL for your next library
Quite aside from the legal meaning of the GPL, you could always ask the authors what they intended. If they want to prevent proprietary applications from using the library, as promoted by , that should influence your decision.
IMO, if the internals of your application are dictated by a GPL'd library -- *regardless* of how that library is linked, integrated, called, or plugged in -- your application is a derivative work. To separate them, put the library aside. Do a proper design. Gather scenarios you need the plugin to support. Document them. Write a new API. Document it. Collect some alternative libraries. Verify that you were not unduly influenced by the GPL'd one.
Or, you know, GPL the application.
Whenever one of these articles comes up, I'm always curious about maximums for:
- active accounts
- concurrent users
- concurrent users per server
- interacting users
It seems to me that we should differentiate between multiplayer and massively multiplayer based on the last one. And on the degree of interaction. After all, a bunch of single-player games and a chat box isn't an MMOG... I hope.
Yes, yes, we all see your geek card. Now stop waving it around.
Manually verifying fingerprints is the kind of voodoo which utterly and completely fails to protect normal users. In fact, I was probably being too optimistic to imply that key conflict warnings would deter unsafe behavior.
Apply a trivial malware DNS hijack. Against a full-blown PKI. And we're still screwed, because most users don't understand the threat, and click through warning after warning.
Most SSH clients will verify that you are connecting to the _same_ server as last time. However they can not verify the actual identity of that server.
(Well, server with the same key as last time you connected to that domain name or IP, but close enough)
Not unless trade schools suddenly get better, and software engineering programs suddenly become ubiquitous.
And not while most students learn better by implementing parts of the theory. And not while employers expect them to be half-competent coders.
And, well, not :)
Can you clarify this? I've written several programs that generate IL (including one full-blown compiler for a JavaScript-like language) and I don't recall having to do any gymnastics.
I suspect you are sticking to the sane subset.
Generating code for structs requires care. Generating code for generics is downright tricky. And generating code for generic transparent proxies of combinations of generic interfaces made me want to throw chairs.
Glad you're having a better experience. I'm still going to avoid the wall 'o text necessary to hammer everything in detail, so please forgive my terseness. Everything qualified by "last time I used it":
Dynamic code on .NET CE, especially involving generics, fails in many entertaining ways. It's comparable to Java ME, but with more silently-wrong behaviors.
Auto properties fail completely in structs, and can't be used as ref or out parameters. No way to implement only one accessor. No way to hook in change notifications. So basically, nice placeholders until you get to writing the real code.
Aliasing causes many hilarious logic errors. Doubly so when multiple threads are cooperating. Which might be why the grizzled C++ coders pay attention to it...
You've got exceptions, you get partial execution. You've got reference parameters, you've got side effects. Well, barring doing all the assignments at the bottom of the method. Which defeats the purpose of the syntactic sugar.
Actually, the IL gymnastics mostly get pushed into Microsoft's court. The compilers spit out the easy subset, and the .NET runtime then tries to optimize it. This is a far harder problem than native-compiling Java bytecode, so I have some sympathy for the epic failure.
So yes, disaster. Tremendous effort invested to solve problems in Java. Then more effort to solve the problems from those solutions. Each round piling on more complexity. As much as the sluggish JCP annoys me, they *do* know when to say no.
In part I agree with you. In designing C# (and .NET in general), Microsoft correctly identified a lot of the hiccups of Java development.
Unfortunately, IMO, their solutions were a disaster.
Erasure-based generics are annoying, but the CE-incompatible hacks of runtime generation are worse. Writing getter/setter for trivial properties is annoying, but limited and buggy syntactic sugar is worse. Having all objects be pointers is annoying, but making structs silently stack-allocated is worse. Needing to use arrays to fake reference parameters is annoying, but side-effects on partial execution are worse. Having to scrunch different languages in to a Java-tailored bytecode is annoying, but the gymnastics required by MSIL are worse.
Every time someone posts a stupid correlation versus causation argument on Slashdot, I want to smack them.
I call this the violence-inducing-argument hypothesis, because suggesting causation would just encourage them.
LaTeX already got mentioned, and probably makes more sense.
If you really want an unreadable super-general XML-based format, use ODF.
And it's not like we (or the GP) are asking for a lot. We're not asking them to be expert software engineers. Basic programming skills like that should be trivial for anyone in CS/CE/IS/EE. Hell, I'd expect most ME and CE students to be able to do simple programming like that these days, especially if you didn't care about the language they did it in.
Should be, I agree. Yet combining a technical specialty with basic coding leaves one recruiting from a very limited pool.
Even when that technical specialty is coding, it seems a pretty small pool. :)