Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Building a commercial product may use various open source libraries that have use of other libraries. In an ideal world you would know which licenses they use and whether it is safe to use them.
However, if you use an open source product (or commercial can apply here also) that is in breach of licensing and you don't know about it how does this affect what you do?
So for example I use Product A that uses a licence than means product A and anything that uses it has to be open source. However Product A has breached the rules but hidden the fact.
Now this means my product is also supposed to be open source but I have no idea it should be. Can i be in breach of the license even though I don't know I am?
As it happens I am customizing a EULA for a commercial software component (using a template from a Legal firm) and I found this clause in it
(b) that the use of the Software by the Licensee in accordance with the terms of this EULA will not infringe the Intellectual Property Rights of any third party;
What I would do is scour the license of the component you are using as you may find this clause. If so (Im not a lawyer and this does not constitute legal advise), you may be able to reasonably assume that so long as you are complying with the license of the component you do own, you will not infringe the license of any component you do not own.
I'm not a lawyer (tm), but I'd say that you are responsible, of course. If you use a product A that uses another product B, you must know about that fact that B is used and also you must know about the licensing terms of B, as - effectively - you're using B yourself.
But that's just what I'd expect...
Licensing is like a chain. If for example one component makes use of some other work in an unlicensed way, the whole chain is broken, the other work can not be rightfully licensed to others.
For copyright it does normally not depend whether you know what you're doing or not. Sounds harsh, just saying upfront as you asked for commercial distribution.
If you create a work, you should do what that requires:
Locate all third party code you make use of.
Locate all binary blobs.
Catalog the components.
Find out who hold copyright and under which license each compontent is available, retrieve the licenses and store them with the software (if the software does not ship with the actual license text, document from where and why you've stored the texts).
If it's not clear under which license a component is available, contact the coypright owner/author. You should prefer written communication.
Verify that you full-fill the requirements of each license.
Verify that all components are license-wise compatible with each other.
I think doing this pro-actively is important because otherwise you can't argue that you did not know if you can't document what you did know. It would be just meaning that you didn't want to know which hardly can't offer any sort of protection. To which level you need to find out about an identifiable component I would say it depends (saying: How far you need to take this).
Ask your lawyer and do some risk analysis: You might not be legally obligated to check that subcomponent A which makes use of A-B and A-C has properly checked for the right of these two components. But in case it turns out that A-B was violated and A is not rightfully licensed to you regardless what the licensor of A told you, you can still loose any usage rights for A-B which could turn out that you must drop A. So for critical components you might want to do more than the law requires you to do.
In a commercial context "assuming" might be counter-productive. Ask your lawyer about that.
The work to clarify copyrights and licenses, it's progress as well as the underlying processes should be documented. You should also look for legal help with such processes as if you run into conflicts (and software licensing can be complicated) you need to legally discuss what you have as well. Depending on which components you use, expect this to be quite some work.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
When I sell software I've written I send the customer a End User License Agreement that I got from a draft template on the web (see link below). One large customer I recently worked with has contacted my as they say this is just a EULA and not a license. What is the difference?
http://www.developer-resource.com/sample-eula.htm
Thanks for the help.
Jay
An End-User License Agreement (EULA) is a contract between the copyright holders and the user. It requires the user to agree, usually by clicking "I agree". Think of it like a contract: "if the user promises to do X and Y, I promise to grant you permission to use this software".
A license (especially open source licenses) do not require the user to agree to it. They strictly give the recipient of the software additional rights. Think of it like a declaration of additional permissions: "I grant you the permission to copy and modify this software".
If you've ever installed an open source operating system like Debian, you'll notice that you never have to click "I agree", not even once. This is because the free and open source licenses of the software included in Debian automatically grant you the right to copy and use the software, you don't have to agree to do anything in exchange.
EULAs, on the other hand, do require you to agree first, which usually means you are giving up a right in exchange. They have been known to contain some pretty outrageous clauses (for example, Sony required users agree not to bring class-action suits to court against Sony). However, it is disputed whether EULAs are actually legally enforceable in all cases.
IANAL but in my opinion, the license would state the limitations of their ownership of their copy of the software. I think a EULA better describes the limitation of the proper use of the software and your liability or lack there of based on the use of the software.
I.E. a license won't say "don't use this to hack somebody" while a EULA would say "we're not responsible if you use this for malicious purposes." Likewise the EULA might not mention who in the company is allowed to use it, but a license can say things ranging from "5 developers in your company" or "any developer employed by you" or whatever limitations you want to apply.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've started to write a file format specification for a domain-specific data type. My goal is to improve interoperability between a large number of data providers and search algorithms. I want the result to be available for use, patent-free and without distribution fees.
I'm looking for advice on which license to use, both for the specification and for the contributor agreement, if I need one.
If this were software then I know enough about the GPL, MIT, etc. licenses to make an informed decision. If this were a straight document then I would pick one of the Creative Commons licenses, likely CC by attribution.
Looking around, I don't find any common license statement or much in the way of advice. I'm leaning towards the one used in RFC (for example, the HTTP/1.1 copyright statement) but that says "this document itself may not be modified in any way" (with exceptions), which is something I'm not used to from developing code under the MIT and GPL licenses. But that restrictions seems pretty common in specifications.
Unlike most documents but like code, specifications can be affected by patent. Is it best practices these days to also state that the specification is patent-free and require any contributors to reveal any patent conflicts they may know of and/or freely license those patents for the purposes of implementing the spec?
Should I require some sort of contributor agreement?
Or should I just wing it, choose the RFC copyright statement (or CC-By-Attribution), and not worry about this?
"this document itself may not be modified in any way" (with exceptions) [...] But that restrictions seems pretty common in specifications.
Actually, it is pretty much a requirement. If anybody could change it at will, it wouldn't be much of a specification: that would defeat the whole purpose to "improve interoperability between a large number of data providers and search algorithms".
Dalke: Is it? I'm so used to implementation-defined and ad hoc format definitions and people who break the spec left and right that I didn't think it would add anything, and protection would hinder future extension if I decide to not continue maintaining the code. I thought conformance was better handled by trademark law, like how DRM-based CDs which violate Phillips' Red Book can't use the "CD" logo.
[...] which is something I'm not used to from developing code under the MIT and GPL licenses
Actually, you are used to it, you just don't realize it: the whole reason why you were able to just write the three letters "GPL" above and blindly assume that everybody knows precisely what you mean, is because the GPL itself contains exactly that same restriction. ("Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.") The GPL itself is not distributed under a Free License, precisely because if anybody where allowed to modify it, it would lose its meaning.
Dalke: You're right, although the GFDL's "invariant section" sprang immediately to mind when I was considering the possibilities. I will point out that people do things in the license grant which modify the terms of the GPL to, among other things, make it non-free, and I've personally modified the three-clause BSD license to scratch out Berkeley and put in my name, but those are quibbles.
Is it best practices these days to also state that the specification is patent-free and require any contributors to reveal any patent conflicts they may know of and/or freely license those patents for the purposes of implementing the spec?
Yes. It is clear from your question that you care a great deal about making the barrier for implementors as low as possible. Then, what good is a free, open, royalty-free specification if I have to pay for a patent license anyway? This has to be addressed, preferably by an IP/patent lawyer with extensive expertise in such questions (including, but not limited to, the specific challenges that open source projects face with regards to patent licensing).
There are some quite subtle pitfalls in there. For example, one common theme is to require that patent licenses be made available under what is usually called FRAND (or RAND) terms, which stands for fair, reasonable and non-discriminatory. Which sounds good, right? Except there's a subtle problem there: charging 1 cent for every copy is certainly reasonable and if you charge everybody the same amount, it's also fair and non-discriminatory. Except that open source projects (and even freely distributable proprietary ones) cannot enforce those terms, therefore they cannot implement the specification.
Dalke: Very true. But for licenses that's a well described topic. There are reams of text on the matter, and suggestions, and podcasts, and even automated license choosers. For specifications, not so much. I did know about the RAND issue, and I've heard stories about other spec where a contributor at the end said "Oh! Look at that! We've got a patent on it. Well lucky us!" A question is how much I should worry about it.
So, proper patent promises or covenants or whatever you call them, are very important. (As are trademarks, by the way.)
For example, the W3C originally wanted to adopt a RAND license for its specifications, but after significant protests from projects such as Mozilla and Apache, they decided upon a royalty-free model. So, even an organization which cares deeply about freedom and openness almost made a mistake with the potential of killing every single open source web browser, feedreader and XML parser.
Or should I just wing it, choose the RFC copyright statement (or CC-By-Attribution), and not worry about this?
"Winging" important legal decisions is how people end up bankrupt or even in jail. Or at least extremely unhappy. While the first two are pretty unlikely in this case, I assume that you will be unhappy if you find out in two years that your specification is completely useless because of a glitch in its patent/copyright/IP legalese.
Dalke: I knew that word would be a draw. ;)
There are legal firms that specialize in pro bono work for non-profit developers of open source projects; maybe one of those will help you. The most well-known ones are probably the Software Freedom Law Center (SLFC) in the US and the Institut für Rechtsfragen der Freien und Open Source Software (ifrOSS) in Germany.
And whaddaya know, the fourth news item on the ifrOSS homepage is about the Open Web Foundation Agreement, which is a license template by the Open Web Foundation specifically for open, non-proprietary community-driven specifications for web technologies.
Dalke: Thanks. I'm in Sweden, so I wonder how well those resources will apply to me. Looking at the OWF I see it's US-based but it tries hard to be international, and I see one thing I don't like; the requirement for attribution. It does look like they are the people to talk to. Thanks for the pointer!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This is the only product that I know that a consumer must agree to something that only lawyer can (something) understand. I'm sure car accidents kill more people each year than software accidents. But I don't sign anything like an EULA when I buy a car.
So why does software have EULA? Were there a bad accident that triggered the need for software companies to protect themselves? (and what was the first software that had EULA?)
[Update] Just to clear my point: I don't understand why software have EULA. No other product that I can think of does (not even gun)! So what makes software different that this product needs some sort of "liability limitations"?
By the way, Wikipedia says that "The legal status of shrink-wrap licenses in the US is somewhat unclear."
The difference is that you are purchasing a license to use software, not the software itself (which the software company still owns). The EULA stipulates the method with which you can use the software. Similar agreements are in place when you rent things (e.g. a home), lease equipment, etc.
An EULA is designed to be a contract that conveys or limits “usage” rights, hence the name End User Licensing Agreement. It has nothing more to do with a copyright than the mortgage loan contract that I have with my bank. That is why the legality of shrink-wrapped licenses is questionable. It is a contract that you do not get to read until after you purchase a product. It is clear from many responses here that the vast majority of people have not wrapped their heads around the idea the copyright does not extend to “usage” rights.
One responder wrote “Actually, the book is yours but the rights to the book are not. Just as in software, you purchased the physical media, but are bound by law on how you can use it.” Nothing could be farther from the truth. There is no law that restricts how you can use the book. Any restriction on usage would have to be agreed upon by you and the retailer as part of the sale.
Consider that in the absence of copyright, the copying and distribution of books would be perfectly legal. A book would be typical tangible property and nothing more. Copyright limits your ability to legally copy and distribute the content of the book. No additional agreement is necessary. Copyright in no way dictates how you can use your book and copyright law does not convey to the author the power to convey, limit, or negotiate “usage” rights. The only way that they can limit usage rights is through a separate contract that would have to be completed as part of the sale or rental.
There was some confusion regarding the GPL. The GPL is not an EULA. It is a copyright license that permits copying and distribution of the content so long as you comply with the restrictions of the license. In absence of the GPL (say you choose not to accept it), you can still use the software, but you are restricted from copying or distributing the software by Copyright Law.
EULA exist for various purposes. Companies that develop software want to negotiate a position that puts them at the least risk and gives them maximum leverage.
If a consumer receives software without any license, consider what they might consider their rights:
They may believe they can copy the software, as many times as they want.
They may consider re-selling the software, and still keeping a copy for them self.
They may believe the software must work perfectly, with zero bugs (as they understand a bug)
They may believe it is fully waranteed against any perceived defect, and try to return it, for a full refund, at any point in the future.
In short, the EULA disabuses consumers of these notions. It defines ownership and copyright of the software, limits on its use, distribution, features, and quality.
Now it is true that as lawyers get involved in the EULAs more and more, stranger and stranger provisions creep in, such as provisions that you cannot review the software on a blog, or you cannot bad-mouth the software to the press, or that the publisher owns content created with the software.
But fundamentally, the EULA is supposed to be about the producer and the consumer coming to an understanding of what is, and is not, an acceptable use of the software.
Actually, what is quite funny, in Germany EULAs are pretty much legally-non binding, since you only get to see them after the purchase, so for us the answer to your question is:
To intimidate the user from doing stuff the company does not want
There are basically three reasons for EULAs:
Software is much more copyable than any other product I can think of. It is almost never left on its distribution medium. That creates a huge temptation to, for example, buy one copy of Windows and install it on all of a company's thousand computers. Developers want to explicitly lay out how many computers the software may be installed on.
Software often has undetected problems. Even the best QA department never finds all the bugs in a software product. Developers know this and want to be legally covered.
Software can often be easy to take apart to discover a developer's trade secrets or other information the developer doesn't want others to know. Developers want to legally restrict this to protect their advantage over competitors.
Of course, there are sometimes other reasons for other terms. EULAs for Apple's Mac applications, for example, usually state that you can only install the software on an Apple-branded computer; this ensures that Apple's software (which is usually sold much cheaper than it would be from any other developer) increases sales of Apple hardware. The GNU GPL tries to ensure that the innovations in derivative software remain available to the community that developed the original. There are as many reasons as there are clauses.
It depends on the exact wording of the EULA. Often, it's written to reinforce existing laws, such as copyright, by directly informing the user that it's unlawful to copy the program. It also adds on other restrictions such as no reverse engineering, restricting the intellectual property.
Additional clauses may include "not to be used in nuclear projects" or similar. This is merely covering the developer's bases, as it is extremely unlikely that a nuclear system developer would use a non-realtime, non-approved system without extreme amounts of research.
A further clause could restrict certain classes of users, such as military or government, which the developer feels strongly against.
As for which software had the first EULA, I have no idea.
Cars and guns technically have something like a EULA... we just call them "licenses". You have to learn the limitations and rules of their operation, then take some tests and sign some papers.
Nobody has mentioned the obligations of the provider, which are often in the EULA too. If I make your software a critical piece of my corporate infrastructure and you go bust I want to be able to get my hands on the code so your failure doesn't precipitate mine.
As someone said, this is more akin to a rental agreement than a purchase agreement, which is why the analogy with a gun does not really apply.
For proprietary software, License tells about your right to use specific software copy and impossibility to re-sell it, also your and software authors rights and charges
For open source software, License also tells about your right and charge about source code (distribute, do not do that, do that with limitations)
When you use a gun at a firing range, don't you have to sign some type of release or waiver? The logic is similar.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have always included clauses to transfer to my clients full author, ownership and use rights for all the source code, original images, original resources, etc. I develop/create for them.
Of course, I retain author, ownership and use rights for my libraries and I usually do not include source code for those. If the client requires my library’s source code, then I ask a premium for those and I provide them with the proper use license and I include the needed restrictions on allowed use.
I really see not the need to retain rights for myself or my company. A client’s work is just for them. I never reuse code (even if I have to write some process again, I do not see it as code reuse).
Why lots of companies/programmers retain author, ownership on commissioned work?
If one client commissioned it, chances are others will find it valuable as well. Often, developers will retain ownership so that they can exploit later opportunities. Alternatively, they might charge more in exchange for relinquishing rights to the work.
There might be a number of reasons for this. The most common one would be leverage. If part of the application you develop has broad applicability, the you might be able to retarget substantial parts of the solution to other clients. This would achieve one of two things: Shorter time to market which would imply a lowest cost for the client, or on fixed bid projects, bigger margins for you.
Another case could be to protect yourself. Your example itself is somewhat of a case study. You give the client the full rights and source to the work you do for them, but you retain the rights to your libraries, they pay extra, etc...
Depending how the contract is actually worded, if you use "your" libraries as part of the final deliverable, wouldn't that be work you actually create for them. If you did not include those libraries, would they still have a complete product. If not, then is not your library part of the work you did for them? Why should they pay extra for that? Lawyers love that kind of arguments. Of course, if you have friendly and satisfied clients, then this would not likely be an issue, but sometimes things don't go so well.
If your contract says something like "client has a right to the code, to do what they want with, but you retain your rights to do what you want with the code", then there is no gray zone. As with everything legal, hire a good lawyer.
I imagine it is to protect them from being sued if they ever do reuse code (on purpose or not).
The earlier answers have it right and are both right. There are two basic reasons:
First, as you build experience in a particular area, you can accumulate knowledge across multiple customers and be even more valuable to future customers, provided that you are able to reuse what you developed in the first place.
Second, it is not always 100% clear where intellectual property rights begin and end. If you grab some clever code snippet from the last project for the next one, are you reusing “too much” so as to infringe the rights you gave the first customer? Best defense against a customer coming back and claiming infringement is not to give them the ability to do so in the first place.
One further point. Why would your customers need to have legal ownership of the code anyway? They can get all the legal rights they need to use your code by having a license. Having ownership on top of that does nothing for their ability to use the code and it prevents you from re-using it. (Of course the counterpoint to that is that they may want to prevent you from making “their” concepts available to a competitor if theirs, but there are other ways to address that.)
In case they write the next Google.
No body has mentioned this yet, but I always assumed companies did this to make it very difficult to hire anyone else to make program enhancements later on. This is obviously especially true if source code is not provided.
Enhancements can often be charged at a premium later for the actual amount of time the change would take to implement. I have seen such requests as adding extra datagrid filtering costing thousands.