On 23 Jul 2000, Grant Bowman wrote:
> This assumes they are considered as the same "work", right? I just
> finished reading the licenses and I saw reference in the GPL that
> seperate, distinguishable works do not need to be covered by the GPL and
> can be distributed together.
This is correct.
> Also, by open source do you mean DFSG compliant or OSI Certified? I
> guess it really doesn't matter much once a license is chosen. For those
> interested, you can see the difference between them by comparing
> http://www.debian.org/social_contract and
> respectively. Hmm, The Artistic License was listed on the DFSG page.
I think the distinction is fairly insignificant. If you can list a
license that we ought to be considering that falls under one definition
but not the other, let us know. In my opinion, any such license that
falls into such category is reason enough to exclude it from
consideration. Incidentally, the Artistic License is OSI-certified.
> Are there specific patents we are concerned about either now or in the
None that I'm aware of. The problem is that companies patent
everything. There's a very high probability that anything we develop will
be covered by some patent. Whether or not that patent is legitimate or
not is another matter.
> Lee, I tend to agree we need a license that corporations "aren't afraid
> of." Maybe this is a gross misinterpretation, but I think those
> software packages would be considered seperate works, so the GPL
> wouldn't apply and may still be acceptable.
What Lee is saying is that it must be possible to incorporate our work in
proprietary software, not just distribute it as separate works. So the
GPL does apply here.
> I am not sure I understand this point fully as you described it. You
> got me curious, so here's another reference license that's included with
This is essentially a reworded BSD license, with some trivial differences.
> The nice thing about open source is that it isn't one company against one
> company. Microsoft hasn't taken over Bind even though they have
> proprietary extensions. If you don't like a way software is used and
> you have the source code, then you have a recourse: create something
> better. I know it's not that easy, but if one of the larger companies
> takes a product in one direction, all competitors have a very low or
> non-existant barrirer to entry, right?
I'm not sure I understand your point here.
> Given some of these licenses, the only way to "proprietarize" anything
> is further development, right? So, what specifically are we concerned
> about having hijacked? A fundamental concept in security is appropriate
> measures. There is probably a more accurate way of saying this, but do
> you need an armored car to drive to the bank every time? If we are
> concerned about this, let's address it, but do we have to worry about
We should be worried about hijacking, but I don't think trying to prevent
it via licensing is the right approach.
> I don't understand completely how to license under both. Is this with
> the use of Exibit A from the MPL?
It's basically making the forking possibilities of MPLed code
explicit. In the case of modifications to original works, MPL and GPL are
essentially equivalent, and so are clearly compatible. MPL also allows
larger works to be covered under different licenses, as long as the
original work is available under the MPL. Those licenses don't have to be
proprietary; it can also be the GPL, for example. And so what you have,
in essence, are two codebases: one under the MPL, and one under the
GPL. Those two codebases may actually be completely in sync, but can
always be taken in different directions.
-- +=== Eugene Eric Kim ===== firstname.lastname@example.org ===== http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they | +===== can have an excuse to drink alcohol." --Steve Martin ===========+
Need technology solutions for your business? Respond.com can help. Just tell us your IT needs. We'll bring the right providers to you http://click.egroups.com/1/6324/5/_/444287/_/964425807/ ------------------------------------------------------------------------
Community email addresses: Post message: unrev-II@onelist.com Subscribe: unrev-IIemail@example.com Unsubscribe: unrev-IIfirstname.lastname@example.org List owner: unrev-IIemail@example.com
Shortcut URL to this page: http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Jul 24 2000 - 01:12:11 PDT