Companies are used to complying with a thick stack of legalese? - please

Posted Aug 4, 2011 8:30 UTC (Thu) by ayers (guest, #53541)
Parent article: Emacs and the GPL

I hold it to be a common myth, that "Complying with a thick stack of legalese in order to license some bit of proprietary code may seem easier, at least partly because companies are used to those kinds of licenses". The fact that very few people can claim to understand the intricacies of the plethora of interactions of proprietary license schemes with all their cross references simply hides the contradictions and violations from the public view.

The clear simplicity of Free Software licenses (and yes that includes the GPLv3 when compared to your classic EULA or redistribution agreements) just makes it much more obvious when a violation occurs that it becomes possible that nearly anyone using common sense can identify a potential violation.

That simply isn't the case in case in the proprietary world. Show me someone who understands the copyright, patent license and trademark obligations of distributing a .NET application for further redistribution, and I'll show you someone who is most likely confused.

The proprietary model as I see it, is about creating an unsurmountable confused mess of interdependent obligations, instating a direct or indirect revenue stream and ignoring the convoluted obligations as long as that revenue stream is satisfactory. Once that satisfaction falls below a threshold you start looking for violations, which are bound to exist, to increase that revenue be it by negotiation or litigation.

to post comments

It's not a common myth, it's simple truth...

Posted Aug 7, 2011 8:45 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

The fact that very few people can claim to understand the intricacies of the plethora of interactions of proprietary license schemes with all their cross references simply hides the contradictions and violations from the public view.

This is not the most important distinction. The most important distinction is the fact that you operate within framework of for-profit people. If violation is found (and it happens with proprietary software more often then with free software, actually) then your development team is rarely affected.

Different people are dealing with proprietary licenses and with free software licenses. Proprietary licenses are confined almost exclusively to legal department: developers contact them when they need/want to use some proprietary tool, get the approval (or rejection) and forget all about licenses: when the approval is given it's up to legal department to solve further problems.

Copyleft works in entirely different fashion: it does not contain any complex puzzles for legal department, but it does contain strict requirements for developers which are accustomed to entirely different modus of operandi.

The proprietary model as I see it, is about creating an unsurmountable confused mess of interdependent obligations, instating a direct or indirect revenue stream and ignoring the convoluted obligations as long as that revenue stream is satisfactory. Once that satisfaction falls below a threshold you start looking for violations, which are bound to exist, to increase that revenue be it by negotiation or litigation.

Exactly. This makes it safer for companies: it's easier for them to estimate risks. Since it's all about money it's easier for them to estimate what is expected, but, what is more important it's up to the legal department to settle the problems, developers are never involved... Well, legal department can revoke the right for some component and then developers need to redo their work, but this all happens in the same fashion, developers never need to think about how their source is organized and what pieces can never be published and what they are expected to publish, etc.

Free software imposes smaller burden then typical proprietary licenses (that's why they are growing much faster), but this is entirely different kind of burden - a lot of companies just don't know what to do about it.

It's not a common myth, it's simple truth...

Posted Aug 8, 2011 12:15 UTC (Mon) by Trelane (subscriber, #56877) [Link] (2 responses)

If your legal team only emits binary yes/no for proprietary libraries and source, then you're doing it wrong.

Proprietary software can come with all kinds of restrictions, not just on what you can and cannot ship and how you can ship it but also what you can and cannot *do* with the software yourself. Keep in mind also that not all proprietary customers are equal, and some really *do* get to look at (some of) the source and do (highly restricted) things with it.

It's not a common myth, it's simple truth...

Posted Aug 8, 2011 12:20 UTC (Mon) by Trelane (subscriber, #56877) [Link]

Take, for example, (part of) the JDK5 license (http://java.sun.com/j2se/1.5.0/jdk-1_5_0-license.txt)

B. License to Distribute Software. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software README file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

[...]

D. Java Technology Restrictions. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation.

E. Distribution by Publishers. This section pertains to your distribution of the Software with your printed book or magazine (as those terms are commonly used in the industry) relating to Java technology ("Publication"). Subject to and conditioned upon your compliance with the restrictions and obligations contained in the Agreement, in addition to the license granted in Paragraph 1 above, Sun hereby grants to you a non-exclusive, nontransferable limited right to reproduce complete and unmodified copies of the Software on electronic media (the "Media") for the sole purpose of inclusion and distribution with your Publication(s), subject to the following terms: (i) You may not distribute the Software on a stand-alone basis; it must be distributed with your Publication(s); (ii) You are responsible for downloading the Software from the applicable Sun web site; (iii) You must refer to the Software as JavaTM 2 Platform Standard Edition Development Kit 5.0; (iv) The Software must be reproduced in its entirety and without any modification whatsoever (including, without limitation, the Binary Code License and Supplemental License Terms accompanying the Software and proprietary rights notices contained in the Software); (v) The Media label shall include the following information: Copyright 2004, Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Sun, Sun Microsystems, the Sun logo, Solaris, Java, the Java Coffee Cup logo, J2SE , and all trademarks and logos based on Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. This information must be placed on the Media label in such a manner as to only apply to the Sun Software; (vi) You must clearly identify the Software as Sun's product on the Media holder or Media label, and you may not state or imply that Sun is responsible for any third-party software contained on the Media; (vii) You may not include any third party software on the Media which is intended to be a replacement or substitute for the Software; (viii) You shall indemnify Sun for all damages arising from your failure to comply with the requirements of this Agreement. In addition, you shall defend, at your expense, any and all claims brought against Sun by third parties, and shall pay all damages awarded by a court of competent jurisdiction, or such settlement amount negotiated by you, arising out of or in connection with your use, reproduction or distribution of the Software and/or the Publication. Your obligation to provide indemnification under this section shall arise provided that Sun: (i) provides you prompt notice of the claim; (ii) gives you sole control of the defense and settlement of the claim; (iii) provides you, at your expense, with all available information, assistance and authority to defend; and (iv) has not compromised or settled such claim without your prior written consent; and (ix) You shall provide Sun with a written notice for each Publication; such notice shall include the following information: (1) title of Publication, (2) author(s), (3) date of Publication, and (4) ISBN or ISSN numbers. Such notice shall be sent to Sun Microsystems, Inc., 4150 Network Circle, M/S USCA12-110, Santa Clara, California 95054, U.S.A , Attention: Contracts Administration.

It's not a common myth, it's simple truth...

Posted Aug 8, 2011 18:41 UTC (Mon) by elanthis (guest, #6227) [Link]

> some really *do* get to look at (some of) the source and do (highly restricted) things with it.

Quite a few proprietary licenses are source licenses. Full source licenses. With relatively permissive terms controlling what you can do with the source. (Obviously giving the source away or reselling it is out, which is hugely restrictive compared to FOSS.) This is particularly common in the middlware and tools market and in the games market (which is mostly about middleware and tools).