|
BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law |
|
Sunday, January 14 2007 @ 02:34 PM EST
|
Brendan Scott has been studying the BSD license, particularly in the context of Australian law, and he has come up with some startling questions. Is the BSD license as permissive as we've thought? The paper is principally for lawyers to consider, but it's certainly of interest to everyone, and note his disclaimer: Nothing in this paper is legal advice or a statement of the
law. This paper is an exposition of an (untested) argument as to the
effect of the BSD license. Scott will be speaking at the Gaming Miniconf at LCA2007 in Australia on Tuesday at 11:15 if anyone wants to discuss the paper afterwards. The paper is also available in PDF format.
*************************
BSD – The Dark
Horse of Open Source
Brendan
Scott* Open
Source Law www.opensourcelaw.biz inquiries@opensourcelaw.biz January
2007
Abstract1
We observe that
there exists a broad misconception that the BSD permits the licensing
of BSD code and modifications of BSD code under closed source
licenses. In this paper we put forward an argument to the effect
that the terms of the BSD require BSD code and modifications to BSD
code to be licensed under the terms of the BSD license. We look at
some possible consequences and observe that this licensing
requirement could have serious impacts on the unwary.
Note/Disclaimer:
This discussion is limited to likely effects under Australian
law. Some of the arguments made are of a generic nature and might be
profitably applied in other common law jurisdictions, such as the UK
and the US – but, then again, they might not. Open
source licenses have been subject to little judicial scrutiny to
date. Nothing in this paper is legal advice or a statement of the
law. This paper is an exposition of an (untested) argument as to the
effect of the BSD license.
1. Discussion
and Assumptions
1.1 It seems that
the collective wisdom is that once you acquire BSD code, you can
license it to others under any terms you like, including on the
terms of a closed source license.2
The received wisdom is that the BSD has minimal restrictions on
what can be done with the code. In particular, there is the view
that its terms do not need to apply to derivative works made from
BSD code. Take the view of Microsoft, for example:3
"The BSD license places no substantive restrictions on software
developers as to subsequent use in derivative programs and licensing
of those programs. The BSD license allows programmers to use, modify
and redistribute the source code and binary code of the original
software program, with or without modification. Derivative works can
be either open source or commercially licensed." [presumably,
taken in context, "commercially licensed" means licensed under a
license other than the BSD]
1.2 This nature of
the BSD is something which can easily be taken on faith. We don't
assert that this view is universal (as some of the references in
the rider show), but it certainly does appear to be prevalent. We
consider that the view evidenced by the references set out in the
rider is, more likely than not, incorrect. In this paper we look
at a number of scenarios and analyze some consequences of the
application of the BSD to software code.
1.3 An assumption
made by this paper is that licensees are granted their license by
distributors, and not by the original licensor. The mechanics of
license propagation is not one specifically addressed by most open
source licenses. There seems to be an assumption that when a
person gives a copy of (open source) software to a third party, the
giver also grants a license over that software to that third party.
This method of licensing is assumed in this paper. There is
another interpretation of the license mechanism, which is that the
original licensee has already granted a license over the software
to everyone, and the giver is simply notifying the recipient of the
terms of that license. We note that draft 2 of version 3 of the
GPL specifically addresses this issue, adopting a hybrid position
by which the original licensor grants a license to the recipient
automatically at the time of receipt of the code.4
Where relevant, comments on the effect of this alternative
licensing interpretation (ALI) are made in the article. These are
marked “ALI”.
2. What
are the terms of the License?
2.1 The text of
the BSD is as follows (our numbering – it is this numbering which
is used when we refer to “clause x” of the BSD):5
1 Copyright (c) , [YEAR], [OWNER] All rights
reserved.
2 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
3 * Redistributions
of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
4 * Redistributions
in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other materials provided with the
distribution.
5 * Neither
the name of the [organization] nor the names of its
contributors may be used to endorse or promote products derived from this software without specific prior written permission.
6 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 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.
2.2 The logical
flow for this analysis is to consider distribution of BSD code in
source and object form, with and without modification. We consider
each of these scenarios separately in the following paragraphs.
3. Redistribution
in Source Form without Modification
3.1 Consider the
situation where code licensed under the BSD license is
redistributed6
in source code form and without any modification. Normally, the
reproduction of the source code of software involved in such a
redistribution would be an infringement of copyright. Therefore in
order to distribute the code legally, the distribution would need
to be permitted by a license. Clause 2 clearly permits a person to
redistribute that code providing that they comply with clause 3.
Clause 3 requires the retention of “the above copyright notice”
and “this list of conditions”.
3.2 This begs the
question: what is the legal effect of being required to retain
“this list of conditions”. Are they just there for show? Do
they have some other effect? In determining this, a court will
look to the objective meaning of the clause and,
potentially, the objective intention of the party granting
the license. In this case, the actual subjective intention of the
party granting the license (and what they thought the words meant)
is irrelevant.7
What the court is looking to determine is what the reasonable
person (ie an idealized and dispassionate citizen who is called on
to assess the scope of the license) would make of the words.8
3.3 Consider first
the warranty disclaimer. If there is a requirement to “retain”
a copy of the warranty disclaimer in a redistribution, is a court
likely to say the warranty disclaimer is intended to be effective
or not? For example, could the disclaimer be retained but framed
by a redistributor in such a way that the disclaimer had no legal
force?9
It is likely that the reasonable person would read the license and
think that the licensor intended that the warranty disclaimer was
to run with the redistribution without qualification.
3.4 On this
analysis, the warranty disclaimer travels with the distribution and
the distributor has no ability to qualify it. The question then
becomes what about the other clauses? What about clause 2 which
permits “redistribution and use” of the source code? If, in
the case of the warranty disclaimer, the objective intention of the
requirement to “retain” or “reproduce” the warranty
disclaimer is that the warranty disclaimer is a condition of the
distribution, why should the same reasoning not apply to the terms
in the “list of conditions”? Moreover, if the warranty
disclaimer is operative as a condition, what basis can there
be for arguing that the other clauses are not?
3.5 If the
other license terms are operative, then the combined effect of
clauses 2 and 3 is that redistribution of the source form must
occur on the terms of the BSD license. A
similar argument leads to the same result in respect of
redistribution in object form. There is a certain element of
common sense to this conclusion. If the license terms are not
operative, any later taker could legally vary the requirement that
the warranty disclaimer be included. Moreover, if anyone could
license the code under different terms, then any person
redistributing the unmodified code10
could remove the warranty disclaimer and other terms, removing the
protections expressly included by the copyright holder.
3.6 It is a corollary of the above that if a copyright holder wants a
warranty disclaimer to travel with the code, then they must include
a condition to that effect, and that condition must travel with the
code to at least the same extent that the disclaimer is intended
to. In short: to be effective licenses which include a disclaimer
must be infective.
ALI
3.7 Under the ALI the conclusion in this section follows automatically
because the ALI assumes that third parties have already been
licensed under the BSD and that the inclusion requirement simply
puts the recipient on notice of the license terms. Note that the
ALI would not permit licensing in this case under a different
license as it assumes that the giver is not licensing at all.
4. Reproduction
in Source Form With Modification
4.1 We now turn
our attention to the case where modifications are made to the
source code, and redistribution of the source code with those
modifications occurs. Above, we concluded that the BSD license
applies to the unmodified source code. Does it also apply to the
modifications?
4.2 Clause 3
simply talks about “Redistributions of source code”. A
distribution of modified source is a distribution of source code,
so clause 3 applies – a copy of these terms must be included with
the modified source code. The wording does not support
identification of a specific subset of the source code (ie the
portion which is unmodified) for the license to apply to. Assuming
our analysis above applies, then by including the license terms
with the modified source code will make those terms (in particular,
the rights to distribute and use in clause 2) apply to the whole
of the modified source code as
redistributed.
ALI
4.3 The situation
under the ALI is probably similar to the argument above about
framing the warranty disclaimer. By definition under the ALI no
license is granted by the giver over the original code. This
raises a question about the “gap” between the original code and
the code as modified. This gap can't be licensed by the original
licensor since it's not theirs to license. However, the original
licensor has mandated specific wording to be included which
purports to apply to the code as a whole (ie as modified). The
question would become – is it reasonable to read these words as
permitting a similar form of framing to that discussed above (in
paragraph 3.3/note 9)? In this respect, two clauses (the warranty
disclaimer and the clause 5) imply that the terms of the license
are intended to address some of the interests of contributors to
the software.11
The references to “contributors” in these clauses would be
meaningless if the license terms only applied to the original code
and when assessing competing interpretations of the license. As
these references to contributors appear to be very deliberate, it
would be inappropriate to prefer an interpretation in which they
have no meaning. As such, it is unlikely that the license would be
interpreted as permitting such framing and the ALI is therefore
likely to lead to the same result. Under the ALI there may now be
two licences, one from the original licensor relating to the
original code, and one from the contributor relating to the
modifications.
4.4 A counter
argument may be that the copyright statement (clause 1) may be
wrong in the case of modifications and the BSD does not provide an
option for the addition of other copyright notices. This is
difficult, but not impossible, to reconcile with the interpretation
above – for example, if clause 1 of the BSD is intended to vest
copyright in modifications in the original author it will be
consistent with the above interpretation (and, incidentally with
the ALI). Such an interpretation would, no doubt, cause some alarm
and therefore should not be preferred without substantially more
analysis. In this context that clause 6 exquisitely draws both the
distinction between the “copyright holders” (plural) and
contributors and the “copyright owner” (singular) and
contributors. However, if not reconciled (either in this way or as
a drafting error),12
it is difficult to see how the BSD can be consistent (under the
ALI) except by reading the references to contributors in clauses 5
and 6 as having no meaning.13
5. Binary
Form of Modifications
5.1 A similar
argument to that for source code applies in relation to modified
binaries. Arguably therefore, if you have modified the object form
of BSD licensed software then when you distribute it your
modifications must also be licensed under the terms of the BSD
license.
5.2 One might
argue that, in the case of binaries, most people don't actually
modify the binary form of some software. Rather they modify the
source code, and compile new object code from that modified source.
That is, the object code is not the original binary “with
modifications”. Rather, both of them are derived from a common
source.
5.3 In Australia
the compilation of source code into object code is itself a
reproduction of the source code.14
In fact, any derivation of object code from source is such a
reproduction. As such, if you modify the source code, you need the
original copyright holder's permission to compile it and to
subsequently distribute it. Where is that permission to be found
in the BSD? If the new object code is not the “source or binary
[form], with or without modification” then there is no right to
distribute that new object code. Either the compilation of the
modified source is a binary form which is subject to the BSD, or it
will be an infringement to distribute it at all (in the absence of
an additional license).
6. Can
BSD Code be Licensed Under a Different License/Closed Source
License?
6.1 We asserted
above the collective wisdom that BSD code can be licensed under
other licenses. There does not appear to be any basis for this
wisdom in the terms of the license. Further, the terms of the BSD
license do not appear to allow more restrictive licensing terms.
This is not to say that the BSD terms forbid them. Rather, the
BSD's usage and distribution rights are so broad, that additional
(parallel) restrictions would appear to be ineffective.15
There is not even any basis on which modifications to the code can
be used to leverage a different license16
– because, as we have concluded above, (if part of a
“redistribution”) those parts which are the original “with or
without modification” must be licensed under the BSD terms.
6.2 We should also
note here that, in the world of licensing, the appropriate starting
point is to assume that what is not permitted is prohibited (at
least to the extent that it is prohibited by copyright or other
laws). The BSD does not include an express permission to license
under different terms, so the ability to license under other terms
can only be arrived at by implication. There does not appear to be
any basis in the words of the license which supports such an
implication.
6.3 One might also
argue that the actions of the community can be taken into account
when determining the scope of the license. This argument may have
force in certain specific circumstances (for example, where a
specific licensor has clearly adopted this broader practice and
made their adoption known), but is probably lacking substance in
the general case. First, it is something of a circular argument –
if the license defines what the community is permitted to do,
anything outside the license is illegal. How can the illegal
actions of members in the community (even en masse) render
their own illegal activity legal?17
Second, how are the “actions of the community” to be
established? Third, why should these actions be implied in the
general case? For example if I write some software, then walk
outside and give it to a passer-by with a copy of the BSD attached,
why should that person's license be determined by anything other
than the words of the BSD included with the software (as it
comprises their entire knowledge of the license and its context)?
Moreover, why should the “actions of the community” be binding
on me as a licensor when I choose this form of words for my
license, especially if I do not reference those actions in the
wording of the license?
7. Does
the BSD Require Availability of Source Code?
7.1 The BSD
license does not have any express provision requiring that source
code be distributed along with a binary. You could argue that by
distributing a binary version of the software you are granting a
license over the corresponding source code (even if the source code
or modified source code is not distributed) since clause 2 of the
BSD permits use and redistribution of the program in source form.
However, if this argument is correct, it would still not lead to
the provision of access to the source code.
7.2 So, even if:
(a) modified
source code is required, in the event of distribution, to be
licensed under the terms of the BSD license; and
(b) the binary
form of the modified source must, if distributed, be licensed
neither of these by itself, nor both taken together, ensure that
anyone will be entitled to access to the source code for that binary.
7.3 It is here
that the BSD's common wisdom has its force. While a license of
object code under the BSD license would presumably require that the
source code for that binary also be licensed under the BSD license
it does not require that access to that source code be provided.
We argue below that this may lead to a false sense of security for
those developing on top of BSD code.
8. Some
Questions
8.1 Assuming that
the conclusion of this paper is true, this raises the following
questions (which this paper leaves open):
(a) is it
legal/effective to modify the attribution clause in the old BSD
terms? Arguably, the practice of modifying the license terms to
add attributions is inconsistent with the license – later takers
would only need to comply with the original attribution clause and
would be free to fail to comply with the additional attribution
requirements;18
(b) how can the
GPL also apply to software licensed under the BSD?19
The additional requirements of the GPL would not appear to be
enforceable in respect of the BSD code. If they are not
enforceable, how can the conditions in the GPL, and in particular
the requirements of clause 2 be complied with?
(c) the absence
in the BSD of a requirement to make available the source code
brings into question whether the BSD ought to have been approved
by the Open Source Initiative (OSI) (for failure to comply with
clause 2 of the Open Source Definition20
(OSD)). There has been inconclusive discussion in relation to
this on the OSI's license-discuss mailing list in 2002,21
the upshot of which was that OSD #2 does not impose a requirement
on the terms of the license and is, rather, a pragmatic
requirement relating to the software itself
and the circumstances under which it is distributed in practice.22
This leads to the troubling conclusion that it is possible for
software to cease being open source software even if its license
terms remain the same;
(d) when a
company incorporates BSD code into some software, then (to the
extent the binaries are modifications of that BSD code) the
company is, by assumption, required to license that software
(including their own modifications and the source code for their
modifications) under the terms of the BSD. We saw above that this
does not mean that the source code must be released at all.
However, what of the situation where the source code subsequently
becomes available? If that was the case, would there be no
copyright infringement for copying and distributing that source
code? This is discussed further below;
(e) what is the
difference between a “modification” and a “derivative work”?
If they are the same, the scope of the BSD's licensing
requirement will be very similar to that of the GPL. Note also
that the BSD only permits the distribution of modifications, so if
there exist derivative works which are not modifications the BSD
does not address whether they can be distributed or even created –
and in the world of licensing that is the same as a prohibition.
Compare the GPL which expressly (but conditionally) permits the
creation and distribution of derivative works;
(f) can BSD
software be included in compilations and are there circumstances
in which a compilation including BSD code is a modification of
that code?
9. The
BSD Blind Spot
9.1 The troubling
aspect about the BSD is not so much the scope of the license, but
the common wisdom that its use entails no risks. Assuming the
argument above is correct there exists a risk (set out below) to
organizations modifying BSD code. This risk is perhaps not likely
to eventuate but, if it does, its effects would be substantial.
9.2 If an
organization modifies BSD code and releases a modified version
then, as we noted above, the modified version will need to be
licensed under the terms of the BSD license. Further, we have
assumed that that the terms of the BSD license give a recipient a
right to copy the source code for that software, even if they only
receive the binary. While it will be of great comfort to know that
the BSD license does not require the production of the source code,
the BSD license permits anyone who already has access to the source
code to distribute it. Of itself, this would appear to
substantially reduce, if not remove, the confidential character23
of the source code. While a person may have held that source
code previously under an obligation to maintain it confidential, is
it not possible that the granting of a BSD license to that person
will remove the requirement to keep it confidential?24
9.3 We must
therefore pose the question – can an employee (or, more likely,
an ex- or soon-to-be-ex employee) who has access to the modified
source code disclose that source code to others if they acquire a
copy of the released BSD binary (i.e. as released by the
organization)? Even without this requirement, if the license of a
binary version can affect the confidential nature of the source
code for that version, then, depending on the timing, this may
affect the ability to apply for patents which relate to the source
code version.
9.4 The
realization of this risk does require the confluence of a number of
different circumstances, not least the enforcement of the original
BSD license. It should not be viewed as an automatic consequence
of the adoption of BSD code. Nevertheless, the risk of the BSD is
that an organization may make a substantial investment in BSD code
on the assumption that that investment code will remain protected
by non disclosure only to find that they cannot prevent an
employee, or third party who gains access to the code, from making
that code public under the BSD license. The end result here is
very similar to that of other licenses (such as the GPL), with the
proviso that organizations adopting the GPL will usually do so with
their eyes wide open to the consequences.25
Those adopting the BSD may find themselves not only blindsided,
but to devastating effect.
ALI
9.5 This risk
would presumably be exacerbated under the ALI as each person is
automatically assumed to have received a license – so the risk
would not be contingent upon a person receiving a copy of the
licensed binary.
10. Conclusion
10.1 If the
arguments in this paper are correct then we can draw a number of
conclusions:
(a) the BSD
appears to require that modifications be distributed only under
the terms of the BSD, and that this requirement therefore cascades
down to subsequent generations of code;
(b) the license
does not appear to permit the relicensing of BSD code under the
terms of any other license, at least in so far as any restrictions
in other licenses would seem not to be binding;
(c) there may be
some scope for arguing that the term “modification” to the
code is restricted or limited in some fashion. However, as the
license only permits redistribution of “modifications” the BSD
does not permit the redistribution of any derivative work which is
not a modification;
(d) the BSD does
not have a requirement for the distribution of source code. It is
not clear whether this means there is a deficiency in the Open
Source Definition.
10.2 Use of the BSD
is not without consequences. While unlikely, the worst case
scenario could be the inability to prevent the disclosure of
modifications made to BSD code – in some cases a catastrophic
result. Use of the BSD license requires the same careful
consideration as the use of any other open source license. The
safest option to follow in these circumstances is to assume
modifications made to BSD code are themselves subject to that
license, and that disclosure of those modifications may not be able
to be prevented.
Rider
What
Does The Community Think About BSD Relicensing?
There
is an inherent problem with attempting to ascribe views to a large
group of people, only the minority of which have been interviewed or
reviewed. As such, technically, this paper asserts without proof
that the BSD relicensing view is widely shared. Posing any
number of references may only be evidence of a specific subset of the
community which holds the view, rather than the community as a whole.
However, in support of this paper's assertion, we include a
collection of quotations from documents which purport to be reference
documents on the meaning of specific open source licenses or on open
source licensing. Except as stated otherwise each of these pages
were accessed on 17 February 2006, and the most recent version of the
document which could be located has been used.
Note the new BSD license is thus equivalent to the MIT License,
except for the no-endorsement final clause. [Note:
on the analysis in this paper they would not be equivalent]
As at 1 March 2006, Open Source Initiative, foreword to new BSD
license http://www.opensource.org/licenses/bsd-license.php
The BSD License allows commercial use, and for the software
released under the license to be incorporated into commercial
products. Works based on the material may even be released under a
proprietary license.
As at 16 February 2006,
http://en.wikipedia.org/wiki/BSD_License (version: 03:25, 8
February 2006 GrinBot m (robot Adding: nl Modifying: hu))
These BSD-style licenses make it clear that you hold copyright and
make no warranty, but that is about it.
Barak A.
Pearlmutter (and others), DFSG and Software License FAQ (Draft),
Revision: 1.84 $ $Date:
2004/11/16 http://people.debian.org/
~bap/dfsg-faq.html
The BSD License grants permission to do whatever you want, as long
as you incorporate the copyright and a disclaimer of liability. This
is one of the earliest open source licenses. Under its terms you may
do virtually whatever you want. For example, you could adapt
BSD-licensed source code to create a proprietary, commercial product.
Pete
Loshin, Open Source Software: Free and Open Source License
Myths http://www.b-eye-network.com/
view/2205?jsessionid=5750033371a735f1d2377e8caa05907c
The copyleft concept is not applicable under a BSD license because
BSD does not include the requirement that derivative works are
subject to the same terms as the initial BSD license.
http://
wiki.flashline.com/wiki/index.php/
Legal%20Issues%20Relating%20to%20Open%20Source%20Licensing
The so-called new BSD license applied to FreeBSD within the last
few years is effectively a statement that you can do anything with
the program or its source, but you do not have any warranty and none
of the authors has any liability (basically, you cannot sue anybody).
This new BSD license is intended to encourage product
commercialization. Any BSD code can be sold or included in
proprietary products without any restrictions on the availability of
your code or your future behavior.
and
Developers tend to find the BSD license attractive as it keeps
legal issues out of the way and lets them do whatever they want with
the code.
Bruce
Montague, Why you should use a BSD style license for your Open
Source Project, (particularly telling, as this interpretation is
critical the arguments in support of the BSD made by this paper)
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html
The "English" version of the license is effectively that you can
do anything you want with the code, but if you use BSD code you can't
sue anybody - you have no warranty and none of the developers has any
liability.
http://63.249.85.132/
fbsd_intro.html
That's it. You can distribute it as either binary, source, or
either, even under a different license (provided that the terms of
the above are met).
http://www.my-opensource.org/lists/
myoss/1999-06/msg00182.html
The users can do whatever they want with the software, including
releasing it as proprietary software, whether modified or not.
Francesco
Potortì, Software licenses, Updated:
2005-04-11 http://fly.isti.cnr.it/
sl/licenses.html
For instance, a vendor could take one of the BSD-licensed Unix
systems, change it slightly, and rerelease it under a completely
closed and proprietary license (ie. no CopyLeft)
FreeSoftware,
http://www.usemod.com/cgi-bin/
mb.pl?FreeSoftware
We also include some
notes of comments where people have perceived or enunciated the issue
and arrived at the same conclusion as in this paper.
I am not at all sure about the legal implications of including BSD
sources into proprietary software, as you have to keep the "list
of conditions" intact, which would include the permission for
redistribution. I've heard conflicting optinions [sic] on this.
--
MartinBaute, Licensing Issues (Last edited on August 26, 2004 8:46
am.)
http://www.mega-tokyo.com/
osfaq2/index.php/LicensingIssues
The BSD gives very broad and extensive permissions to second
parties. But one permission it does not give is the right to change
the license. (28 Jan 2000)
Certainly someone could take my BSD source, compile it, and
distribute it binary only. However, those binaries still have my
license on them and the recipients have the right to redistribute
them themselves. (31 Jan 2000)
Prescient
comments from David Johnson in this discussion in Debian-legal email
list, relating to this message from January 2000 (see also contrary
views expressed in the thread):
http://lists.debian.org/
debian-legal/2000/01/msg00081.html
http://lists.debian.org/debian-legal/
2000/01/threads.html#00081
(thread view)
|
|
Authored by: feldegast on Sunday, January 14 2007 @ 02:52 PM EST |
So they can be fixed
---
IANAL
My posts are ©2004-2007 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.[ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, January 14 2007 @ 02:53 PM EST |
Little pet peeve of mine...
Begging the question, in the context of an argument, is assuming the truth of
the proposition that is in dispute; it is a kind of circular reasoning and a
logical fallacy.
Raising the question is making salient in the conversation an interrogatory
sentential construction.
So in the current context, which is 3.2, "this" (and "this"
is ambiguous here and should be replaced with a definite description) raises the
question you pose - a question that should end with a question mark, not a
period.
Try this:
3.2 Clause 3 of the BSD license raises the question: what is the legal effect of
being required to retain “this list of conditions”?[ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, January 14 2007 @ 03:26 PM EST |
The B in BSD is Berkeley, as in University of California, Berkeley. The
motivation for the license is that as the taxpayers already paid for the
development, it would not be appropriate to limit how any taxpayer could
enjoy
the fruits of intellectual study. A lesser consideration is that since it was
built by faculty and students in order to teach and learn concepts, BSD code
may necessarily require further engineering to produce real world
products.
For an entity, outside of academia, developing code, the GPL makes
more sense,
because they are paying for their own r&d. [ Reply to This | # ]
|
- Stirring times possible? - Authored by: Anonymous on Sunday, January 14 2007 @ 03:43 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Sunday, January 14 2007 @ 04:19 PM EST
- Woof! - Authored by: tyche on Sunday, January 14 2007 @ 05:24 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: vonbrand on Sunday, January 14 2007 @ 09:37 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: digger53 on Monday, January 15 2007 @ 12:19 AM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Monday, January 15 2007 @ 06:22 AM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: PJ on Monday, January 15 2007 @ 10:02 AM EST
- Unpleasant Supporters - Authored by: TB on Monday, January 15 2007 @ 11:03 AM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Monday, January 15 2007 @ 11:58 AM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: chuck on Monday, January 15 2007 @ 12:55 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Tyro on Monday, January 15 2007 @ 01:11 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: eric76 on Monday, January 15 2007 @ 09:54 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Tuesday, January 16 2007 @ 06:35 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: marbux on Monday, January 15 2007 @ 05:02 PM EST
|
Authored by: tiger99 on Sunday, January 14 2007 @ 03:38 PM EST |
As no-one seems to have started one yet. Please remember those clickable
links, where possible! [ Reply to This | # ]
|
- Vista Cast A Pall On PC Gaming - Sidebar - Authored by: tredman on Sunday, January 14 2007 @ 04:05 PM EST
- Open source software on the BBC - Authored by: Anonymous on Sunday, January 14 2007 @ 06:05 PM EST
- News on the Stealth Trademark Guy - Authored by: Anonymous on Sunday, January 14 2007 @ 09:19 PM EST
- Novell sues SCO for US$26m in Unix System V licence fees - Authored by: Anonymous on Sunday, January 14 2007 @ 09:38 PM EST
- Off topic thread here - Authored by: w30 on Sunday, January 14 2007 @ 11:43 PM EST
- UK CItizens : petition the Prime Minister to make software patents clearly unenforcible - Authored by: zr on Monday, January 15 2007 @ 05:34 AM EST
- SCO close to NASDAQ threshold - Authored by: chris_bloke on Monday, January 15 2007 @ 06:43 AM EST
- First conviction in HP leak scandal case - Authored by: PeteS on Monday, January 15 2007 @ 07:21 AM EST
- Alan Cox Files Patent For DRM - Authored by: Morosoph on Monday, January 15 2007 @ 08:36 AM EST
- Apple bullies bloggers. Again. - Authored by: Jadeclaw on Monday, January 15 2007 @ 09:50 AM EST
- Microsoft trial transcripts - Authored by: Anonymous on Monday, January 15 2007 @ 10:23 AM EST
- Unfair Fight - Authored by: cbc on Monday, January 15 2007 @ 01:33 PM EST
- Unfair Fight - Authored by: Anonymous on Tuesday, January 16 2007 @ 07:29 AM EST
- Purchase a Dell PC with Linux preloaded - Authored by: clark_kent on Monday, January 15 2007 @ 01:55 PM EST
- Purchase PC preloaded with Linux - Authored by: clark_kent on Monday, January 15 2007 @ 02:15 PM EST
- Sidepanel: Net Neutrality - Authored by: tinkerghost on Monday, January 15 2007 @ 03:46 PM EST
- new ticker -Forget Neutrality - Keep Packets Private - Authored by: Anonymous on Monday, January 15 2007 @ 04:20 PM EST
- would anyone be interested in - Authored by: Anonymous on Monday, January 15 2007 @ 04:52 PM EST
- Hollywood admits DRM isn't about piracy - Authored by: Anonymous on Monday, January 15 2007 @ 07:12 PM EST
- newsticker-Copyright law changes could leave consumers vulnerable - Authored by: Anonymous on Monday, January 15 2007 @ 09:03 PM EST
- BSD is dying (video link) - Authored by: sgsax on Tuesday, January 16 2007 @ 02:08 AM EST
- Off topic thread here - Authored by: vadim on Tuesday, January 16 2007 @ 04:28 AM EST
|
Authored by: Anonymous on Sunday, January 14 2007 @ 03:48 PM EST |
Yeah, that theory's come up before a couple of times, in discussions of the
various free software licenses (don't have a reference to hand, sorry). The
general conclusion is that while it *might* be true, the BSD license does not
contain any clauses that restrict or command the actions of a person who might
redistribute the software. That means they can't really be sued or in any way
required to provide the modified source - if they give it to you, fine, but if
they don't, then you can only obtain that source through dubious means. Any such
method would likely be illegal in and of itself, without regard to the license.
Consider: assume Microsoft had a piece of software, distributed in binary form.
If one of Microsoft's developers of the software were to redistribute the source
without permission, then while this may not be a breach of copyright law, it is
almost certainly a breach of their employment contract and most likely of trade
secret law too. Thusly Microsoft can pursue legal remedies without having to
resort to copyright law.
So not much has really changed - the entity doing the modification still has
abilities to place restrictions on what happens to those modifications, even if
their ability to use copyright law for this purpose is suspect.
(The implications of this for restrictive-license source distribution, like
Microsoft's "shared source" program, is an unknown - and it's
Microsoft's problem to worry about, so nobody really cares)
The really important implication of this theory is the question of whether or
not you can combine the BSD license with a restrictive EULA that places special
extra conditions on the recipient. That is widely regarded as an unknown - with
no case law on the subject, it's far too difficult even for a lawyer to guess
accurately. As a point of general principle, free software developers usually
dismiss this issue by noting that they really don't care about it, and anybody
who wants to use a restrictive EULA is just going to have to deal with the
matter themselves.
Note that the practice of making special restrictions in a shrink-wrap EULA is
also widely considered by many lawyers to be legally suspect in the first place
- it's based on the notion that a forced, non-negotiated contract is somehow
binding merely because the recipient had the option of not using the software at
all. So nothing's really changed there either - restrictive EULAs have always
been questionable and this is just one more reason to add to the pile.
The basic point is - these things *may* be true (it's generally agreed that we
won't know unless and until the theory is tested in court), but they don't
really have major implications even if they are. Certainly they don't have any
apparent implications that the free software community is likely to care about -
this is a problem for corporations, who can get their own overpaid legal
department to fret over it.[ Reply to This | # ]
|
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Sunday, January 14 2007 @ 05:22 PM EST
- BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law - Authored by: Anonymous on Sunday, January 14 2007 @ 06:38 PM EST
- Leaked software under BSD - Authored by: Anonymous on Sunday, January 14 2007 @ 07:51 PM EST
- UK CItizens : petition the Prime Minister to make software patents clearly unenforcible - Authored by: zr on Monday, January 15 2007 @ 05:30 AM EST
- EULAs are suspect - Authored by: Anonymous on Monday, January 15 2007 @ 07:35 AM EST
- EULAs are suspect - Authored by: Anonymous on Monday, January 15 2007 @ 10:07 AM EST
- EULAs are suspect - Authored by: Anonymous on Monday, January 15 2007 @ 10:24 AM EST
- Link - Authored by: Anonymous on Monday, January 15 2007 @ 10:30 AM EST
- EULAs are suspect - Authored by: gbl on Monday, January 15 2007 @ 01:30 PM EST
- EULAs are suspect - Authored by: Anonymous on Monday, January 15 2007 @ 05:14 PM EST
- Could someone decompile a BSD licensed binary and publish the result? - Authored by: PTrenholme on Monday, January 15 2007 @ 03:23 PM EST
|
Authored by: tiger99 on Sunday, January 14 2007 @ 03:49 PM EST |
I am wondering if the author is merely showing a pro-GPL bias by identifying
flaws in the BSD licence that have no real significance? Having said that, I
personally prefer the GPL, precisely because it does not allow anyone to take
the work of others and make it into a commercial product, while contributing
nothing back to the original author, or the community, as BSD was thought to
allow. He could be saying that the BSD might not allow that either, but I
think he is just saying that the BSD licence is not clear legally, and may be
risky to use. The so-called risks associated with the GPL are well known and
understood, therefore they are not risks at all. All very confusing to a
non-lawyer. I suspect that this will quietly go away, and this time it may
well be that M$ and the FOSS community are actually in agreement. Just think
what it would mean to M$ if their use of BSD code was found to be illegal!
But it would be fun..... [ Reply to This | # ]
|
- MIT/Expat is usually recommended these days - Authored by: Anonymous on Sunday, January 14 2007 @ 06:03 PM EST
- Popular sport - Authored by: Anonymous on Monday, January 15 2007 @ 07:42 AM EST
- Popular sport - Authored by: PJ on Monday, January 15 2007 @ 09:35 AM EST
- With respect ... - Authored by: Anonymous on Monday, January 15 2007 @ 01:27 PM EST
- Great analogy - Authored by: TB on Monday, January 15 2007 @ 11:10 AM EST
- Popular sport - Authored by: Anonymous on Monday, January 15 2007 @ 12:18 PM EST
- Keep going up - Authored by: Anonymous on Monday, January 15 2007 @ 01:34 PM EST
- Popular sport - Authored by: Anonymous on Monday, January 15 2007 @ 03:17 PM EST
- Slightly biased? - Authored by: raya on Sunday, January 14 2007 @ 07:57 PM EST
- Slightly biased? - Authored by: Anonymous on Monday, January 15 2007 @ 08:56 AM EST
|
Authored by: Anonymous on Sunday, January 14 2007 @ 04:31 PM EST |
FWIW, the National
Information and Communications Technology Australia (NICTA) is promoting
something called Au
stralian Public Licence B Version 1-1 (OZPLB) as a BSD replacement license.
They're using it for stuff like Iguan
a, a "base OS" for imbedded systems.
Clearly, somebody in the
Australian government has been persuated that BSD-like "corporate
friendly" licenses, which allow corporations to take public code and make
it proprietary, is better than GPL-like "free market friendly"
licenses, which maximize software market transparency and competition on code
quality -- not marketing -- by ensuring that the codebase is available to every
customer.
Karl O. Pinc <kop meme com> [ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, January 14 2007 @ 05:56 PM EST |
Yes, unmodified BSD-licensed code must be distributed under the BSD license as
he notes.
The normal use case is a large work which contains many modules, with the BSD
code as a single module. The BSD code remains under the BSD license and all its
requirements; it cannot be relicensed and is not relicensed. However, the
*other components* may be under any license. This means that to use or
distribute the work as a *whole*, you need to satisfy *both* the BSD license and
the other, perhaps proprietary, licenses. Unlike the case of the GPL, *this is
possible*.
The case of a heavily modified hunk of BSD-licensed code is similar. This is
the case of a *derived work*, which is subject to two copyrights: the copyright
of the person making the derived work, and the copyright of the person who made
the original on which it was based. The original copyright is licensed solely
under the BSD license, and cannot be relicensed. The derived work's copyright
may be licensed under any license, including proprietary ones. Both licenses
must be satisfied simultaneously, but again this is possible.
This is my non-lawyer's understanding, but I have done a fair amount of research
on this stuff, and this seems to be a consensus view among everyone who has done
any investigation into copyright law as it affects derivative works and
compilation works.
To summarize:
* BSD-licensed code *cannot be relicensed*.
* But it *can be* included in a work with a different license.
This means your proprietary program *must* legally include all those BSD license
statements, warranty disclaimers, and copyright notices; they apply to the
"BSD portion" of the program. I'm not sure what would happen if the
"BSD portion" was deemed to be inseparable from the rest, but that's
usually not the case, as far as I can tell.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, January 14 2007 @ 06:08 PM EST |
People choose the BSD license because they want people to be able to use their
source code in both closed and open products.
If they didn't want them to be use their source code in these ways, they would
choose a different license.
And so, while it maybe possible to come up with some hypertechnical
reinterpretation of the BSD license which conflicts with that intent, doesn't
the authors' intent govern?
And aside from that, who is going to enforce a hypertechnical reinterpretation
of the BSD license, except the copyright holders - nobody but the copyright
holders has standing?
And aside from that, even should a BSD license copyright holder, retroactively
hypertechnically reinterpret the license in this, don't all the same sorts of
arguments that apply to SCO's reinterpretation of AT&T contracts apply: it
didn't mean that at the time, the reinterpretation leads to an absurd result,
the reinterpretation leads to copyright misuse, estoppel, waiver, etc.
Quatermass
IANAL IMHO etc.[ Reply to This | # ]
|
|
Authored by: Arker on Sunday, January 14 2007 @ 06:12 PM EST |
"3.2 This begs the question: "
No it doesn't!
And this guy is a lawyer, so obviously he didn't flunk out of school in grade
two, so he has absolutely no excuse for such an egregious error. I very nearly
stopped reading right there. In fact I did stop. But eventually I came back and
finished the thing, out of respect of PJs opinion that this was important enough
to post.
At any rate, I don't think his thesis is controversial or novel. In fact, he
appears to me to be missing the point. I don't believe, and I wasn't aware
anyone of note believed, that the BSD license allows one to *change* the
license. BSD code can be used in, for instance, GPL code - there is a little,
AFAIK, in the Linux kernel, but it's still under the BSD license. It just
happens to be the requirements of the BSD license and the requirements of the
GPL license can both be satisfied simultaneously. That is, the BSD code is under
the BSD license, the GPL code is under the GPL license, and the work as a whole
must therefore be treated as if it were GPL licensed in order to satisfy the
conditions of both licenses. You can still pull out whatever BSD bits there are
and republish them under the BSD license, but if you use any of the GPL parts
you must treat the combination as if it were GPLd.
And MicroSoft can get away with leveraging BSD code for its proprietary products
because the BSD license doesn't contain any requirement to make the code
available with the binaries. They don't, technically speaking, change the
license of that code - they simply don't publish the code, and the BSD license
doesn't require them to. Am I wrong? [ Reply to This | # ]
|
- Grrr - Authored by: Anonymous on Sunday, January 14 2007 @ 07:05 PM EST
- Grrr - Authored by: grouch on Sunday, January 14 2007 @ 07:57 PM EST
- Grrr - Authored by: Arker on Sunday, January 14 2007 @ 08:06 PM EST
- Grrr - Authored by: PJ on Sunday, January 14 2007 @ 11:54 PM EST
- Grrr - Authored by: Anonymous on Monday, January 15 2007 @ 12:42 PM EST
- Grrr - Authored by: Arker on Monday, January 15 2007 @ 03:03 PM EST
- Grrr - Authored by: Anonymous on Monday, January 15 2007 @ 01:20 PM EST
|
Authored by: russellmcormond on Sunday, January 14 2007 @ 06:13 PM EST |
I disagree with with suggestion that modifications, or other derived works.
should be presumed to be in the same license. When I make a change you end up
with different works which are licensed:
- The original, unmodified
version -- which the originating copyright holder has offered a BSD license for.
I can not *change* this, and if I distribute a modified version I am not in any
way *changing* the license of the original.
- My modifications, which I am
the copyright holder for. I can use whatever license I want for my
modifications. This is one of the things that may be discussed in the
SCO-vs-IBM case, assuming it makes it to trial and SCO doesn't die too
quickly.
- The combination of the original and my modifications. In order to
distribute the whole the license I use and the license of the original need to
be compatible with each other. They don't have to be identical, just
compatible, such that the terms of one do not conflict with the
other.
While it may be possible to create a license which is
incompatible with the terms of the BSD license, I can't think of one offhand
that doesn't involve me somehow stripping the moral rights of the original
copyright holder.
Russell McOrmond
http://flora.ca/
Policy coordinator for CLUE: Canada's
Association for Free/Libre and Open Source Software.
--- Russell McOrmond,
FLOSS Consultant [ Reply to This | # ]
|
|
Authored by: david_koontz on Sunday, January 14 2007 @ 06:54 PM EST |
9.2 If an organization modifies BSD code and releases a
modified version then, as we noted above, the modified version will need to be
licensed under the terms of the BSD license. Further, we have assumed that that
the terms of the BSD license give a recipient a right to copy the source code
for that software, even if they only receive the binary. While it will be of
great comfort to know that the BSD license does not require the production of
the source code, the BSD license permits anyone who already has access to the
source code to distribute it. Of itself, this would appear to substantially
reduce, if not remove, the confidential character of the source code. While
a person may have held that source code previously under an obligation to
maintain it confidential, is it not possible that the granting of a BSD license
to that person will remove the requirement to keep it
confidential?
IANAL, but the issue of open source
licenses is part of my job responsiblities. Looking through Scotts paper, it
appears that all issues derive from the definition of "derivative work". Its
probably safe in general to use the U.S. definition:
Derivative
Works
A “derivative work,” that is, a work that is based on (or derived
from) one or more already existing works, is copyrightable if it includes what
the copyright law calls an “original work of authorship.” Derivative works, also
known as “new versions,” include such works as translations, musical
arrangements, dramatizations, fictionalizations, art reproductions, and
condensations. Any work in which the editorial revisions, annotations,
elaborations, or other modifications represent, as a whole, an original work of
authorship is a derivative work or new version.
A typical example of a
derivative work received for registration in the Copyright Office is one that is
primarily a new work but incorporates some previously published material. This
previously published material makes the work a derivative work under the
copyright law.
To be copyrightable, a derivative work must be different
enough from the original to be regarded as a “new work” or must contain a
substantial amount of new material. Making minor changes or additions of little
substance to a preexisting work will not qualify the work as a new version for
copyright purposes. The new material must be original and copyrightable in
itself. Titles, short phrases, and format, for example, are not
copyrightable.
So, small changes aren't a derivative work, and the
original BSD license applies. Larger changes are a derivative work and the
portion that is under the original BSD license is still covered by the same
license, which gives permission for modification.
The derivative work
author must abide by the license requirements for distribution, these aren't
particularly onerous, keeping the copyright notice in source code, reproducing
the copyright notice and list of conditions in any supporting materials when
distributed in binary form (attribution).
The derivative work author has the
right to control distribution of the authors original works portion of the
derivative work. If the author specifies licensing terms for distribution that
are not incompatible with the original license, he has not violated the license
terms.
As far as the implication as to whether or not the soon to be
ex-employee could re-distribute the source code would depend on whether or not
the modified work qualified as a derivative work, as the author of the
derivative work controls distribution of the portions that are copyrightable by
the author of the derivative work. If the soon to be ex-employee had a safe
determination that a modified work didn't qualify as a derivative work based on
changes involving only elements not coverable by copyright, they could spill the
beans on an embrace and extend scheme.
[ Reply to This | # ]
|
|
Authored by: rsmith on Sunday, January 14 2007 @ 07:26 PM EST |
Use of the BSD is not without consequences.
That
is true for any license, isn't it? You kicking in an open
door.
While unlikely, the worst case scenario could be the
inability to prevent the disclosure of modifications made to BSD code – in some
cases a catastrophic result.
If preventing disclosures of
source code is paramount, why you base your product on open source code at
all?
Use of the BSD license requires the same careful
consideration as the use of any other open source
license.
Well, duh! That's another open door kicked
in.
--- Intellectual Property is an oxymoron. [ Reply to This | # ]
|
|
Authored by: pem on Sunday, January 14 2007 @ 07:57 PM EST |
As others have pointed out, BSD-licensed material cannot be RElicensed, but can
be AGGREGATED with other software under different licenses quite easily. It's
just like IBM's JFS. No matter what SCO's Unix license says, they don't have
any control over IBM's software which can be linked to it.
So this question
in the paper is troublesome (in that it might have the potential to encourage
some employee to do something stupid):
9.3 We must therefore
pose the question – can an employee (or, more likely, an ex- or soon-to-be-ex
employee) who has access to the modified source code disclose that source code
to others if they acquire a copy of the released BSD binary (i.e. as released by
the organization)? Even without this requirement, if the license of a binary
version can affect the confidential nature of the source code for that version,
then, depending on the timing, this may affect the ability to apply for patents
which relate to the source code version.
Since you can only
patent things which have not been publically disclosed (or within one year of
initial disclosure in the US), it is prudent to worry about disclosure by
employees, which is why most companies have (usually one-sided and onerous)
employee IP agreements. Anybody who thinks one of these employee agreements
might be circumventable because some proprietary program contains some
BSD-licensed code is thinking fairly creatively, but perhaps from the starting
point of a GPL mindset.
Unlike the GPL (which is arguably viral, and which
is arguably claimed by Stallman, et al. to be even more viral than might
be supported by law, the BSD license doesn't try to be viral. It doesn't say
you cannot link with incompatibly licensed code; it doesn't try to impose its
own definition of derived work; and it doesn't even have any obligation to
distribute matching source with a binary.
Try this simple thought
experiment. Assume you link some BSD-licensed code with a proprietary library
you have a copy of. Have you caused the proprietary library to be under the BSD
license now? If you distribute the binary, can your customers now redistribute
the entire binary with impunity?
As another poster noted above, Microsoft
and other companies routinely use BSD code. See, for example, these Windows XP release
notes, which state that "Portions of this product are based in part on the
work of Greg Roelofs. Because Microsoft has included the Greg Roelofs software
in this product, Microsoft is required to include the following text that
accompanied such software: Copyright 1998-1999 Greg Roelofs. All rights
reserved." (with the rest of the BSD license text following).
Assume for a
moment that a distributor of pirated copies of Windows is trying to make the
argument in court that, since Microsoft didn't specify exactly which portions of
Windows was composed of the Roelofs code, the distributor can simply assume that
all of Windows is fair game, because at least some of it consists of
BSD-licensed code. Realistically, how far will that argument get the
defendant?
Likewise, if your employer has some internal proprietary code
linked with BSD code, and your employee agreement says to keep it confidential,
you would be a fool if you disclosed the proprietary code and relied on the
strength of the BSD license to protect you. [ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, January 14 2007 @ 08:43 PM EST |
If the binary is just a source translation, surely so is a decompilation?
So is it therefore valid to be able to decompile/reverse engineer binaries
generated from BSD licensed sources, and treat that source as BSD licensed?
!Z
[ Reply to This | # ]
|
- Decompilation? - Authored by: pem on Sunday, January 14 2007 @ 10:07 PM EST
- Decompilation? - Authored by: Anonymous on Monday, January 15 2007 @ 08:05 PM EST
|
Authored by: Anonymous on Sunday, January 14 2007 @ 08:51 PM EST |
Here is how he formatted the BSD license in his
article:
1. Copyright (c) , All
rights
reserved.
2. Redistribution and use in source
and binary forms, with or
without modification, are permitted provided that
the following
3. Redistributions
of source code must retain the
above copyright notice, this list
of conditions and the following
disclaimer.
4. Redistributions
in binary form must
reproduce the above copyright notice, this
list of conditions and the
following disclaimer in the
documentation and/or other materials provided
with the
distribution.
5. Neither
the name of
the nor the names of its
contributors may be used to endorse or promote
products derived
from this software without specific prior written
permission.
6. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 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.
Here is how
the BSD license typically appears in source files (from Wikipedia page on
BSD).
* Copyright (c) <year>, <copyright
holder>
* All rights reserved.
* Redistribution and use in source and
binary forms, with or without
* modification, are permitted provided that
the following conditions are met:
*
* * Redistributions of source
code must retain the above copyright
* notice, this list of conditions
and the following disclaimer.
* * Redistributions in binary form must
reproduce the above copyright
* notice, this list of conditions and
the following disclaimer in the
* documentation and/or other materials
provided with the distribution.
* * Neither the name of the
<organization> nor the
* names of its contributors may be used
to endorse or promote products
* derived from this software without
specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE
REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE
REGENTS 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.
I will ignore the trivial differences in
what the author calls section 6.
Notice the author also omits the end
of section 2.
I think the author has fooled himself as a result of his
reformatting, as well as seeming to assume the entireity of one work must be
under a single license.
I will deal with this entireity issue first, as
it is pervasive through his article, although it really compounds the other
error, which is where I think things first went off the rails. A good example
is in 4.3 and 4.4 he talks about the "gap" modifications as if there is a
problem with them because they aren't covered by the original BSD license). I
think there is no problem, when author A releases under the BSD license, he has
granted author B the right to make modifications/derivatives, and has no
copyright interest in the modifications, and therefore to the extent the
original software is A, it remains under A's BSD license, and the modifications
and additions, are under B's license. That is simply a reflection of a routine
procedure in software licensing (both open and closed). There are many packages
where you get source code or libraries, can use them subject to conditions, but
your own home-grown code remains yours.
Going back to formatting:
Look at section 3.2 to 3.4 in the author's argument. He interprets the warranty
disclaimer (what he calls section 6), as being one of the conditions required
for source or binary distribution. Because he also assumes everything in one
software package must be under one license, he seems to assume the intermediate
entity must duplicate the warranty disclaimer.
Example:
A
licenses under BSD license to B.
B is now giving software to C, let's
say with A's code embedded.
The author seems to assume that B must
somehow replicate the warranty disclaimer to party C (section 3.2 to 3.4 of his
argument). It's not clear whether he thinks (i) that B must do that in its own
capacity, or (ii) do it on behalf of A. Sorry, but I don't think that can be
right.
- If he thinks (i), it can't be right, because B can't modify
A's BSD license and notice to read "B" instead of "A" in section 6.
-
If he thinks (ii), that can't be right, because B can't enter into an agreement
on behalf of A. Where's that power granted?
In other words, if you go
down his route you get a license which permits you to distribute in source or
binary form, but which is impossible to comply with.
So where's he gone
wrong?
As I said: The author seems to assume that B must somehow
replicate the warranty disclaimer to party C (section 3.2 to 3.4 of his
argument)
Why is he assuming that?
Because he has reformat the
BSD license so that the warranty disclaimer (section 6) is one of the conditions
for redistribution.
The warranty disclaimer isn't one of the conditions
for redistribution. It is simply a statement that the redistributor is required
to duplicate in their redistribution.
Quatermass
IANAL IMHO etc.[ Reply to This | # ]
|
|
Authored by: PJ on Monday, January 15 2007 @ 04:30 AM EST |
Pls. can you read our comments policy? Thanks. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, January 15 2007 @ 05:05 AM EST |
It says you can release modified versions as source code under the same
license.
It says you can release modified versions as object code under
the same license.
It doesn't say you can release modified versions
as object code under a different license. Which, by the way, is what
Microsoft has done in the past. Since copyright law prohibits every kind of
copying that is not explicitly permitted by the license, why do so many people
assume that modified object code can be released under a different license? The
wording of the license is clear. Nowhere does it permit this. So copyright law
prohibits it. [ Reply to This | # ]
|
|
Authored by: Ian Al on Monday, January 15 2007 @ 06:00 AM EST |
No, really!
The author noted that, under Australian law, if you modify the source code, you
need the original copyright holder's permission to compile it and to
subsequently distribute it. He asks "where is that permission to be found
in the BSD?".
The BSD does not limit how you use source code or binary code. One of the use's
available under the licence is to compile the source code.
One of the uses available is to disassemble and decompile the object code.
Can Microsoft aggregate BSD code into a larger work under their horrible EULA?
Yes they can. The EULA is not permitted to reduce your rights to the BSD
original or modified parts and Microsoft must make it clear to what part of
their aggregate the BSD licence applies, or not use it at all. That gives you
the rights licenced under the BSD.
So, under the BSD licence you can get a copy of the original source code and
compile it for the target machine also arranging for the intermediate file to be
created of the assembler code. Now, disassemble Microsoft's modified BSD
licenced code. Compare the assembler code for each and you will find out what
Microsoft have changed. You can, now, modify the original source code to
generate Microsoft's object code.
Now, seeing what a pig's breakfast most Microsoft code seems to be, I have to
question your sanity for doing that, but not your legal right.
Moving quickly on, before you become physically sick, let's suppose an
innovative software company has modified a BSD licenced work. The work is on
their development server in both source and binary form with the BSD licence
associated.
Can an employee take copies of either and use them outside of the company in any
way? I don't think so. The employee has a licence so to do, but doesn't have the
legal right. If the employer does anything to restrict copying (including
non-disclosure agreements and armed guards) then the work is a trade secret. The
employee cannot even tell someone else that the BSD work, modified or
unmodified, is a part of the employer's business.
And, if you think about it, that is also true about GPL code that is not
redistributed. Once distributed, both become free, but BSD does not
automatically become open.
---
Regards
Ian Al[ Reply to This | # ]
|
|
Authored by: Brendan Scott on Monday, January 15 2007 @ 07:09 AM EST |
Some responses to some comments:
First: if you can see something wrong with my analysis, please let me know.
Thank you for the comments to date.
Second: Some people are saying it's irrelevant because it's patently wrong,
others are saying it's irrelevant because it's rehashing what everyone knows to
be true.
Third: If you have an established relationship with X, the copyright owner of
program y and X has made clear to you how the licence terms for program y are to
be interpreted, that will trump the words of y - at least if their to your
advantage and in the absence of a contract - "I know the invitation says
black tie, but your massage sandals look just fine, come in anyway"
(arguably it will trump the terms even if the interpretation is to your
detriment - "I know the invitation said massage sandals or better, but
black tie is gauche, go away"). This paper is looking at the general case
where person gives software to another under the BSD and no other relationship
or communication between them can be assumed.
Fourth: some of the formatting and text of the quoted licenses were omitted
during transcription. They have been corrected (although the original uses
angle, not square brackets).
Fifth: the confidentiality question is something which needs more analysis. I
suspect the argument will have more legs in AU than in the US given differences
in trade secret law. In addition, confidentiality is an exercise of a court's
equitable jurisdiction so there is more scope for a court to punish blameworthy
conduct. At its highest it applies only to modifications to the BSD code. But
if you're an employer be aware there could be an issue.
Sixth: Derivative works - not something I can comment on, other than to note
that the BSD doesn't use the term - and to say that (as a US law layperson) I
would be surprised if derivative work and modification were read to be
equivalent.
Overview of paper
The structure of the argument can be mapped out like this:
I take some BSD licensed code a. Copyright in a is held by a third party. I
make substantial modifications to it, producing c (call b the changes to a which
give c). Everyone agrees that c is a with modifications.
If I want to redistribute c then, since it is "a with modifications"
must I include the BSD? If so, given that I know the BSD is a software license,
what is the effect of that inclusion? Can I include it so that it has no effect
on what use a third party can make of c? It is certainly arguable that it is
only a requirement to include a notice which has no legal effect. By looking at
the warranty disclaimer I felt that this is not an interpretation likely to be
preferred because if it was it would permit people to remove the (words
requiring the inclusion of the, and therefore also the,) warranty disclaimer.
Alternative Approach
Another way of approaching the question is to consider if I put the BSD notice
on c and gave it to a third party T - without anything else - would T have a
right to use c? If so, on what terms? I think it is more likely than not that
a court would say T has a license to use c on the terms of the BSD. I think it
is unlikely (eg) that the license would be interpreted as restricted to a, with
b unlicensed.
Counter Arguments
There are counter arguments (especially those based on the inherent ambiguity of
the license - see notes 11, 12 and 13 and related text) but I don't find them
(ie those raised in notes 11-13/associated text) convincing. Some comments
have suggested that the requirement to include the BSD relate only to the
"a" component of modified code. I don't think the terms of the BSD
support that (see paragraph 4.2). I can choose not to distribute b, since it's
my code, but if I want to distribute c then I need to attach the BSD and the
rest is history.
The nub of it all is what is the consequence of including "this list of
conditions".
[ Reply to This | # ]
|
|
Authored by: iabervon on Monday, January 15 2007 @ 01:56 PM EST |
I think the critical issue is what the terms in license terms retained in
redistribution refer to. To start where he starts, I think that a reasonable
person would expect, from reading the license, that Microsoft could offer a
warranty for software they distribute which they received under the BSD license;
the obvious interpretation is that "The copyright holders and
contributors" are the ones Microsoft got the code from, and if Microsoft
retains the original copyright notice and puts their copyright notice (if any,
for substantial changes) elsewhere, they aren't included in this disclaimer.
(Not to say that they can't have their own disclaimer elsewhere.)
Following the interpretation with this additional piece, it seems clear that the
redistribution terms apply to the source that Microsoft received, not to the
source when Microsoft finished with it, or to the binary Microsoft built from
it. So, while the redistribution terms remain in effect, they only apply to
redistribution of the original code. So this only affects the implausible
situation where somebody wants to grant BSD-type rights exclusively to
Microsoft. Maybe they license it to the general public under the GPL, but give
Microsoft a deal which lets Microsoft alone take it proprietary; that wouldn't
work, because anyone who got it from Microsoft would get the license, and (if
they somehow figured out what was going on) could use the license they got via
Microsoft with the source code they got under the GPL.
[ Reply to This | # ]
|
|
Authored by: roman on Monday, January 15 2007 @ 03:54 PM EST |
Here are the parts of the license that are important to me and my understanding
of it as a developer:
Redistribution and use in source and binary
forms, with or without modification, are permitted provided that the following
conditions are met: - this means to me that I can redistribute source and
binary of this software if I satisfy the conditions provided below.
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer. - this means to me that the
text of the BSD license and the copyright notices on this piece of software must
be present in the source when I redistribute the source. To me this only means
that I cannot strip this text from the text of the source.
*
Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution. - this means to me that the
text of the BSD license and the copyright notices on this piece of software must
be present in the documentation that comes with the program. To me this only
means that I cannot strip remove this text from the text of the documentation
when I distribute this program in binary.
* Neither the name of
the nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written
permission. - this only means that I cannot take the name of the
organization mentioned in the text of the license that comes with this program,
nor can I take the names of persons from the same text and use these names for
purposes other than distributing this program further (either modified or
unmodified,) without specific prior written
permission.
--
This is ALL. There is nothing else for me, as
a developer (or for you as a user or anyone else) that this license means. It
is not intended to be a GPL. When I want to use GPL, I use GPL, when I want to
use BSD, I use BSD. They serve different purpose, they are not the same and
they do not mean the same thing.
The lawyers make it possible in court
to turn one thing into something else by manipulating the human
language.
What I would like to do, is to see the laws written in
something like PROLOG with a list of conditions, so when someone wants to know
whether something can be done legally for this law, it would be sufficient to
just throw a question sentence into this program, which would then give an
unambiguous YES or NO response.
In the case of BSD, this machine would
givea NO to the question: is BSD a viral license, like the GPL?[ Reply to This | # ]
|
|
Authored by: PTrenholme on Monday, January 15 2007 @ 04:05 PM EST |
For most people, I suppose, a "binary" distribution would be one made to be
read by a specific computer system in a format specified for that system. And a
"source" distribution would be one of the instructions used (or which could be
used) to produce a "binary" distribution.
But the distinction that the
"source" be "human readable" is not very supportable. There are (an extremely
small) number of people who can "read" (and understand) a binary data steam of
what many would call a "binary" distribution. Or, of course, if we drop the
"understand" almost anyone could "read" the binary representation.
The
observation that the "source" is in at "higher level of abstraction" is not too
meaningful either. Some "source" is nothing more than a list of machine
instructions (assembly code), and a one-to-one "translation" of the "binary"
distribution to an "assembly language listing" is fairly easy.
So what is
the legal meaning of the mention of "source" and "binary" in, for
example, the BSD license?
Or, more germane to GrokLaw, in SCOG's
contention that Novell is only entitled to money collected for "binary"
licenses? --- IANAL, just a retired statistician [ Reply to This | # ]
|
|
Authored by: Jonathan Bryce on Monday, January 15 2007 @ 06:07 PM EST |
I think the answer is in the licence.
Where do you get permission to distribute the program?
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
there then follows a list of conditions.
You have to comply with them, but any other licence that allows you to comply
with those conditions is surely OK.[ Reply to This | # ]
|
|
Authored by: MattZN on Monday, January 15 2007 @ 07:25 PM EST |
I'm sorry, it is just absurd. I tried to read the paper, I really did. I
couldn't follow the argument at all. It just makes no sense. I'm sorry, but it
doesn't.
I've been programming for a very long time and most of my work uses the BSD
license. Everyone who uses the BSD license, and especially those of us who have
used it for decades, knows exactly what it is meant to do because it says what
it is meant to do in plain language. Because hundreds of companies use BSD code
in precisely the way the license allows them to, and sell their proprietary
derived works without disclosing source code because they don't have to, and
have been doing so for over 25 years.
No lawyerese is ever going to change the meaning of the license with that much
use history. We aren't talking about just Microsoft here. We are talking about
thousands of programmers like me who would easily qualify as expert witnesses
all telling the judge the same thing. We are talking about hundreds of
companies (not just microsoft) that use BSD-derived code in proprietary products
every day and have been using them for decades.
This is a nice fantasy I suppose, but that is all it is. I consider it
reckless, actually. Not F.U.D., but definitely reckless. In particular I think
the author should not try to hide behind his legalese and consider the matter
from a more realistic perspective, such as what would likely happen if someone
actually filed a lawsuit on the matter.
-Matt Dillon[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, January 16 2007 @ 12:25 AM EST |
This was the guy who spearheaded an effort to threaten to sue Australian-based
IT Companies "on behalf of Linus" for using the word "Linux"
in their website text in harmless sentences such as "Here at Foobar
Consulting, we can write software for Linux". (For the record, we received
one)
His motiviation here is undoubtedly to increase the number of lawyers involved
in the software development process.[ Reply to This | # ]
|
|
Authored by: jig on Tuesday, January 16 2007 @ 04:54 AM EST |
objectively, i don't see how the BSD license can be construed to do anything
OTHER than to require attribution of authorship of any part of the code provided
to the entity redistributing it in either binary or source form. well, that an
requiring that the disclaimer as to those authors is included in the
distribution as well.
reading it directly indicates this, reading the various interpretations
indicates this also. to guess that an australian court would interpret it in
some other way based only on australian contract law is probably not a useful
endeavor. there might be gotchas, but in general i don't believe that an
australien court would pull something out of thin air rather than look at
evidence of how it's been used in the past (and it's been used, extensively, as
i've described above).
i think the failing i'm sensing in the reading of the license is that the author
is trying to overload the definitions of the license by playing both the part of
a user and a contributor at the same time, and then messing up, temporally, how
things progress to redistribution. the license requires two set of things, one
set if you use the code, and another (encompassing superset) if you use the
license to (re)distribute your work. i can "use" the code but not use
the license to redistribute it, or at least not the full license (i always have
to attribute past authors and reproduce their disclaimer). it can get a little
complex, but it should be a pretty linear analysis. modifications OR derivitive
works don't automatically acquire the burden of the BSD license, at least not
the full license, and not in total.[ Reply to This | # ]
|
|
Authored by: Brendan Scott on Tuesday, January 16 2007 @ 06:26 AM EST |
Intention of licensors
The intention of licensors will not be relevant unless it is communicated. So
if I say A but intend B, the only thing I can hold a licensee to is A. Further,
it is the licensor's intention which is relevant. If I use your license terms,
I can't see any reason (in general) why your interpretation of those terms
should be binding on me/my licensees. In some circumstances they will be (eg if
I specifically reference them or my conduct implies my adoption of your
interpretation) but in the general case - no.
Prohibiting Closed Licenses
The important point here is not whether a person is able to apply another
license, but what would the effect of that license be if the recipient already
has the benefit of the BSD? Any restrictions in a closed license will be
irrelevant as the BSD already permits "redistribution and use". This
affects GPL compatibility as well, although the answer to that may be that the
work as a whole is subject to the GPL.
[ Reply to This | # ]
|
|
Authored by: Brendan Scott on Tuesday, January 16 2007 @ 06:46 AM EST |
I think the defining thought experiment in this is the scenario I outlined in a
post above (and with which, unfortunately, no one seems to have engaged). Let
me restate it:
Assume
1. a is BSD licensed code.
2. Copyright in a is held by a third party.
3. I make substantial modifications to it, producing c (call b the changes to a
which give c).
4. Every reasonable person agrees that c is a with modifications.
Experiment (Part 1):
I put c (and nothing else) on a CD ROM and walk outside and hand the CD ROM to a
stranger.
First question - am I required to retain the BSD license terms when I give the
CD ROM to that person? [My answer - yes]
Experiment (Part 2)
Assume
5. I have retained the BSD licence terms on the CD ROM.
6. There are no other license terms on the CD ROM and I say nothing else to the
stranger.
Second question - does that stranger have a license to use c? [My answer - I
think so, under the BSD, but they may not know it until they read the CD ROM.]
How would you answer these questions?[ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, January 16 2007 @ 07:01 AM EST |
I did not read the paper to the end. I think the author has some fundamental
misconceptions there.
1. The BSD license talks about distribution with or without modifications.
2. It does NOT talk about anything that specifies licensing of modified works.
F.e. GPL clearly states how modified works should be licensed.
3. If you include the writen text of the license in the source or binary where
the original code is used, you have met the requirements of the license. If the
resulting binary has an MS like EULA does not matter.
CONCLUSION: You have to give credit for the original code to the original
author. Source/Binary/Modified/Unmodified DOES NOT MATTER. One exception is that
you strip the copyright etc. from the distributed work, then you have no right
to use the code and you are breaking the license conditions.
COMMENT: Any OSS license has a virulent nature to preserve the rights of the
original author (attribution of authorship). So it has to carry over to all the
modified works. Either by verbatim inclusion of the copyright (BSD) or
restriction to the same license (GPL) as their requirement.[ Reply to This | # ]
|
|
Authored by: rsmith on Tuesday, January 16 2007 @ 07:14 AM EST |
Have you thought to ask the creators of the license what their intent was?
---
Intellectual Property is an oxymoron.[ Reply to This | # ]
|
|
Authored by: Brendan Scott on Wednesday, January 17 2007 @ 04:14 PM EST |
This paper is about discussing the effect of specific words considered in the
abstract - as I hope is clear from the paper's discussion. A number of comments
have asked about the effect of intent and common use. My responses on this
point have been that it can affect the license, but then I've wandered off into
a discussion of the words in the abstract or in the absence of context - which
is the focus of the paper. On reflection this is not an appropriate response
for me as it fails to give proper emphasis to some of the most practical
implications for people in this forum - so let me make some comments about the
practical effects of this argument on existing projects.
If you have an existing project under the BSD then the interpretation in this
paper will probably have no practical effect on you. There are two main reasons
for this. The first is that established projects are upfront in stating what
you can and can't do with the code. If the project has stated that its code can
be used or distributed in a certain way, it would be very difficult to argue
against this (in addition such statements would undermine some of the
assumptions in the paper). The second is that this interpretation is of no
value if the license is not enforced in this way and BSD participants are very
unlikely to do so.
I'm sorry I did not make this clear earlier while the thread was more active. [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 18 2007 @ 03:04 AM EST |
You make a fundamental mistake in your analysis.
In the BSD license, the word "use" refers to, approximately,
"incorporation of the code, or some portion thereof, within another
work". This is not only the intent, but the only reasonable
interpretation.[1]
Therefore, the license *expressly permits* incorporation of the work, or a
portion thereof, within another work (the "containing work"). That
work, whether classified as a derivative work of the BSD-licensed code or not,
may be subjected to additional copyrights. These additional copyrights may not
permit redistribution of the containing work.
1) The license was written assuming U.S. law. Under U.S. law, copyright cannot
restrict what one does with a legitimate copy of a work, other than make copies
of it. Other definitions of "use" generally referring to things like
actually executing the code, which are simply not covered under copyright law in
the U.S. at all.
- mycroft[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 18 2007 @ 03:08 AM EST |
Pursuant to my previous comment, I want to make this point very clear.
You cannot simply reinterpret a license under the laws of a different
jurisdiction. International copyright law simply does not work that way. You
must take into consideration what the license means in the jurisdiction in which
it was written. It seems to me that you have completely failed to do that.[ Reply to This | # ]
|
|
Authored by: Carlos Mundi on Thursday, January 18 2007 @ 01:11 PM EST |
Is it just me, or is this one of the most exquisitely poorly written documents
on the subject of software licensing? Australian and American variants of
formal English are not so different as to disqualify me as an educated reader.
I am not a lawyer, but I have been involved with both commercial and FOSS
software licensing for about a decade. My experience tells me that the refuge
of 'legalese' is not the chief difficulty with this document. This is at best a
first draft of an analysis, and I have to wonder what Mr. Scott's intent was in
releasing it in draft form. I do not dispute the validity of some of the
questions raised by this document. Indeed, the FOSS community would do well to
bring more qualified legal scrutiny to the underpinnings of our IP culture,
including a full account of venues and jurisdictions. I do, however, wonder if
the offered analysis of these questions might have at least a small measure of
FUD as an objective. [ Reply to This | # ]
|
|
|
|
|