Distributed Copyright: Libre, not "free beer"
On Thu, 18 Jan 2001, Russell Nelson wrote:
> Manfred Schmid writes:
> > I hereby request an official Board statement: Does OSI approval of
> > licenses require the software to be free in the sense of "free beer"?
>
> [ I prefer to use the terms "gratis" and "libre". In English, "free"
> means both those things at the same time, and in our context is often
> VERY confusing. ]
>
> No. I (just one of the board members of OSI) don't care if software
> is gratis. Open Source (or "Free", aka rms-Free) software must be
> libre. That it ends up being gratis is just a side-effect; sometimes
> a good one, sometimes a bad one.
I also believe that an appropriate license is "libre" and not
"free-beer". I wrote about this two years back, at
www.distributedcopyright.org ; my original thoughts had a
serious flaw (with regard to trademark), a more succinct
and updated version is at http://www.clarkevans.com/jackson.txt
My primary problem developing this further has been time and
a reasonable product to license under this mechanism. I'm
currently working on a product; and perhaps one of these days
I'll have time to get the non-profit up and running.
Clearly the OpenSource style ("gratis -> free beer") of licensing
does have serious applications, as I've written and contributed
to many open source projects myself. However, I just don't
think it is the solution to *all* software; and I think that
standard proprietary software is ugly enough to deserve
some competition.
Manfried, If you and others would like to "join-in" and help
refine DistributedCopyright.Org, this would be great. Right
now the list server is down and when I get time I'll update
the web site (which is now over a year old).
Until serious people join in, I'll plod along developing my
killer app and then will go to market under DistributedCopyright.
A product, I now feel, is the *only* way to bring a license
into view (I've ranted enough trying to get others to change
their license...)
Kind Regards and Sincere Hopes for a Liberating License this year!
Clark Evans
P.S. The style of license as you have designed it does not
gaurentee "libre". A seperate non-profit must hold the
copyright for this to be true.
[License-discuss] a Free Island Public License?
I'd love your high-level thoughts on a "Free Island" license or anything that might be similar in nature. ... FREE ISLAND PUBLIC LICENSE (v0.2 on 12 DEC 2011) This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free components. So long as this copyright and license are included in all substantial copies of this work you may: 1. Publicly copy and use verbatim copies of this work including public distribution and performance. 2. Privately deal with this work in any way you wish, including internal usage, copying, and modification of this work. You may also make publicly available via distribution or public performance any Derived Work only if the following conditions are met: 1. the preferred source code for the Derived Work must be made freely available under this license; 2. the Derived Work must pass the Free Island test. By "Derived Work" we mean a modified copy or adaptation of this work or a separate work such as a plug-in, protocol adapter, or wrapper which is designed to have intimate interactions with this work's operational details, or interfaces. A Derived Work passes the "Free Island" test if it could be prepared, modified, compiled, tested, installed, and operated in a manner advertised or expected using only Commodity Hardware, Free Software, this software, and the Derived Work itself. In particular, the Derived Work fails this test if it depends upon proprietary software, remote services or hardware to provide features that do not have a corresponding Free Software implementation. By Free Software we mean any software which is readily available to the public without fee and with this license, any license approved by the Open Source Initiative or any license considered free by the Free Software Foundation. By Commodity Hardware we mean a computing device which has substitutes in a marketplace and is priced under fair, reasonable and non-discriminatory terms (FRAND). A safe harbor for passing the Free Island test is if the Derived Work is fully usable as intended when compiled & installed on a set of networked Debian virtual machines using software only from its 'free' distribution, the KVM emulator, and no outside network connectivity. If the work is created for the purposes of interfacing with proprietary hardware or services, then a sufficiently complete emulation of those components must be made available as Free Software. THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, AGAINST INFRINGEMENT, TITLE AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
On Fri, Dec 16, 2011, at 04:33 PM, Jeremy C. Reed wrote: > | This software is licensed for any purpose excepting the right to > | make publicly available derived works which depend exclusively > | upon non-free components. > I believe these could be understood to conflict with: > - ``The freedom to run the program, for any purpose (freedom 0).'' > > How can it be used for any purpose if it can't depend on non-free > software implementation? I this think is a strong argument. Like the GPL, this license imposes a condition on the distribution of modifications, it doesn't restrict use. If you're looking for a free software principle it might conflict with, it is: - ``The freedom to distribute copies of your modified versions to others (freedom 3)`` Of course, the GPL also conflicts with this freedom since one's modifications might include linking with non-free software. The difference between the GPL and this license proposal is that the GPL requires that the "whole of the work, and all of its parts" be under the GPL. While this license instead requires that the modification be functional on a free island. ... For example, if you made significant modifications to a "C" program such that it would now use the ::MessageBox() function, you're welcome to compile it (on Windows) and use it yourself. However, if you wish the privilege to distribute your derived work, it should be compilable and your changes should operate as you would intend using only free software. Luckily, the MessageBox Win32 System call is implemented under Wine so there's no problem meeting the Free Island test. This is a different approach than the GPL and I'm hopeful that we might have a fruitful discussion about its merits. I'm not a lawyer so I'm sure there are lots and lots of details that are poorly constructed. It matters little to talk about the details if the general direction doesn't stand up on examination. Kind Regards, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
On Fri, Dec 16, 2011, at 10:51 PM, Bruce Perens wrote: > The author should back up and state a list of goals, > rather than present the argument as pseudo-legal drafting. Bruce, My primary objective is that software ported to provide compatibility with proprietary platforms be done in such a manner that the free software emulators of those platforms become sufficiently good to run the ported work. I think this would increase the willingness of authors to contribute their works as free software; at the same time I think it would provide a motivator to ensure that free software emulations of proprietary platforms (like Wine) are fully functional replacements. Why do I think so? The value of a platform isn't intrinsic, it is rather proportional to the software that runs on it. Hence, when free software is ported to a proprietary platform, the author of the free software is unwittingly contributing to the financial value of the proprietary platform's vendor without any equivalent value exchange. Since I realize it is not in the spirit of "free software" to explicitly ban the use of a proprietary platform, I think the next best thing that you could ask for in return is proper emulation. A previous attempt at accomplishing this objective used a modified GPLv3 less the system library exception. However, I don't think this neatly encapsulated the idea and might not even be strong enough to accomplish the objective. My secondary objective (tightly related) is to somehow address the well known "work around" to the GPL where you wrap your proprietary functionality as a web service API and then call it from a derived work. To me this fails since it doesn't license the "the whole of the work, and all its parts, regardless of how they are packaged". For an example of this "work around" please see an example of this approach [1]. The informal consultation of two intellectual property attorneys seem to concur with the response to this question -- that even if the GPL linking affects shared libraries, it certainly does not extend to web services; Web API "work around" is simple & effective. This second attempt at a license takes a different approach from the GPL, implicitly not exempting system libraries but also making a test (and license name) that I hope would render useless these sort of application topology copyleft work-around. I think the opening of the license itself nicely encapsulates both of these goals in a succinct way: This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free components. I hope this expresses my intent clearly. I had presented an earlier proposal on debian-legal [2] that was much less well developed. I expressly omitted my objective here so that the license idea itself would be taken up on its merits without diving into a discussion if my goals are worthy. I think there are lots of reasons to disagree with my objective, however, the question for me is if this general approach is acceptable pathway to an open source license. Best, Clark [1] http://stackoverflow.com/questions/4351119/if-i-use-gnu-gpl-code-with-my-own-server-side-code-do-i-need-to-open-my-server/ [2] http://lists.debian.org/debian-legal/2011/11/msg00025.html ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] GPL and proprietary WebAPIs
I have a broad question about various interpretations of the GPL with regard to WebAPIs. Let me start with an example scenario. 1. Suppose that Super Visual is a clever GPL licensed data visualization program (released by Vendor A). 2. Now suppose that there is a closed-source, but free to redistribute, data processing library, called Correlate (by Vendor B), which takes a data set and a parameters and does a clever and very proprietary data transformation. 3. Now suppose that I modify Super Visual to incorporate the functionality of Correlate. It works wonderfully and I wish to share my Visual Correlate with my friend. Is this permitted by the GPL? a. Suppose my modifications involve static libraries, the resulting Visual Correlate is a single compiled executable. b. Suppose Super Visual has a plugin mechanism, and I use this internal API to load Correlate as a dynamic link library. Let's assume I also ensure that the program still works but lacks the correlate functionality if the dynamic library isn't there. I don't ship correlate.dll, but tell my friend about the easter egg. c. Suppose that Super Visual doesn't have a plugin system, but I release a GPL licensed Super Visual /w Plugins that does. Now can I release Visual Correlate using this plugin mechanism? d. Suppose that I make a SuperVisual+ (GPL licensed) with "generic", if complex way, to invoke separate executables for external processing using standard input, output, and command line arguments. Suppose also I get permission from vendor B to create and freely distribute a closed source Correlate command line executable that takes the specially formatted inputs to return outputs that the SuperVisual+ needs. I'm all clear now? e. Suppose that I instead wrap Correlate in a WebAPI (let's say I get permission of Vendor B to do this). Then, my modification to SuperVisual creates a runtime dependency on the web service; it degrades nicely without Correlate functionality if you lack a network connection or haven't paid to access my web service. Can I release this Visual Correlate under the GPL? f. Suppose that SuperVisual is a web application, and I "wrap" it with a web service running on a different server (without modifying one line of code), parsing the output stream to add additional functionality provided by Correlate. The final result is that my users experience a single integrated application that mixes both Correlate and Super Visual functionality. My interpretation of the GPL is that in every case, I'd be producing a modified version. Even in the latter case, my wrapper would be using very specific (and hence intimate) information about how the application works and therefore would qualify as a new program based on the earlier work. Hence, since my Visual Correlate must comply with the GPL; and since I don't have the right to also release Correlate under the GPL, I can't share my work (as cool as it may be) with my friend -- even if he already has a copy of the Correlate program. I say this for a few reasons. First, in section #1 of the GPL, "Corresponding Source" it says that the corresponding source must include all source code needed to run the object code. Hence, I must also include Correlate under the GPL. Secondly, under section #5c, it requires that I license the "whole of the work, and all its parts, regardless how they are packaged". Hence, my attempts to work around the intent of the license are foiled... packaging the Correlate function as a WebAPI doesn't make it any less of the whole work. Is this a correct assessment? If not, where has my logic gone astray? I've talked to a few attorneys lately about this situation, and I've gotten wildly different answers. While the specific example is completely hypothetical, the general situation isn't. I'd remark that it's widely held that wrapping up proprietary functionality in a Web API is a valid way to evade the GPL's copyleft. http://stackoverflow.com/questions/4351119/if-i-use-gnu-gpl-code-with-my-own-server-side-code-do-i-need-to-open-my-server/ Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Tue, Dec 20, 2011, at 03:30 PM, Chris Travers wrote: > In general, good will from the projects at issue is a factor that > should not be underestimated and being a good citizen means ideally > making sure they are ok with it. Absolutely. If people consider you to be behaving fairly, they are more likely to support your cause. > I can tell you how the LedgerSMB core team approaches this. We draw a > hard line between "using our code" (requires adhering to the GPL) and > using our API (does not). In practice this means if you use our code > as a basis for your code whether through object inheritance, literal > copying, or paraphrasing, we expect you to adhere to the GPL v2. Let's suppose that I've working on a Ledger++ program which is a proprietary version of your Ledger SMB that adds awesome multi-state Payroll and Asset Depreciation features. Only rather than including these features in your code-base, I include only stubs that package up the data each feature needs, calls a proprietary web service, and returns the data. So, about 5% of my code is a bunch of hooks, while 95% of my Ledger+ code remains proprietary. I release the stubs under the GPL license... but effectively, the features I've added are completely useless and non-operational unless you've paid for my web service subscription. > This is intended on our part to keep the "based on" > language in the GPL v2 to be close to the derivative > works definition in copyright law and recognizing that > nobody needs copyright licenses from Microsoft to write, > say, Internet Explorer plugins. My reading of the GPLv3 is that it uses copyright law to determine when you've made a modification, but, the condition to distribute your modification goes far beyond this limitation, including "the whole of the work, and all its parts, regardless of how they are packaged". > In this view, there is no problem. There wouldn't even be a problem, > in this view, if the libraries were linked provided that the code > connections are not so intimate as to create a derivative work (for > example, I would argue that class inheritance in fact does this). Would you have a problem with the scenario above, perhaps assuming I'm implementing a business feature that you consider to be "core" to the mission of Ledger SMB and you would have hoped would be contributed back to the project? Thanks kindly for any additional thoughts, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Wed, Dec 21, 2011, at 03:01 AM, Chris Travers wrote: | > Let's suppose that I've working on a Ledger++ program | > which is a proprietary version of your Ledger SMB that | > adds awesome multi-state Payroll and Asset Depreciation | > features. Only rather than including these features | > in your code-base, I include only stubs that package | > up the data each feature needs, calls a proprietary | > web service, and returns the data. | | Ok. So far so good. | > | > So, about 5% of my code is a bunch of hooks, while 95% of | > my Ledger+ code remains proprietary. I release the stubs | > under the GPL license... but effectively, the features | > I've added are completely useless and non-operational | > unless you've paid for my web service subscription. | | Well, technically you'd probably release under the LGPL or BSD | license, sort of like nVidia does with their stubs for their Linux | video drivers. Again this isn't a new thing. You see a surprising | amount of it in Linux (ndiswrapper, the nVidia drivers that RMS hates, | etc). I don't understand why it'd matter how the stubs are licensed, if the GPL doesn't have any ability to "jump" over a network. | > My reading of the GPLv3 is that it uses copyright law | > to determine when you've made a modification, but, the | > condition to distribute your modification goes far beyond | > this limitation, including "the whole of the work, and all | > its parts, regardless of how they are packaged". | | That's not my reading. My reading is that the license tries to get | away from the derivative works definition (maybe it's not strict | enough for Stallman?) through refining definitions. Of course the GPL | is not a EULA and it only requires acceptance when you distribute the | work or derivative works, but that only covers some cases. The GPLv3 defines a modified work as strictly matching any adaptation that requires copyright permission. So, I don't think there is a re-definition there. What the GPLv3 does do is set very broad terms (far beyond the 'modifications') in exchange for the right to publicly distribute these modifications: In Section 1, it requires the "Corresponding Source" to include *all* the source code needed to generate, install, and (for an executable work) run the object code and to modify the work -- excepting system libraries or general purpose tools or generally available free programs. So, for my example, I believe the "Corresponding Source" would absolutely include the Multi-State Payroll and Asset Depreciation code that I'm trying to hide behind a web service. Since without this code, I'm not able to run the logic in the hooks (screen buttons let's say). In Section 5, the GPLv3 clarifies this intent even more, by requiring that I license "the whole of the work, and all its parts, regardless how they are packaged". In my example, I'm attempting to circumvent the GPL via packaging. However, it's pretty clear that the whole work includes the Payroll and Depreciation logic since my hooks are pretty useless without this complementary logic. Hence, while the *modifications* to your code are simply hooks, the conditions for distributing those modifications would go far beyond what copyright law might consider. Deservedly, the GPLv3 uses my hooks (the part covered by copyright law) to require the release of the exact same source code I am attempting to shield & pretend aren't part of the derived work. | Let's try a thought experiment. Let's say LedgerSMB depended on | Windows and was essentially using Windows-only API's (and thus linking | with Windows base libraries). Now, I recognize that the GPL | specifically exempts linking to system libraries, but I see no reason | why system libraries are different from a copyright perspective (i.e. | this distinction exists solely because RMS wrote it into the license). | Now, if linking implies derivation, then isn't the software (and by | extension *all* Windows software) derivative of Windows? If that's | the case then doesn't every developer of Windows software need | Microsoft's permission to distribute such software? I don't think so. That's not how the GPLv3 works. The GPLv3 isn't claiming your work is a derivation of the base works, it is adding additional conditions in exchange for the right to distribute your modifications. There is a difference. Let's pretend that Win32 calls aren't System Libraries. In this case, let's say I'm making a derived work that ports your software to work on Windows. So, while I cannot do this directly, I can do it indirectly by ensuring that Wine supports the Win32 calls I use and getting my program to work under Wine. In this case, I will have met the conditions in sections 1 and 5 of the GPL using the code found in Wine. There is nothing saying that my derived work (that is generated on Linux under Wine) couldn't be distributed and executed on the Windows platform. | > Would you have a problem with the scenario above
Re: [License-discuss] GPL and proprietary WebAPIs
I found a tangible example of what I'm referring to, complete with wonderful visuals. Chris Kleisath at Sybase describes how they circumvent the GPL license by using intermediate APIs to link proprietary functionality with GPL licensed works. Is Chris correct? For GPLv2? For GPLv3? http://iablog.sybase.com/kleisath/index.php/2009/02/how-to-interface-proprietary-code-with-gpl-code/ ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Greetings, Earthlings! Need quotes for article
On Wed, Dec 21, 2011, at 04:28 PM, John Cowan wrote: > > Sybase Open Watcom Public License 1.0 > > http://www.opensource.org/licenses/Watcom-1.0 > > I don't see anything wrong with this MPL variant either. This license seems to have two interesting conditions. First, it requires a click-wrap when "reasonably feasible", I don't know how problematic this is. Second, it seems to require changes be publicly available even if you deploy them only within your organization. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Thu, Dec 22, 2011, at 02:00 PM, Lawrence Rosen wrote: > Linking GPL software to proprietary software is legal as > long as one doesn't create a derivative work. Thank you for the helpful response. The hard part then is knowing when a derivative work would be formed, or, perhaps more difficultly, what is the derivative work constitutes. (I know the analysis below is too generic to provide any concrete answer, but I'd love to learn more about the frequently misunderstood things about the GPL) Let's say my original work O has been changed via a set of non-trivial modifications M, where these changes provide new/different functionality to the base work O and cannot be used independently. In this case, it seems clear that both M and the combined work, C = O+M are derived works. At this point, if O is licensed under the GPL, to publicly distribute M (and hence C), it should be licensed and distributed under a license compatible with the GPL. Now for the hard part. Suppose there is a proprietary work P which M references and uses for a critical part of its implementation and that P doesn't have any substitutes; that is, the interface between P and M is proprietary, and not a standard protocol with open implementations. Does the GPL prevent the distribution of M if the work it relies upon, P, isn't compatibly licensed? I've heard some GPL advocates say that the answer depends on the type of linking and if M is also derived from P. Frankly, I don't understand either of these limitations, the first is a technical detail. If M doesn't operate as intended without P, why would it matter if M be a derived work of P? As a non-lawyer, I read section 5(c) where it says in order to distribute the modifications M, you must license under GPL "the whole of the work, and all its parts, regardless of how they are packaged". Further, in section 1 of the GPL it states the corresponding source must include "all the source" needed to "run the object code". So, I'm quite confused... it doesn't talk about the type of linking nor does it seem to require that M be derived from P. I do know that I can't operate O+M without P and this seems sufficient to bar the public distribution of M. I suppose it matters on the specifics of the given case. > If GPL advocates insist upon distinguishing among types > of functional linking, then talented software engineers > will avoid disputes by building shims, APIs, or use > dynamic linking to accomplish their functional goals. I absolutely agree with this. It shouldn't matter at all how the components are connected, via direct incorporation, static linking, dynamic linking, or via WebAPIs. Those are simply technical details and attempts to discuss type of linking I think really distracts from the primary concern. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Thu, Dec 22, 2011, at 01:34 PM, Rick Moen wrote: > You know, Clark: Speaking for myself, I have no interest > in advising querents about how closely they can lawfully > skirt the requirements of copyleft licences, or how they > can creatively circumvent those requirements entirely, in > order to use copylefted properties in proprietary works. > > You keep asking basically the same question, but are seeing > scant interest in helping you. Might be that my view is common. Your characterization is wholly inaccurate, although I could see how you might arrive at this conclusion. My objective by asking this question is to determine if the GPL is an appropriate license for our consulting organization to release suite of tools and programs that are currently bundled with our services. I have some doubts since there seems to be a general consensus that you can easily use WebAPIs to evade the GPLv2. Our general application would be similar to Chris Travers' accounting application, and the case I'm concerned about would be very similar to what I posted in my follow-up. That is, could a competitor submit a set of hooks/menus as a "derived work" and effectively shield proprietary functionality via a WebAPI? I later found Chris Kleisath's blog post that implies that Sybase uses a similar technique. I'm asking, openly, what people's public opinion on this matter is. I'm not asking for advice about how I could incorporate GPL licensed material into a proprietary work. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
Rick,
My question is rather straight-forward. Does the GPLv3
permit the distribution of derived works that require
an independent and non-free work for its operation [1].
I was under the impression that the Corresponding Source
("all the source code needed to... run the object code")
and 5c ("the whole of the work, and all its parts,
regardless of how they are packaged") would effectively
prevent this sort of distribution. However, this seems
not to be the case.
If so, and this seems to be the consensus I'm hearing,
then I think the GPLv3 is ineffective; more of a nuance
than effectively protecting the free commons. Since,
if I wish to distribute an extension of GPL'd work,
all I have to do is factor out the critical parts of
the my work and make them available as an independent
and proprietary web service.
On Fri, Dec 23, 2011, at 03:52 AM, Rick Moen wrote:
> I doubt very much that the recent queries here qualify as
> that variety of public service.
You are being unnecessarily argumentative. I'm
trying to find an appropriate licensing strategy
for our company, and I'm expressly trying to prevent
and understand the sort of shims that seem to be
standard industry practice. If our work can't be
protected from these "creative circumventions" by
the GPL, then we probably won't use this license.
It's my position that if you wish to create a derived
work that incorporates proprietary functionality,
you should also provide an equivalent implementation
under a compatible license. The style of linking
and the question if the combined work is also derived
from the proprietary work are largely irrelevant in
my estimation. Yet, these two considerations keep
emerging as if they are limitations of the GPL.
Part of this problem is legal, but the other part
is what the community accepts as being acceptable
and that depends upon the public opinion of legal
and technical professionals on this list.
Best,
Clark
[1] For purposes of this question, you can consider the
dependency to be declared as part of the derived work,
but resolved at runtime via sockets or WebAPI; also
assume that the derived work is *not* a modification
or transformation of the independent, non-free work.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Sun, Dec 25, 2011, at 10:22 AM, Ben Tilly wrote: > The real question is not what the GPLv3 does or > does not allow, it is what copyright does or does > not allow. If a work is derived under copyright > law from a GPLed piece of work, then it must be GPLed. > If a work is *not* derived under copyright law > from a GPLed piece of work, the GPL is going to > have trouble restricting it. If you write any > other copyright license, you'll run into the same issue. Thank you kindly for your response. My question involves 3 works, not 2. We have a original work O, a "derived" work D (O + a shim/adapter), and an independent proprietary work P; where D derived from O under copyright law, D relies upon P for its operation, and where P has no substitutes. I am assuming that by copyright law the author of O can restrict the distribution of D. Let's further assume that P has no substitutes, so that its functionality is not available under a license compatible with the GPLv3. So, my question is if the GPLv3 would restrict the distribution of D due to its dependence on this independent and proprietary work P. This is the essence of the WebAPI hack to the GPLv3, you refactor your would-be derived work D into an independent and proprietary work P as well as a shim S, such that the "derived work" is D = O + S is released under the GPLv3 but the functionality "added" to O are effectively useless unless you use it in conjunction with P. This is exactly the case I discussed in my reply to Chris Travers and the shim technique promoted by Sybase's Kleisath [1]. It is my personal view that the GPL would absolutely restrict this since it covers "the whole of the work, and all its parts, regardless of how they are packaged", "all the source code needed to [...] run the object code", and "independent works, which [... are... ] combined". What confuses me and what I'm asking here is why licensing professionals focus on two items that I consider irrelevant: (a) what is the type of linking between D and P? and (b) is D a derived work of P? What we know is that D is derived from O and that D requires P for its operation. Those two facts seem sufficient for my taste. Best, Clark [1] http://iablog.sybase.com/kleisath/index.php/2009/02/how-to-interface-proprietary-code-with-gpl-code/ ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Sun, Dec 25, 2011, at 01:01 PM, Rick Moen wrote: > Quoting Clark C. Evans (c...@clarkevans.com): > > > What confuses me and what I'm asking here is why licensing > > professionals focus on two items that I consider irrelevant: > > (a) what is the type of linking between D and P? ... (b) is D a derived work of P? What we know is that D ... is derived from O and that D requires P for its operation. > > Please name one such licensing professional (who is not an FSF > spokesman). What was on my mind was this journal article: Software Interactions and the GNU General Public License By Malcolm Bain in IFOSS L. Rev. Vol 2, No 2 (2010) (http://www.ifosslr.org/ifosslr/article/view/44) What was also on my mind was an informal side chat with an attorney on the stack overflow question [1]. I was referred to the GNU FAQ, especially the answer for plug-ins [2] where the applicability of the copyleft "depends on how the program invokes its plug-ins" and aggregation [3] where it says "sockets... are normally used between two separate programs". This attorney said the specific details of the case were necessary to give any advice, but after my insistence, commented that the community consensus is likely correct. Probably you consider both of these professionals to be associated with the free software foundation. For what it's worth, our own corporate attorney doesn't have a concern with regard to linking technologies, he advices that GPL is quite vague and if we were to use it, we should publicly exclaim our interpretation. To this regard, Larry Rosen's comment [4] is refreshing, matches my expectations, and is broadly helpful: "If GPL advocates insist upon distinguishing among types of functional linking, then talented software engineers will avoid disputes by building shims, APIs, or use dynamic linking to accomplish their functional goals." Unfortunately, this doesn't give me enough guidance on the applicability of copyleft; specifically with my 3-work scenario where someone uses a shim/adapter to include proprietary functionality via a WebAPI. I keep asking this in this public forum since it matters quite a bit to the effectiveness of the GPL. If this sort of work around is acceptable by the community, then other than nuance value, there really is no point in copyleft, and one should use Apache or keep the work proprietary. Assuming a shim/adapter creates a derived work under copyright law so that its distribution could be limited based on conditions of the license agreement, does the GPLv3 actually prevent the distribution of a derived work when its operation requires an independent, proprietary component that has no free software substitute? In particular, does the relation vis-a-via copyright law between the adapter/shim to the independent proprietary work matter if it's clear enough that the adapter/shim cannot operate without the proprietary work? Best, Clark [1] http://stackoverflow.com/questions/4351119/if-i-use-gnu-gpl-code-with-my-own-server-side-code-do-i-need-to-open-my-server/ [2] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins [3] http://www.gnu.org/licenses/gpl-faq.html#MereAggregation [4] http://projects.opensource.org/pipermail/license-discuss/2011-December/91.html ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
First, thank everyone for their responses. I especially enjoy the reading material that Rick Moen has referenced. On Tue, Dec 27, 2011, at 10:07 AM, Tzeng, Nigel H. wrote: > If it's not a derivative work then it's not a derivative > work and you should have no heartache. If it is a > derivative work then you have legal recourse to correct it. I'm concerned about the case where a shim/adapter could be ruled as derivative work and as such its distribution of such could be prohibited under copyright law --- but where the court does not consider the derivative work to include an independent proprietary component needed to actually use the derivative in a meaningful way. In this case, does the GPLv3 create an additional contractual condition for the distribution of the "covered work" in 5(c) that would forbid the distribution of the shim if the required proprietary component is not also licensed compatibly? Or, is 5(c) of the GPL essentially the same as the OSL and limited to only the scope of a derivative work. In this interpretation, you rely upon convincing the court that the entire derived work necessarily includes a component which is required for it's operation. That seems much harder case. > IMO, "appropriate licensing strategy" is far more a > business decision than a legal one. If you wish to develop > an open source community around your product then > GPL v3 + a proprietary license option like MySQL AB > offered is safe enough for most practical purposes. I think MySQL AB's licensing strategy is offered in this forum as an overreach. In particular, Larry Rosen argues that there is no derived work when an application simply uses MySQL as intended via its public interface, even if the application relys upon specific MySQL functionality. It seems that Rick Moran and many others agree. Please note that my scenario is different, I'm talking about a competitor who would alter/transform/modify our work in order to add proprietary functionality -- not simply use it via its public interface. > Then your scenario of shims and "creative > circumventions" isn't a negative but a positive as it > enhances both your revenue stream and ecosystem. I can't disagree more. This technique, if the GPLv3 offers no defense against it, would permit our competitors to keep their exclusive proprietary licensing stream while actively integrating the benefit that our software would provide without contributing back. The shim being an actual "anti-contribution" since it may confuse users what is free software and what isn't. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
John, Thank you for your reply. On Tue, Dec 27, 2011, at 11:18 AM, John Cowan wrote: > > Does the GPL prevent the distribution of M if the > > work it relies upon, P, isn't compatibly licensed? > > Web browsers "rely on" web servers to provide most of their function > (take it from someone who was recently cut off from the Internet for > three whole days), and also on the entire Internet infrastructure of > routers and so on. Most of this infrastructure, and many web servers, > runs proprietary software, but nobody argues that a GPLed web browser > can legally interact only with GPLed servers using GPLed infrastructure. I'm not arguing for this interpretation, this would be a restriction on how software may be used (clearly non-free). You offered earlier a thoughtful remark: | Microsoft grants explicit permission to use its SDKs to | construct software that is intended to run on Windows. | If it happens to run on non-Windows systems such as | ReactOS or Wine, that is not the developer's fault. So, I look at it in a similar manner: if a derivative work in the form of a shim/adaptation can be used as advertised using only free software, then the requirement that the "whole work" be licensed in a compatible manner is met. That the shim or adapter might work with a proprietary implementation of that same free software is an acceptable outcome. It is the user's right to operate their copy of the software with a proprietary implementation. With this view, if a derivation (shim or adaption) requires proprietary software (with no open source substitutes) in order to function as expected, then "the whole of the work, and all its parts, regardless of how they are packaged" has not been compatibly licensed. In this case, while the author may wish to distribute their "improvement" under the GPL, they are barred from doing so under 5(c) since their "improvement" effectively requires that one obtain a proprietary license to enjoy the derived work. So, back to your question. Given my interpretation, the only issue with a GPL'd web browser might be the inclusion of features that only work in combination with a proprietary web server (and lack an open source implementation). In this case, there are three options: (a) make an exception in the license, this is what the "System Libraries" stuff is all about, (b) implement the quirks/features of the proprietary web server as a derived work from an open source web server, or (c) use a different license. I think that (b) is a very fair tradeoff. If a vendor would like to add support for proprietary webserver features to a GPL'd web browser, they should be willing to provide a reference implementation with the complete functionality they wish to incorporate. How else could one only using free software take advantage of the feature they have added to the web browser? How else could you maintain this addition to the commons and know it works? On Tue, Dec 27, 2011, at 02:49 AM, John Cowan wrote: > > My question involves 3 works, not 2. We have a original > > work O, a "derived" work D (O + a shim/adapter), and an > > independent proprietary work P; where D derived from O > > under copyright law, D relies upon P for its operation, > > and where P has no substitutes. I am assuming that by > > copyright law the author of O can restrict the distribution > > of D. Let's further assume that P has no substitutes, so > > that its functionality is not available under a license > > compatible with the GPLv3. So, my question is if the GPLv3 > > would restrict the distribution of D due to its dependence > > on this independent and proprietary work P. > > As a worst case, the behavior of P can be reverse engineered, > since it is communicating openly with D in a way that can be > analyzed. I think this misses the point entirely. If it's easy enough to embed proprietary functionality via shims without providing an open source implementation of the complementary functionality, then copyleft doesn't really serve much purpose, except for being a nuisance. The shim you'd get would be a minimal conversion from your data structures to something that could be then converted into theirs... how'd that be useful to reverse engineering? Why should the burden of reverse engineering be placed on the one contributing free software to the commons? > If you don't know about the Affero GPL3, you should look into it. Yes, but the AGPLv3 addresses a completely different problem; it also faces the same challenge I'm outlining. I appreciate the the thoughtful engagement, I don't see why the proprietary Internet infrastructure has anything to do with what I'm discussing since I could create & test just about anything using a set of networked virtual machines. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] a GPLv3 compatible attribution for MIT/BSD?
Good Morning! Our company is releasing a medical informatics platform, RexDB, under the GPLv3 license later this year (after the code has a developer documentation). We will be using 7b clause of the GPLv3 license for a reasonable author attribution. Even so, parts of our system will be released under a more permissive license, and I'm wondering if there is a simple, MIT-style clause that would be compatible with the GPLv3? Here's my crayon attempt... To the extent that an application using this software displays legal notices, copyrights, or attributions it must acknowledge the Example Project (http://example.org) in a similar manner. Would this sort of clause be compatible with GPLv3 and would it meet the OSI criteria? Would anyone have specific wording suggestions? I'm asking here because I'd rather re-use something similar, if not, then I'd prefer to be adding a clause that has "consensus" here. Thank you kindly. Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
On Sun, Jan 15, 2012, at 03:23 PM, Johannes Buchner wrote: > It talks about preserving the preservation of legal notices or > author attributions, not rules of any ad formats for the software. That's correct. > *The only thing you demand is that they distribute the source, and > that the source must (forever) contain your name.* > BSD/MIT licenses do demand that too. That's incorrect. Both Apache 2.0 and GPLv3 permit a requirement to display author attribution in legal notices shown to the user, this is beyond MIT/BSD license which requires only that the copyright notice in the source files be maintained. So, I'm looking for a clause for MIT/BSD derivative which would be an equivalent statement, by "compatible" I mean a "permissive term" by the GPLv3. > > Here's my crayon attempt... > > > > To the extent that an application using this software displays > > legal notices, copyrights, or attributions it must acknowledge the > > Example Project (http://example.org) in a similar manner. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
On Wed, Jan 18, 2012, at 05:19 PM, John Cowan wrote: > What I would do if I were you is to construct such a license > using the MIT license and the attribution clause you want, > carefully tracking the language in the GPLv3. Then follow > the process "For Approval" at http://www.opensource.org/approval. > IMHO you can reasonably ask for the outside legal review to be > waived, given the simplicity of your license. Since I'm not a legal professional, I'd prefer someone who is associated with the Open Source Initiative to provide some guidance if they might feel inclined. My objective for this license (MIT + Attribution Clause) is to inform people who use works based on this software that the program they are using is built with other components. Acknowledgement is probably the most important compensation that developers could get and it's the right thing to do. That said, I don't want this requirement to be hard to grok, intrusive or obnoxious; further, I'd like the license to be very generic without having any sort of NOTICE text file or license addendum or exhibit. What's very important is that the clause is succinct, understandable, effective, and easy to use. I intend to make some sort of ``credit.js`` project with an enumeration of projects, urls, collaborators, and other detail that might automate the compliance with this license. It'd have some sort of "" button that would have a pop-up with an attractive listing of open source components. Of course, if someone did this before I do it... great! Without further ado, here is a second draft of a clause which would be added to an MIT derived license... To the extent that a work containing this software displays author attributions, copyrights and legal notices, it must credit this work and its development project commensurately. The GPLv3 uses the words "containing this software" and "based on this software" often, the former being used in 7b, so this is the wording I use here. The GPLv3 uses a "to the extent that it" to explicitly mean that such a display of legal notices isn't required, and that these requirements only bind if such a display exists (see 5d). This is the phrasing I use here. The GPLv3's definition of Appropriate Legal Notices is a user interface feature that displays a copyright notice and provides warranty and other license detail. In the interest of brevity, I've shortened this: 'displays ... copyrights and legal notices'. The GPLv3 permits requiring "author attributions" in 7b as a permissive clause, I took the liberty of adding this as an explicit sort of display feature that would be most appropriate. If there are a list of author attributions, this seems also a place where acknowledgement of a work would be appropriate. By "credit" I'm thinking of the standard verb definition, to "Publicly acknowledge someone as a participant in the production of (something published or broadcast)." It seemed both succinct and to the point given the current context. By "this work and its development project" I mean that the attribution should not focus on the copyright holder(s) or contributors directly, but rather include the name of the work itself and its developer community. The FSF acknowledged "Powered By " as a valid author attribution as the GPLv3 was being discussed. I'd like to make this more clear, since developers are often rather anonymous, wishing broader recognition through the name of the projects they contribute. Besides, listing dozens of people is almost certainly tedious. By "commensurately", I mean that the effect of this attribution requirement is both done in a similar style and in a manner proportionate to the relative contribution. So, I'd expect if there are a bunch of project logos with hyper links on such a display, then one should probably find the correct logo for the current software package and hyper link it as well. Or, equivalently, if the display is simply a 8pt courier listing of projects in an HTML block, then this clause would ask for nothing more. Finally, that the position of an acknowledgement would reflect a relative ranking with regard to other components. This proposed license doesn't require the preservation of an attribution/copyrights display feature, even though the GPLv3 may consider it permissive. This is deliberate, I think it is completely consistent with MIT/BSD philosophy to permit removal of such a display in a derived work. I very much look forward to any commentary. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
So that we can track changes in the license draft and corresponding interpretation, please visit the GitHub project... https://github.com/hattip/fmn Thank you kindly, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
Sorry, the repository is https://github.com/tip-o-the-hat/fmn#readme ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
On Sun, Jan 22, 2012, at 10:54 PM, John Cowan wrote: > > Since I'm not a legal professional, I'd prefer someone who is > > associated with the Open Source Initiative to provide some > > guidance if they might feel inclined. > > I realize that. However, I think you have done about 80% of the work to > kick off the license approval process (see http://opensource.org/approval > for details), and should just go ahead with what you've got. If you > don't do it, no one else is likely to. > John, I submitted it per your request earlier, but have since made another revision of it. So that anyone interested can follow its development, I'll be sticking with GitHub for revisions. I also sent the link over to debian-legal to get their opinion. I've updated a discussion of the language, so that my logic can be evaluated -- https://github.com/tip-o-the-hat/fmn#readme Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
As an update to this thread, I don't see a way to create an generic and effective attribution clause for MIT/BSD that is compatible with the GPLv3, so for the moment, I'm focusing on an incompatible method. If anyone is interested in following up with creating a compatible method, I'd be very interested in having compatibility. I'm going to continue my effort focused on a commensurate attribution clause as a MIT derived license. I'll track this work at https://github.com/tip-o-the-hat/fmn#readme ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] TCPDF license: LGPLv3 + a special clause: is this still considered "Open Source"?
On Wed, Feb 1, 2012, at 01:55 AM, Chris Travers wrote: > Does the GPL v3 give you the permission to drop legitimate > copyright notices from software or accompanying documentation? As you note, the GPLv3 7b provides the right to require the preservation of legal notices and author attributions in the material that an author has copyright for; and any derivative works of that material. > I would add further that the requirement for attribution/copyright > notice seems entirely in line with the 7b attribution terms. I don't > see why you have to see this as a new license. This requirement was completely different. It was an attribution in dynamically generated content, the generated PDF, which is not their copyrighted material but instead the output of their program. That said, programs that include boilerplate copyrighted material in their output (Bison) might require that the output itself be released under the GPLv3. However, it is traditional for the FSF to provide an exception for this case. Even in this case though, if the output might be considered a work "based on" the processor itself, it not be an interactive user interface, so I'm not sure if 7b would apply. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
As an update to this thread, I've revived my interest in trying to keep GPLv3 compatibility with this approach; a reasonable, attribution terms for a MIT derived license or the GPLv3 itself (under 7b). However, I've expanded the scope of this beyond simply crafting a license that requires attribution. For this sort of project to work, it requires community engagement from the ground up -- even for works that don't have this sort of requirement. Hence, I've started an open source project for effective attribution for OSS projects. If you are interested, I'd love to have collaborators. http://tip-o-the-hat.org In some ways, the license is dead last. The order of priorities are: 1. Create a set of open source components that can be used for the visual display of OSS attributions in a manner that satisfies both the GPLv3 requirements as well as being broadly useful enough for projects to incorporate. 2. Create a registry of OSS works and dependencies with pretty logos, license terms, and others. This would be automated using various distribution manifests as possible. 3. Encourage adoption by open source projects even if such an approach isn't mandated by any license -- it's just the right thing to do. I'm sure others will agree once it is convenient and easy. Then, only then, would there be sufficient community backing to consider the need for licensing terms to enforce an emergent consensus on acceptable attribution practices for those who might otherwise wish to not play along. However, these terms should have a clear interpretation as voluntarily implemented by a wide variety of projects. Thank you for listening. I hope you might engage. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
Karl & Rick,
I'm proposing that we implement a open source catalog and credit system
so that it is convenient for applications to display a graphical screen
(or textual menu) listing all of a works component parts, information
about them, copyright statements, license information, perhaps
contributors, and most importantly project name, location and logo.
If (and only if) this system for acknowledgement is adopted broadly by
the community would it be time to formalize the practice that is
voluntarily followed, and making it a legal requirement for those
who would otherwise wish to hide this attribution from their users.
...
Let me start with some background to explain why I'd want this.
First, the mostly irrelevant part. We have an excellent medical
informatics project, RexDB (http://rexdb.org) which we are preparing to
release under the AGPLv3 with the 7b attribution clause as currently
deployed by SugarCRM and Zarafa. I want to stress that the ability to
have a non-removable "Powered By" logo such as this was essential part
of getting board approval. Since we won't have a "Professional"
version, the ability to advertise our company as the authors of this
work is quite important for our services and support business model.
That said, what I'm proposing here isn't badgeware.
So. It seems our *capstone* work, RexDB, will have some rather potent
branding ability... but what about the works we've built upon? This
seems kinda like a 1967 Volvo Wagon that happens to have a 427 Hemi, T56
gear box, and a special made titanium drive shaft under the hood. While
we coo loudly about this sort of stuff to our more technical customers,
we don't really have to. We stand on the shoulders of giants. Yet, it
has never been a super high priority to formally have any sort of
prominent attribution for those works that are absolutely essential
to our work and our company's productivity.
I'd like to fix that. In particular, I'd like to dogfood it, so that
our forthcoming RexDB release has a prominent attribution, for all the
stuff we're built upon: Python, PostgreSQL, FreeBSD, and dozens of
others. Even if they don't otherwise require it. So, badgeware isn't
the answer since it doesn't scale: here's no way that having two dozen
badges at the bottom of every page will not work. One is ugly enough.
What is the answer? So, interestingly enough, I think it is exactly
what the other part of GPLv3 7b permits you to request: reasonable
author
attribution in the Appropriate Legal Notices ("ALN") for works
containing the Software. The requirements of the ALN itself are quite
strong; it has to be prominent and convenient feature, accessible from
every interactive user interface of the system.
So. I think the answer isn't to start with legal language, but rather
to build the mechanism and then seek voluntary adoption. If that is
achieved by the "inner circle" of our various open source communities,
then we could talk about how to formalize it as both a standard
"non-permissive" term to the GPLv3 and also as a new MIT+Attribution
license (that is compatible with the GPLv3).
I hope this helps. So, as such, I'm not asking for specific license
feedback now or even approval. However, a broad discussion on this
topic might be quite useful and of course I'd love to have others
engaged with me so that it's a shared & broadly supported idea.
That is... if it even makes sense.
Best,
Clark
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
On Wed, Feb 1, 2012, at 05:16 PM, Karl Fogel wrote:
> Rick Moen wrote:
> > I'm generally doubtful about new licences without a really
> > compelling reason, and the whole sordid badgeware episode
> > from 2006-7 tends to make me particularly skeptical of novel
> > licences talking about 'reasonable attribution terms'.
>
> Basically my feelings too, FWIW.
I think there is room for an otherwise permissive license that
requires attribution of component parts to be presented to users
in a tasteful manner that provides acknowledgement. Closing this
gap is important for libraries and other "under the hood" software
that would otherwise be completely invisible.
As such, this isn't at all like requiring a badge. We're talking
about dozens of components in most modern systems, and those are
further derived from dozens more. I think it's an engineering
problem to create a catalog that stores this and a compelling and
broadly useful user interface screen to display this information.
>From those who routinely write permissive libraries, filling this
gap would be a boon. Currently, you're either permissive or
copyleft... there's no middle ground. I think a requirement on
works "containing" your work that asks for tasteful attribution
but is not a full-blown copyleft to be a very nice sweet spot.
On Wed, Feb 1, 2012, Rick Moen wrote:
> I personally consider most licence requirements for
> 'visual display of OSS attributions' to be at minimum
> a bit obnoxious
I think a solid test for this approach is if applications would,
of their own effort, deploy such attribution without being
compelled. If the practice is accepted broadly enough, then we
could consider a license which would compel the practice for
those who would otherwise not participate.
> However, even SugarCRM, Inc. could see that that was going to eventually
> boomerang on them, so they wisely moved to Affero GPLv3 starting with
> Sugar Community Edition 6.
I'd note that SugarCRM retains in their latest release the 7b
"Powered By" additional non-permissive term.
On Wed, Feb 1, 2012, at 05:30 PM, Rick Moen wrote:
> The term 'attribution' tends to be used for a variety of different
> things, so you may wish to start there.
Yes. Perhaps using the word Acknowledgment may help; I don't know.
> Classically in software, it refers to copyright notices, e.g.,
> in source code. In the last decade, the aforementioned group
> of Web 2.0 / SaaS hucksters started referring to mandatory
> runtime advertising as 'attribution'
It is seen as part of the quid-pro-quo from those releasing their
work. Like it or not, advertising and attribution are pretty
much on the same spectrum.
For grant/contract based businesses, although one is officially
paid for new works, your engagement is based upon reputation,
and, for this purpose you need to have public acknowledgment.
If no one knows the extent of your work, it's difficult to get
sponsorship, contracts, or grants.
Anyway, what's is most problematic about badgeware requirements,
and indeed is a feature from the businesses using such terms, is
that it discourages other commercial uses.
> http://linuxgazette.net/159/misc/lg/sugarcrm_and_badgeware_licensing_again.html
I think Richard Fontana has some nice background on this:
http://lists.debian.org/debian-legal/2011/12/msg00038.html
http://lists.debian.org/debian-legal/2011/12/msg00049.html
http://lists.debian.org/debian-legal/2011/12/msg00045.html
I will say that the wording SugarCRM uses implies to me that
adding additional screens requires you to include their badge,
which I'm absolutely sure isn't accurate. The 7b clause talks
about *preservation* of attribution in materials, not the
injection of false attribution into someone else's work.
> 'Visual display of OSS attributions' required via GPLv3 clause 7b
> sounds a whole lot like the aforementioned Web 2.0 / SaaS notion of
> 'attribution' and difficult to distinguish from what SugarCRM did
Ok, so here's GPLv3 7b, noting that 'material' is defined
above is stuff "you add to a covered work":
Requiring preservation of specified reasonable legal
notices or author attributions in that material or in
the Appropriate Legal Notices displayed by works
containing it; or
So, I read this as having two parts. The first part is what
enables badgeware. Your "Powered By" graphic is part of the
material you added and since it is an attribution, you can
require that it not be removed.
Requiring preservation of specified reasonable legal
notices or author attributions in that material
However, there's the other conditional sentence...
Requiring preservation of specified reasonable legal
notices or author attributions in the Appropriate
Legal Notices displayed by works containing it
This is the part I'm thinking might work as a basis. The
Appropriate Legal Notices ("ALN") is explicitly defined earlier
as being something akin to an "About" box with legal notices.
Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?
On Wed, Feb 1, 2012, at 11:33 PM, Richard Fontana wrote: > A key thing which I've seen abused is an elimination of the intended > limited scope of the "Appropriate Legal Notices" requirement. While in > theory a GPLv3 licensee may be subject to this requirement under some > circumstances, the way one implements ALN is up to that licensee, and > cannot be mandated by the upstream licensor. Yes, "reasonable author > attributions", including in some cases graphical logos, may have to be > "preserved", but one could do so in a far more minimalist fashion than > the upstream licensor had done, for example. The limited scope here is important and critical for something like this to both socially acceptable and implementable. The flexibility is important, since each platform, technology, UI toolkit, and application might have its own style and limits. In summary, a license term would require attribution within an About dialog or something like it. Perhaps along side a dozen or more other attributions and legal notices. The primary question becomes what does reasonable mean? The best I can come up with is a copyleftish like requirement, where you leave it vague and ask for "commensurate prominence and stylistic treatment" as compared to the works own branding. In my opinion, when you do open the ALN, attributions should be visible and convenient to explore. While not at the same level as a works' own branding, not completely buried within a long enumeration of legal notices and license texts. Finally, there's one word that concerns me, *preservation*, it seems this limitation might apply attributions in an ALN. For them to be preserved, they must already exist in something that would qualify as an ALN? What if it is a library... with no interactive interface? Could you ask that attribution come from a packaging Manifest (debian/control, EGG-INFO, or equivalent). Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] Submitting CC0 for OSI approval
On Sat, Feb 18, 2012, at 03:22 PM, Simon Phipps wrote: | Given CC0 expresses a willingness to license, surely an estoppel | is created regardless of whether the abandonment is effective? I'm not a legal professional, but I think it's the exact opposite, in *no* case is a patent license granted: section 3 is quite clear that only "Copyright and Related Rights" are granted and section 4a that explicitly excludes any patent license. As a thought experiment, would something I think equivalent, like this Crayon license be acceptable to the OSI? Permission, *only under Copyright and Related Rights*, is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: No trademark or *patent* rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. P.S. I'm cc'ing people since my posts are being held in the moderator queue. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] What would be necessary to consider the unlicense?
On Sun, Feb 26, 2012, at 03:03 PM, Chad Perrin wrote: > On Sun, Feb 26, 2012 at 12:28:03AM -0800, Rick Moen wrote: > > Defective efforts like 'Unlicense' are what happens when naive coders > > attempt to create permissive licences, with results about as sad and > > unfortunate as would be the case if typical coders were to attempt to > > practice law. > > . . . and yet, the Unlicense is lengthier than (for instance) the ISC and > MIT/X11 licenses, which are better written from a legal standpoint. > That's because the Unlicense is trying to *do* more, and not just because > it wasn't written by lawyers or with lawyers on tap to help tighten up > the language for legal purposes. I suggest that the Unlicense should be considered for OSI approval. If it is a broken license, perhaps those with legal expertise might provide suggestions to fix it? Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] What would be necessary to consider the unlicense?
> I am having trouble finding a benefit that would come from fixing it, > that we don't already have from short-and-sweet licenses like BSD. So, what makes unlicense and these public domain statements alluring is that they serve as vehicles for their authors make a statement about public policy. The MIT/BSD simply don't make a public statement this way, and hence, they don't have that sort of irresistable attraction. I think what CC0 has taught us is that this same public policy vigor should be directed towards intellectual property broadly, including an abandonment of patent and database rights as well as copyright. > What you would to be "as good as" BSD would be a public domain > declaration coupled with a covebroanant not-to-sue that extends to the > patent claims of the dedicator that are necessary to utilize the work > as it was dedicated. And a warranty disclaimer to protect the donor. *nods* > It ends up not being shorter nor simpler. How short could it be though? I suggest we get a "github" or other repository, put in some draft language, and hack at it. Perhaps we could help the original authors of Unlicense produce a 2.0 version that adds "we hate patents too!" feature that would be worth upgrading? Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]
(moving my comment back to license-discuss) On Mon, Mar 12, 2012, at 10:29 AM, Tzeng, Nigel H. wrote: > Frankly, what I want is the family of CC licenses for software. Then > devs without some philosophical axe to grind will have a wide range of > very permissive to moderately restricted software common licenses > to use as needed on OUR terms. Hear! Hear! Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License which requires watermarking? (Attribution Provision)
> Therefore should say on all interface screens > "Foo, a project by Google" or, if a fork: "Bar, a > fork of the Google project Foo" with a link back > to its github repo. This requirement is just too asymmetric. What about credit to the database glue you use? What about the language? What about the other free software library you use? I believe it is unfair to shuffle those projects under the carpet even if they don't have such a requirement. Your license should be designed such that you'd be very happy if everyone used the provision you propose, and in particular, that your work would comply with respect to others' work. I do think that there's room for an otherwise permissive license to require reasonable acknowledgement in a manner compatible with GPLv3. It would require that any derived work with an interactive interface have a prominent way to display copyrights & other legal notices. Then, it'd require that your software project be mentioned in those notices, in a manner commensurate with other components of the whole work. There are two parts to this. First is community acceptance: finding wording that is reasonably clear, effective, yet short enough to satisfy those who are interested in a "permissive" license isn't an easy task. Second, and perhaps more importantly, compliance must be quite trivial -- this requires somesort of registry with just about every commonly used open source work included, as well as a convenient mechanism to use this registry to build a compliant legal notice and acknowledgement visual display. So, the outcome of this would be some sort of visual menu that can be easily accessed, where your work would be one of dozens.I do hope to engage in a project like this when I have some time and can find collaborators who agree on an sensible vision. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
On Sun, Aug 18, 2013, at 02:25 PM, Eben Moglen wrote: > You seem determined to take offense, Mr Cowan. Dr. Moglen, I'd like to highlight Cowan's advice since I've found it very helpful (and completely un-obvious) in my own life: "Civil apologies require confession, contrition, and promise of amendment." Just a few years past, my younger brother called me out with a similar message and I very much lost it.However, after a few *years* (20?) reflection I came to understand I was very wrong, and that my distraction, distortion, and false apology were morally corrupt baggage. John isn't trying to hurt you, he's trying to help you grow as a person ... if he didn't care about the community and Free Software he would remain silent. Kindly, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Unlicense CC0 and patents
Prashant Shah wrote: > CC0 explicitly states that it doesn't grant patent rights if there are any. Is > this not going against the purpose of putting the work in public domain itself? The rationale, as I understand, is that a group in a University or other large organization would like to make their work publicly available, but don't wish to have the expense of clearing it with the intellectual property department. In other words, they explicitly wish to reserve patent rights and don't want the public domain dedication to interfere with their ability to collect licensing. The FSF considers works released under CC0 to be "Free Software" [1], but, the rationale for this determination was never disclosed. Perhaps because anyone could sue for patent infringement regardless of copyright? The OSI couldn't come to an agreement on the fallback license, since it explicitly withheld patent rights [2]. Clark [1] [1]http://www.gnu.org/licenses/license-list.html#CC0 [2] [2]http://opensource.org/faq#cc-zero References 1. http://www.gnu.org/licenses/license-list.html#CC0 2. http://opensource.org/faq#cc-zero ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Unlicense CC0 and patents
On Thu, Aug 22, 2013, at 07:04 PM, Rick Moen wrote: > > The OSI couldn't come to an agreement on the fallback license, since it > > explicitly withheld patent rights [2]. > > Well, sort of. My recollection is that some of the folks on > license-review including me merely suggested to CC that they should > consider just dropping the withholding-patent-rights language completely > (for the reasons cited in OSI's FAQ). I don't think anyone on > license-review said it was, to borrow the expression, a deal-breaker, > just a bad idea to put into a licence generally. Is there any good reason why an individual shouldn't use a dedication and and fall-back license derived from the CC0 by removing the patent clause? I know the Copyright Commons didn't want to publish an alternative, since it would dilute their message. However, perhaps someone could strike the words "or patent", give it a fancy name, and submit it here? Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
