Copyright c
The Vesta Approach to
Software Con?guration Management Allan Heydon,Roy Levin,Timothy Mann,and Yuan Yu Copyright c Compaq Computer Corporation1999.All rights reserved
Abstract
Vesta is a system for software con?guration management. It stores collections of source?les,keeps track of which versions of which?les go together,and automates the pro-cess of building a complete software artifact from its com-ponent pieces.Vesta’s novel approach gives it three im-portant properties not available in other systems.First, every build is repeatable,because its component sources and build tools are stored immutably and immortally,and its con?guration description completely describes what components and tools are used and how they are put to-gether.Second,every build is incremental,because re-sults of previous builds are cached and reused.Third,ev-ery build is consistent,because all build dependencies are automatically captured and recorded,so that a cached re-sult from a previous build is reused only when doing so is certain to be correct.In addition,Vesta’s?exible language for writing con?guration descriptions makes it easy to de-scribe large software con?gurations in a modular fashion and to create variant con?gurations by customizing build parameters.This paper describes Vesta’s advantages over traditional tools,how those bene?ts are achieved,and the system’s overall performance.
1Introduction
This paper describes Vesta,a software con?guration man-agement(SCM)system for managing and building soft-ware,from small systems to very large ones(tens of mil-lions of lines of source code).Vesta addresses the follow-ing four core SCM problems:
Version management.Version management is the pro-cess of assigning names(typically sequential numbers)to a series of related source?les and supporting retrieval of those?les by name.Machine generated,or derived?les, are also versioned by some SCM systems.
Source control.Source control is the process of control-ling or regulating the production of new versions of source ?les.Operations commonly associated with source con-trol include checkout and checkin,which respectively re-serve a new version and supply the data for a previously reserved version.Source control may be coupled with concurrency control as well,so that checking out a par-ticular version limits the ability of other users to check out related versions.
System modeling.A system model is both a static de-scription of a system’s con?guration and a recipe for pro-ducing a software artifact.It names the(versions of) software components that are to be combined to produce larger components or entire systems,names the tools that are to be used to combine them,and speci?es how the tools are to be applied.System models are also sometimes called con?guration descriptions.
Building.Building is the process of evaluating a system model so as to construct a complete system according to the model’s instructions.Building may also include other activities,such as running regression tests on the resulting artifact.
Version management,source control,system modeling, and building are four parts of the larger SCM problem. Considered broadly,SCM is often taken to include such areas as process management,software life-cycle man-agement(e.g.,bug tracking,testing),and even the speci?c tools used to develop and evolve software components. We hold the view that these aspects of SCM,although im-portant to the overall software development process,are secondary to the core issues listed above.We have there-fore focused the Vesta project on solving those core prob-lems,constructing a solid base upon which we believe so-lutions to the other problems can be built.
Some form of SCM is almost always a necessary part of software development.SCM is useful whenever multi-ple source?les,multiple developers,or multiple releases and/or target platforms are involved.Moreover,the larger the number of source?les,developers,or releases,the larger the con?guration management problem.
A good SCM system can greatly reduce these prob-lems.Version management can ease the problem of man-aging multiple source?les by keeping related versions of ?les together.Source control can help multiple developers work productively in parallel.Together,system modeling and building can help manage multiple releases by accu-rately selecting the right sources to use for each release and by automatically managing derived?les. However,several dif?culties stand in the way of de-signing and implementing an SCM system that addresses these problems.First,handling large-scale software is dif-?cult,because it usually involves large numbers of source ?les and developers.Unlike other SCM systems in use to-day,Vesta was speci?cally designed to handle very large projects—millions of lines of code and beyond.The rapid growth of today’s software makes this an even more press-ing problem.Second,with larger numbers of develop-ers comes the need to support parallel development across sites that are often geographically separated,which intro-duces the problem of keeping replicated copies consistent. Finally,for building to be ef?cient,it must work incre-mentally,re-using the results of previous builds whenever possible.However,when multiple versions,multiple tar-get platforms,and multiple releases are involved,sound incremental building is a non-trivial problem.
The rest of the paper is organized as follows.We?rst consider the strengths and weaknesses of several widely-used SCM systems.Section3then describes the Vesta
approach,focusing on the main ideas in the Vesta system and the bene?ts they provide.In Section4,we then de-scribe how those ideas are realized in practice,with an emphasis on the user’s view of the system.Finally,we describe the performance of our Vesta prototype in Sec-tion5,and in Section6,we offer our conclusions from our experiences using the system.
2Previous Approaches
In this section,we review related work by assessing sev-eral popular SCM systems.Some systems,like the Re-vision Control System(RCS)and the Concurrent Ver-sion System(CVS)address only version management and source control,while others like Make address only sys-tem modeling and building.We also consider Clear-CASE,which provides a more integrated solution to the core SCM problems.
2.1RCS and CVS
RCS is a system for maintaining multiple versions of in-dividual?les[10,11].Its main strengths are that it is easy to use,well-understood,and well-documented.Its main disadvantages are two.First,it does not provide transpar-ent access to individual?le versions.That is,an explicit checkout step is required to access an older version of a ?le.Hence,to build an older version of a system,the developer must?rst explicitly check out the correct ver-sions of each source?le required by the build.Second, sources are versioned at the granularity of individual?les. Although RCS provides tagging facilities for grouping re-lated?les,those facilities are awkward to use.
Like RCS,CVS is relatively easy to use and well-supported[4].It also suffers RCS’s problem of not al-lowing transparent access to?le versions.However,un-like RCS,CVS allows related?les to be grouped to-gether into modules.CVS also includes an optimistic concurrency control methodology that allows multiple de-velopers to work on the same?le concurrently.How-ever,allowing concurrent modi?cations is not without its costs,since con?icting edits must be detected and re-solved.CVS’s con?ict detection is simple-minded(i.e., purely line based),so semantic con?icts between changes in disjoint lines may go undetected.When con?icts oc-cur,they must be resolved manually,which can be a time-consuming process.
2.2Make
Make is a widely-used tool for building software[2].It is easy to use and the syntax of its system models(i.e., Make?les)is simple,if somewhat cryptic.Moreover,Make can also be used for tasks other than building soft-ware,such as running regression tests.
However,there are several major problems with the Make approach to software construction.In this approach, dependencies between derived?les and the inputs used to produce them must be speci?ed explicitly by the user,and Make relies on timestamps to decide when it is safe to re-use a derived?le in a subsequent build.A build based on incorrect dependency information or incorrect timestamps can produce an inconsistent result,in which parts of the resulting system incorrectly include stale derived?les.In-consistent builds can produce programs that fail to link or run,or that exhibit bizarre,unexplainable bugs.Devel-opers often must resort to performing a scratch build to correct such problems.
Inconsistent builds are not uncommon in Make.Speci-fying dependencies explicitly is an inherently error-prone task.There are tools such as makedepend for generating certain kinds of dependencies automatically,but again, such tools must be run by hand,so they may not be run as often as necessary.Another problem is that some de-pendencies are inexpressible or too costly to express.For example,dependencies on the values of environment vari-ables cannot be expressed in Make,and dependencies on the Make?le itself are too costly because they would re-sult in a scratch build whenever the Make?le was changed. Make’s use of timestamps is also problematic[3].For ex-ample,when building a system from older sources,Make may incorrectly conclude that the system is up-to-date be-cause the timestamps associated with the older?le ver-sions are in the past;again,a scratch build is often the developer’s only recourse in such situations.
Finally,Make scales poorly.Make does its dependency analysis from the leaves of the“build tree”,working its way up to the?nal result.Hence,the cost of an incre-mental build in Make is proportional to the total num-ber of sources contributing to the build,not the number of sources that have changed.Moreover,although it is possible to structure a software system hierarchically by arranging for Make to invoke itself recursively on sub-components,doing so is awkward and performs poorly, so it is not frequently done in practice.
2.3ClearCASE
Perhaps the biggest problem with the systems discussed so far is that they are not integrated.Building a particular version of a system requires two steps:checking out the correct versions of the sources,and then building them. As described previously,the?rst build of an older ver-sion must be performed from scratch,since Make does not have any knowledge about which versions it is build-ing,so it cannot tell when it is safe to re-use a derived?le
from a different build.
ClearCASE is a commercial SCM system that inte-grates version management with building,and that ad-dresses many of Make’s shortcomings[1].It is based on many of the ideas in the earlier DOMAIN Software Engi-neering Environment(DSEE)system[8,7].
Unlike RCS and CVS,ClearCASE provides transpar-ent access to older?le versions.However,older versions are almost never accessed directly in practice.Instead,a ClearCASE view is used to transparently map an unver-sioned?le name to a versioned one.The rules governing a view can be speci?ed in a variety of ways,and they in-clude provisions for always accessing the latest version of a?le.
For building,ClearCASE provides its own version of Make called clearmake.The advantage to this approach is that developers do not have to learn a new system mod-eling language,and their existing Make?les continue to work.Unlike Make,clearmake does automatic(although somewhat incomplete)dependency detection by monitor-ing and recording the?les accessed during a build.It also manages derived?les for potential later re-use.
There are several problems with ClearCASE.The prob-lem with the view approach to version management is that the meaning of a name can change over time.In partic-ular,the actions taken by someone else can cause one’s own build to suddenly fail.This shortcoming is an im-pediment to effective parallel development.There are also problems with the clearmake builder.First,because clear-make is Make-based,it suffers from the same scalability problems as Make.Second,because its dependency de-tection is incomplete,clearmake can produce inconsistent builds.Third,clearmake’s mechanism for allowing de-velopers to re-use the derived?les produced by others—called winking in—is based on heuristics that can fail to capitalize on valid re-use opportunities.Finally,anec-dotal evidence suggests that the overheads introduced by clearmake are large,so some development organizations choose to use ordinary Make for improved performance, despite Make’s shortcomings.
3The Vesta Approach
As described earlier,Vesta’s goals are to address the core SCM problems of version management,source control, system modeling,and building.It provides a?rm tech-nical base on which solutions to the other SCM problems can be built.Vesta is also explicitly designed to scale up to large code bases,which means it must also effectively support parallel development.Of course,it must be an open system that works with standard development tools. Finally,it must perform well and be easy to use.
The Vesta approach is based on the following founda-tions:
?Immutable,immortal,and versioned storage of all sources and tools.Unlike ClearCASE,Vesta uses ex-plicit version numbers rather than views.?Complete,source-based con?guration descriptions.
By complete we mean that the descriptions name all elements contributing to a build,and no build de-pends on any aspect of the computing environment
(e.g.,tools,libraries,header?les,environment vari-
ables)outside of Vesta’s control1.By source-based we mean that con?guration descriptions describe how to build a system from scratch from sources
(i.e.,non-derived?les).Hence,the descriptions do
not rely on templates,search paths,or other rules for their meaning and function.
?Automatic dependency detection.All dependencies are detected and recorded automatically by the Vesta builder,so no dependency errors can be introduced by human error2.
?Automatic derived?le management.The storage and naming of derived?les is managed automatically by the Vesta storage repository,thereby easing the bur-den of building multiple releases or building for mul-tiple target platforms.
?Site-wide caching of all build work.Vesta features a shared site-wide cache of build results so developers can bene?t from each others’builds.
At this point,the reader may well be wondering what it is like to use Vesta in practice.How can any sources be edited if all sources are stored immutably?If system mod-els must name the version of every source?le,isn’t the overhead of maintaining those references overwhelming? We address these questions and other practical aspects of using Vesta in Section4below.
We?rst point out that these foundations provide several valuable bene?ts:
Repeatable builds.The immutability and immortality of sources combined with the completeness of build descrip-tions together mean that every Vesta build is repeatable. That is,any build performed in the past can be exactly reproduced at any time in the future.
Incremental builds.Although the system models de-scribe how to build a software system from scratch,the Vesta builder uses the site-wide cache of previous builds to avoid work,so good incremental build performance is the norm.The time required to perform an incremental build is generally proportional to the amount of work to be done,not to the size of the system being built. Consistent builds.Because every build is conceptually performed from scratch,and because Vesta’s automatic dependency detection means that a cached result is used only when it is correct to do so,all Vesta builds are guar-anteed to produce consistent results.Hence,there is never any need to do“nightly”or scratch builds to correct for an errant build in which a stale derived?le was used. Parallel development.Several features of the Vesta sys-tem enable parallel development.For one,the Vesta repository supports version branching and partial replica-tion across geographically distributed sites.But perhaps more important is the fact that a user must take explicit ac-tion to build with a newer version of someone else’s code. Hence,it is impossible for one developer’s action to break another’s build.This feature allows developers to work productively in isolation.
The entire Vesta system was designed and implemented with an eye toward scalability.Our design goal was to support systems containing20million lines of code or more.This emphasis is visible in several respects.To organize the construction of large-scale software,system models can be arranged as a modular hierarchy.Dur-ing a build,caching is done top-down rather than bottom up.Hence,cache hits often occur on larger units of work than individual tool invocations,such as the construction of an entire library or collection of libraries.This top-down caching avoids the scalability problem of incremen-tal builds suffered by Make.Finally,because each user’s checked out?les are managed by the repository,the repos-itory can arrange to make checkout and checkin almost instantaneous,thereby eliminating one of the burdens of working with large source trees.
4A User’s View of Vesta
The discussion so far has been fairly abstract.In this sec-tion,we provide a user’s view of Vesta to make the ideas more concrete.We start by describing Vesta’s compo-nents.We then consider Vesta’s source control tools and their effects on the repository.Finally,we present some sample system models to give a sense for Vesta’s system modeling language.4.1Vesta Components
Figure1shows the main components of the Vesta system. The bottom half of the?gure shows the repository and function cache servers.One instance of each server is run at each site.The repository server manages the storage of both sources and derived?les.It provides both a stan-dard NFS interface to sources,and a remote procedure call(RPC)interface that is used by other Vesta tools.The function cache server stores the results of previous builds. Both servers use a normal?le system for backing storage.
Client
Host
Figure1:Vesta’s main components.
The top half of Figure1shows the Vesta components run on each client host.The main client programs are the repository tools and the evaluator.The repository tools provide checkout,checkin,and other source con-trol operations.The evaluator is the Vesta builder.It reads user-written system models and a set of system-supplied models comprising the standard construction en-vironment.Not shown in the?gure are standard develop-ment tools such as text editors and the like,which can be used to access sources via the repository’s NFS interface in the usual way.
During a build,the evaluator will often be called on to run an external tool like a compiler or linker.To do so, the evaluator makes a remote procedure call to a runtool server process.As indicated by the dashed line in the?g-ure,the runtool server may or may not be running on the same client host as the evaluator.Decoupling the runtool server from the evaluator allows tools to be invoked on different machine platforms(e.g,for cross development), or even for multiple clients to use the same runtool server running on a more powerful machine.
Before it contacts the runtool server to launch a tool, the evaluator calls the repository to create a special direc-
tory tree in which the tool will be run.The runtool server then launches the tool in an encapsulated environment that causes all of the tool’s?le references to go to this tree, where they are trapped and reported back to the evaluator. The evaluator records these references as dependencies. During the build,the evaluator also contacts the func-tion cache server to determine if each piece of the build it is about to execute has been performed before(either by the same person or someone else).If so(a cache hit),the function cache returns the correct result.If not(a cache miss),the evaluator performs the work and then calls the cache to create a new cache entry for possible re-use in the future.
Figure1omits several administrative tools.Among these is a tool called the weeder that is used to delete unwanted derived?les from the repository and unwanted cache entries from the function cache.The weeder reads a description?le that says which build versions should be kept;it then uses a mark-and-sweep garbage collection al-gorithm to identify all derived?les and cache entries that are safe to delete.The description?le uses a simple but powerful pattern language;such rules as“keep builds of the last two versions”are easily expressed. Parameterizing the weeder with an explicit instruction ?le gives each organization the?exibility to keep the builds it considers important.Of course,deciding what to weed is simply a time-space tradeoff.Even if a use-ful build is accidentally left out of the weeder instructions and deleted,Vesta’s repeatability guarantees that it can be reproduced,albeit more slowly,and re-cached.
4.2Repository Operations
The Vesta repository is a general-purpose?le system with special support for immutability.As mentioned earlier,it exports both an NFS interface(with some minor restric-tions)and an RPC interface.The repository also manages a site-wide pool of derived?les.
The repository’s main job is to provide directory trees; the?les themselves are stored in a normal Unix?le sys-tem.In particular,the repository supports three kinds of directories:mutable,immutable,and appendable.The purposes of these three directory types will become ap-parent momentarily.
It is worth noting that the repository naming conven-tions we describe next are imposed not by the reposi-tory server,but by the much smaller client-side repository tools.This separation of concerns is important because it means that different source control paradigms(such as a more concurrent paradigm like that of CVS)could be implemented simply by rewriting the repository tools; changes to the repository proper would not be required. Figure2illustrates several aspects of the naming con-
Figure2:Naming conventions assumed by the Vesta repository tools.
ventions engendered by our current repository tools:?Related sources are grouped into arbitrary directory trees called packages.Versioning is done at the pack-age granularity.As shown in version3of the com-mon/thread package,each package version may contain arbitrary?les and nested directories.
?To accommodate large-scale software,the package namespace is hierarchical.For example,the pack-ages of Figure2are arranged in a two-level hier-archy,with package names like common/thread and vesta/repos.
?Version numbers appear as explicit pathname arcs.
For example,version3of the common/thread package is named common/thread/3.
?The root directory of each package version is im-mutable.Hence,the contents of a package ver-sion cannot be changed.The directories that form the package hierarchy,such as common and com-mon/thread,are appendable.The only operation allowed on such directories is the insertion of new items,such as new packages or package versions.?Branches are like sub-packages.Hence,all the op-erations on packages apply to branches as well.In Figure2,the branch common/thread/2.fast has three versions named0,1,and2,the for-mer of which will typically be a copy of com-mon/thread/2.
As shown in Figure3,the repository exports two NFS?le systems,which are made visible to the client through two mount points,typically named/vesta and /vesta-work.The directory tree rooted at/vesta consists only of appendable and immutable directories,
Figure3:The checkout session of the common/thread package.
while the one rooted at/vesta-work is mutable.There is a mutable directory in/vesta-work for each user, and edits are performed in subtrees of those directories. In addition to version directories and branch direc-tories,each package also contains a directory named checkout.This directory contains an appendable di-rectory for each checkout session,each of which contains a separate,immutable snapshot of a package version each time the package is built.Hence,Vesta keeps a version of each package not only across checkout sessions,but dur-ing checkout sessions as well.
The typical development cycle is as follows.?Check out the package using vcheckout ?Modify the package:
–Edit using your favorite text editor
–Advance the package using vadvance
–Build the package using vesta
–Test
–Repeat as necessary
?Check in the package using vcheckin
The outer level consists of three steps:check out the package using vcheckout,modify it,and check it back in using vcheckin.The inner loop of the development cycle is the familiar edit-compile-test loop,but with an extra wrinkle.Recall that Vesta’s repeatability guarantee requires that all builds are performed against immutable sources.Therefore,before invoking the vesta builder,an immutable copy of the user’s current sources must?rst be made using a tool called vadvance3.We now describe these tools and their effect on the repository.
priate part of the package’s checkout directory.Builds are then performed using these immutable sources. Finally,once the user is satis?ed with the state of the package,vcheckin is used to check the package back into the main line of the package version space.As shown in Figure6,vcheckin replaces the previously created ver-sion stub by the latest sub-version of the checkout ses-sion,and deletes the user’s working version of the pack-age from/vesta-work.
4.3System Modeling Language
We now consider typical client system descriptions.A complete discussion of Vesta’s system modeling language is well beyond the scope of this paper,but its complete syntax and semantics are de?ned in a separate paper[5]. Here,we will try to motivate and describe the language’s main features.
Across different development organizations,there is a rather wide variation in build processes,including the size and scope of the systems being built,the structure and methodology of the organization,and the degree of pa-rameterization required.Vesta therefore supports varied descriptions through a general-purpose language that sup-ports abstraction.Abstraction permits the construction of extensions that adapt the language to each organization’s development methodology.As a proof of concept,we have built one fairly comprehensive extension called the standard construction environment.
The system modeling language itself is a full-?edged functional programming language with a C-like syntax. The functional nature of the language is important,since each function call represents a unit of work appropriate for caching.The language uses strong,dynamic typing, which is to say that the run-time types of arguments to all built-in operations are checked for correctness.The language is methodology neutral.The main aspect of the files
h=[date.h];
c=[date.c,calendar.c];
{
libs=<./C/libc>;
return./C/program("cal",h,c,libs);
}
Figure7:A build.ves system model for building a sample application.
language that is specialized for software construction is a primitive to run external tools like compilers and linkers in an encapsulated environment(i.e.,to invoke the runtool server of Figure1).The language also includes an im-port statement that encourages modular build descrip-tions and thereby supports hierarchical system modeling. Figure7shows a sample model for building an appli-cation.By convention,the model responsible for building all the components of a package is named build.ves. The files clause binds the program variables h and c to the listed?les in the package.The body of the model then binds the variable libs to a singleton list containing the standard C library,and returns the result of invoking the program function supplied by the standard environ-ment.It is the program function that is responsible for compiling the necessary sources and linking the program. Before a model like the one shown in Figure7can be invoked,the environment in which the build is performed must be created and bound to the special variable named “.”(dot).The variable“.”is special because it is passed as an implicit argument on all function calls.Hence,assign-ments or changes to“.”are visible in all descendant func-tions of the function call graph.This feature of Vesta’s function call semantics makes it easy to de?ne customiza-tions that affect all relevant parts of a build.
The build environment embodies not only the complete set of functions,tools,libraries,and header?les needed by the build,but also any requested build customizations. Such customizations are typically injected“from the out-side”;that is,a developer considers them as parameters of a particular build rather than inherent details of the system being built.It is thus appropriate to include them in the top-level(outermost)system model.Indeed,such models do little more than list parameter values and invoke the build procedure for a package or collection of packages. Such a model can therefore be readily constructed from a graphical“control panel”program in which the user spec-i?es desired customizations.The control panel then writes a(highly stylized)control panel model4.By convention, control panel models are named.main.ves.
from/vesta/https://www.wendangku.net/doc/2f14320688.html,/common import std_env=std_env/23/build.ves;
import
calendar=build.ves;
{
.=std_env()/env_build("DU4.0");
//build customizations would go here...
return calendar();
}
Figure8:A.main.ves control panel model for estab-lishing the build environment.
from/vesta/https://www.wendangku.net/doc/2f14320688.html,/millicent import wallet=wallet/12/build.ves;
vendor=vendor/20/build.ves;
broker=broker/7/build.ves;
{
return wallet()++vendor()++broker(); }
Figure9:An umbrella system model for building a col-lection of components and combining their results.
Figure8shows an example.The model begins with two imports.One import is of the non-local model com-mon/std
env),and the other is of the local model build.ves(bound to the variable calendar).The model body consists of two statements.The?rst in-vokes the env env model,and binds the result to the special variable“.”.The second statement then invokes and returns the result of the package’s own build.ves model shown in Figure7. This example shows that a model can be called like a func-tion using the standard function call syntax.
The two examples shown so far also illustrate an im-portant point about the appearance of version numbers in system models.Because sources are versioned at the granularity of packages,and because related sources re-side in the same package,version numbers need be sup-plied only for cross-package imports.For example,in Figure7,no version numbers are required because the ref-erenced sources reside in the same package as the model from which they are referenced.The local import in Fig-ure8requires no version speci?cation for similar reasons. However,an explicit version number is required for the non-local import of the std
Test
Hello
53,30410311711 Release
Vesta Make
3.3s 3.4s
Evaluator
912s960s
Table2:The elapsed time in seconds required by Vesta and Make to build the three test cases of Table1from scratch.
NFS server in the case of Make)were run on a233MHz AlphaStation4004/233server machine.In both cases, the server processes used the same AdvFS?le system residing on a local disk,and the client and server ma-chines communicated via a high-speed ATM network called AN2.All machines were running version4.0D of Compaq’s Tru64Unix operating system.
We measured builds of software systems of varying sizes.The characteristics of these systems are shown in Table1.The columns of this table indicate the total num-ber of lines of source code,the number of C/C++source ?les to be compiled,the number of tool invocations neces-sary,and the number of packages across which the sources reside.
The Hello test is a simple“hello world”program con-sisting of a single10-line source?le.It requires two tool invocations:one to compile the?le,and one to link it. This test is included mainly for purposes of providing a baseline measurement.The Evaluator test consists of building all of the Vesta libraries and the Vesta evaluator application.The sources for this test are contained in10 library packages and the evaluator package itself.Finally, the Release test consists of building the entire Vesta re-lease.In addition to building the evaluator,this includes building all the Vesta tools,servers,and documentation. Table2shows the elapsed time(in seconds)required by Vesta and Make to perform each of the three test builds from scratch.These data show that scratch Vesta builds are somewhat faster than Make builds,but not appreciably so,since most of the time is spent compiling and linking. To measure the time required to perform incremental builds,we modi?ed one of the source?les in each build test and rebuilt.In the case of the Release test,we modi-?ed the same evaluator source?le as in the Evaluator test. Table3shows the elapsed time(in seconds)to perform each incremental build.For Make builds,we report two Test
Hello
12.5s15.1s23.3s Release
modular build descriptions that can be highly parame-terized.The main challenge was designing a general-purpose language amenable to ef?cient execution that supported a variety of methodologies and build cus-tomizations.
Overall,Vesta handles the core SCM problems of ver-sion control and building quite well.It provides repeat-able,incremental,and consistent builds.It also sup-ports parallel development through several features,such as branching,explicit versioning,and partial replication. Vesta’s system modeling language is general enough to support different development organizations,and it en-courages modular software descriptions.On small-to medium-sized scratch and incremental builds,Vesta per-forms better than Make,and provides much stronger con-sistency guarantees.Finally,we have found the system easy to use;once we switched over from building the sys-tem with Make to building it with Vesta,we never wanted to go back.The advantages provided by being able to ex-actly name and reproduce any past build are dif?cult to fully appreciate until they are available.
However,despite these successes,there are still some open questions.The?rst relates to scalability.Although Vesta was designed to scale to very large software,we have used it to build only medium-sized systems.An ear-lier Vesta prototype saw use by25programmers develop-ing a1.4million line code base for over a year[9].We designed the current system to overcome the scaling bot-tlenecks we observed at that time,but we have not yet used the current system to build anything much larger than itself.There is evidence that the system scales to a larger number of users:the Vesta prototype is currently in daily use by about60people in a Compaq engineering group. The code base they are developing is expected to exceed 700thousand lines of code by the time it is complete. Another question relates to ease of use.Our experi-ences have been positive,but as the developers of the sys-tem,we are obviously biased.The engineering group that is using Vesta has been able to adapt it to their application and development environment by writing a small number of“wrapper scripts”and a domain-speci?c control panel application.Overall,they have found Vesta to be a signif-icant improvement over their previous version and build management tools.
Finally,for Vesta to be adopted by any organization, some technical and non-technical hurdles must be https://www.wendangku.net/doc/2f14320688.html,ers of other SCM systems need to convert their code bases and descriptions to Vesta,which may require specialized tools that understand their existing develop-ment methodology.Perhaps a more substantial problem is the need to overcome the psychological barrier created by Vesta’s radically different approach to SCM.New users thus require training,not just in a different set of tools,but in a different way of thinking about the software de-velopment process.
References
[1]Atria Software,Inc.,24Prime Park Way,Natick,MA
01760.ClearCase Concepts Manual,1992.
[2]S.I.Feldman.Make—A program for maintaining com-
puter programs.Software—Practice and Experience, 9(4):255–265,April1979.
[3]Glenn Fowler.A case for make.Software—Practice and
Experience,20(S1):S1/35–S1/46,June1990.
[4]Dick Grune,Brian Berliner,and Jeff Polk.cvs(1)manual
page.Free Software Foundation.
[5]Allan Heydon,Jim Horning,Roy Levin,Timothy Mann,
and Yuan Yu.The Vesta-2software description language.
SRC Technical Note1997–005c,Digital Equipment Corporation,Systems Research Center,June1998.
https://www.wendangku.net/doc/2f14320688.html,/pub/DEC/SRC/technical–
notes/abstracts/src–tn–1997–005c.html.
[6]Allan Heydon,Roy Levin,Timothy Mann,and Yuan Yu.
The vesta software con?guration management system.In preparation.
[7]David B.Leblang and Robert P.Chase,https://www.wendangku.net/doc/2f14320688.html,puter-aided
software engineering in a distributed workstation environ-ment.SIGPLAN Notices,19(5):104–112,May1984. [8]David B.Leblang,Robert P.Chase,Jr.,and Gordon D.
McLean,Jr.The DOMAIN software engineering envi-ronment for large-scale software development efforts.In Proceedings of the1st International Conference on Com-puter Workstations,pages266–280,San Jose,CA,Novem-ber1985.IEEE Computer Society,IEEE Computer Soci-ety Press.ISBN0-8186-0649-5,IEEE Catalog Number 85CH2228-5.
[9]Roy Levin and Paul R.McJones.The Vesta ap-
proach to precise con?guration of large software sys-tems.SRC Research Report105,Digital Equip-ment Corporation,Systems Research Center,June 1993.https://www.wendangku.net/doc/2f14320688.html,/pub/DEC/SRC/research–reports/abstracts/src–rr–105.html.
[10]W.Tichy.Design,implementation,and evaluation of a
revision control system.In Proceedings of the6th Interna-tional Conference on Software Engineering,pages58–67.
IEEE Computer Society Press,1982.
[11]W.Tichy.RCS—A system for version control.Software
—Practice and Experience,15(7):637–654,July1985.
2007山东农业大学动物形态学试题
1.骨的构造包括、、、，关节的基本结构包括、、和。 3.输卵管由、和组成，卵子的受精部位 在。 4. 咽有7个口和邻近的器官相通，其中前上方为2个，前下方，后上方通过1个通食管，后下方通过与气管相通，两侧通过两个耳咽管口通中耳。 5. 喉软骨有4种5块，包括不成对的、、和成对的，喉腔内有，是喉的发音器官。 6. 管状器官的管壁由内向外有四层，分别是、、、。 8.皮肤有三层，由内向外分别为、和。其中日用皮革由鞣制而成，、和合称为皮肤腺。 1.骨的类型包括、、和。 2. 一块肌肉就是一个肌器官，包括和两部分；颈静脉沟为和之间的肌沟；肉品学上、、、合称后座。 4. 管状器官的管壁由内向外有四层，分别是、、、。 5.脑干分为四部分，由后向前分别是、、和，在的网状结构内有和呼吸中枢两个基本的生命中枢。 6．大脑半球内的白质有三种，分别是、和。小脑半球是从才发展起来的，参与调节精细的随意运动。 7.分布于前肢的神经来自于丛，其中最长的为，分布于后肢的神经来自于丛，最大的为。 8.皮肤有三层，由内向外分别为、和。其中日用皮革由鞣制而成，、和合称为皮肤腺。
1．腹股沟管 2 植物性神经3．胰岛4．睾丸下降5．冠状血管6 内分泌腺7.胸膜腔8心脏的传导系统9 脑脊髓液10. 硬膜外腔 1.胎儿的心血管的结构特征。 2.简述12对脑神经的名称及发出部位。 3.用简表表示眼球结构。 4.脊髓的结构特征及主要功能。 6. 简述12对脑神经的名称及发出部位 7.躯体神经与植物性神经在分布、发出部位、结构及与意识的关系上有何不 同 8.详述心脏内防止血液倒流的结构与机制 9.植物性神经的组成。 10. 各脑室的联通情况及意义。 11.禽输卵管的结构及功能。
2010年美国值得关注的5大知识产权案
2010年美国值得关注的5大知识产权案 2010年对于美国知识产权法律来说是重要的一年。法院正在审理的5起案件，将有可能造成美国的专利和商标法的重大变化，其涉及到数千亿美元，并且有可能引起互联网新用途革命。 一、Bilski诉Kappos案 在Bilski诉Kappos案中，美国最高法院正考察可授予专利主题的范围，该案的结果有可能成为里程碑似的裁决。 根据法官在口头辩论阶段的问题，很多专家相信法院将会判决Bernard Bilski的发明——在商品交易中使用保值合同以限制价格波动的方法——不具有可专利性。虽然还不清楚法院会在何种程度上判决。 法院有可能狭隘的认定Bilski的发明只是一个抽象的想法，因此在长久以来制定的法律标准下是不具备可专利性的。或者法院可以解释的更为宽泛，审查发明是否需要满足“machine or transformation test”（机器-或-转变）的检验。这一判断方法近期被联邦巡回上诉法院（通常称为专利法院）在Bilski案中所重新引用。根据此检验，过程或方法如果能获得专利则它或能捆绑于特定的设备或器械，或能将某一特定的对象转换为另一不同的状态或东西。 如果最高法院支持“机器-或-转变”检验，对于这一检验的解释将改变专利法。依据过程或者方法“捆绑于特定的设备或器械”的严格程度，则会有一大部分的发明被认定为不可专利。很多现存的商业方法专利、医学诊断专利、法律方法专利，甚至软件专利都将被推翻。 一位芝加哥的专利诉讼律师Jeffrey H. Dean说：“大家都急切等待着最高法院对Bilski案的判决，因为它将影响到很多专利，包括国内很大数量的专利。” 二、Ariad Pharmaceuticals公司诉礼来公司（Eli Lilly）案 Ariad Pharmaceuticals公司诉礼来公司（Eli Lilly）案中的问题看上去相当的复杂。为获得专利，是否必须由发明家提供一份令人满意的有关其发明的“书面描述”？一些专家认为，如果联邦巡回法院对此做肯定回答，这将极大的伤害那些有重要新发现的发明家。 美国专利法第112节规定，为了获得专利，申请者必须披露如何制作和使用这一发明。但是法院还未将这一规定解释为需强加一项单独的“书面描述”。 一些专家认为，提供“书面描述”这一新的非固定的标准会使很多发明家无法完全达到此要求。尤其是那些创造突破性发明的大学、刚成立的公司和小发明家都将处于困境中。这些主体缺乏资金搜索和描述发明潜在的用途，因此，要求他们符合独立的“书面描述”标准将缩小他们本应获得的专利保护。 相反，很多大公司——尤其是大型制药公司——会从这一条款中获益。这将使他们能自由地开发他人重要发明中的很多部分。 2009年4月，美国联邦巡回法院3人审判组认定需出具一份单独的书面描述。这一问题在2009年12月提交给全席审判庭前被重新讨论。很多观察家希望法院在现任首席法官Paul R. Michel5月底退休前对这一案件作出裁决。 三、Costco Wholesale公司诉欧米茄公司（Omega SA）案
美国版权战略对我国文化产业发展的启示
2009年2月重庆工商大学学报(社会科学版)第26卷第1期Feb.2009Journal of Chongqing Technol ogy and Business University(Social Sciences Editi on)Vol126 NO.1 美国版权战略对我国文化产业发展的启示3 韩 洁,谭予涵,谭 霞,王 芳,王 敏 (重庆工商大学法学院,重庆400067) [摘要]美国实施版权战略促进了版权产业的快速发展,为美国经济发展作出了巨大贡献,我国应借鉴美国实施版权战略的成功经验,在文化产业立法、文化产业的科技投入和创新、文化产业的产业化以及国家在政策上的扶持都有待于进一步加强。 [关键词]版权战略;文化产业;美国 [中图分类号]D971.23 [文献标识码]A [文章编号]1672-0598(2009)01-0104-05 一、美国版权产业发展现状 1.美国的版权产业 在美国,人们主要采用“版权产业”来表述商业的和法律的意义上的文化产业。广义的版权产业,是指与创作、传播、复制和发行文学、艺术和科学作品的行业和收集、储存与提供信息的信息行业,主要包括图书、报刊、音像、电子出版业,广播、电影、电视业、音乐、戏剧、舞蹈等艺术表演与其他娱乐业,工艺美术、建筑艺术、园艺设计业,电脑程序设计与软件开发业,信息网络传播业、广告业等等。简单地说,版权产业就是使用智力作品并依靠版权保护进行经营和持续发展的产业。版权产业是知识经济的重要支柱和重要组成部分,是现代出版产业持续发展的动力和源泉。版权作为一种独立的产业,美国在1977年就确立了。为了加强版权保护制度的建设,美国在1976年修订了历经半个多世纪的版权法。自此,美国经济结构发生了战略性的转变,由过去以农业、重工业为主转变为优先发展信息业和服务业为主的产业结构。 版权产业是当今知识经济时代最重要的产业之一,是文化产业的核心和基础因素,其发展水平被国际社会认为是衡量一个国家或地区创新能力和核心竞争力的基本标尺。依照国际知识产权联盟的标准,版权产业可分为四类。第一、“核心版权产业”,主要包括广播影视业、录音录像业、图书、报刊出版业、戏剧创作业、广告业、计算机软件和数据处理业等,其基本特征是研制、生产和传播享有版权的作品或受版权保护的产品。第二、“部分产权产业”,产业内的部分物品享有版权保护,较典型的如纺织、玩具制造和建筑业等。第三、“发行类版权产业”,主要是以批发和零售方式向消费者传输和发行有版权的作品,如书店、音像制品连锁店、图书馆、电影院线和相关的运输服务业等。第四、“版权关联产业”,其所生产和发行的产品完全或主要与版权物品配合使用,如计算机、收音机、电视机、录像机、游戏机和音响设备等产业。[1] 2.美国版权产业在经济发展中的地位 版权产业与美国的经济发展、外汇收入、文化扩张息息相关。版权产业对美国经济做出了重大贡献。在美国,版权产业尤其是“核心版权产业”,已成为国民经济的支柱产业和美国经济增长的主要动因,是美国“知识经济”的驱动力。根据国际知识产权联盟发表的《美国经济中的版权产业:2002年度报告》,版权产业对美经济的作出了重大贡献。 (1)美国版权产业带动经济增长 根据有关的报告显示,自1977至2001的24年里,美国G DP中版权产业一直保持稳定增长势头,其中“核心版权产业”的年增长率平均为7101%,超过同期其他非版权类经济部门增长率(310%)和美国经济总增长率(312%)的两倍多。24年中,其产值已从1977年的434亿美元上升到 4013[收稿日期]2008-10-28 [基金项目]重庆工商大学学生科技创新基金项目《中国文化产业发展与版权战略研究———美国实施版权战略对我国的启示》阶段性成果,指导教师华鹰教授。 [作者简介]韩洁(1985-),女,河北唐山市人,重庆工商大学法学院,研究方向:民商法。
上海市版权局关于印发《上海版权示范单位和示范园区(基地)认定办
上海市版权局关于印发《上海版权示范单位和示范园区(基地) 认定办法》的通知 【法规类别】出版与出版物市场管理 【发文字号】沪版权[2014]33号 【发布部门】上海市版权局 【发布日期】2014.09.09 【实施日期】2014.09.09 【时效性】现行有效 【效力级别】地方规范性文件 上海市版权局关于印发《上海版权示范单位和示范园区（基地）认定办法》的通知 （沪版权〔2014〕33号） 各区（县）知识产权联席会议办公室、各版权服务工作站、各产业园区（基地）、各 有关单位： 为贯彻落实《上海知识产权战略纲要》和《上海版权工作“十二五”发展规则》，进 一步提升上海版权创造、运用、保护和管理水平，规范版权示范单位和园区（基地）评 定工作，推动版权工作更好地服务于上海经济、文化建设，上海市版权局制定了《上海 版权示范单位和示范园区（基地）认定办法》。现予以印发，请遵照执行。 附件：上海版权示范单位和示范园区（基地）认定办法 上海市版权局
2014年9月9日上海版权示范单位和示范园区（基地）认定办法 第一条为贯彻落实《上海知识产权战略纲要》和《上海版权工作“十二五”发展规划》，进一步提升上海版权创造、运用、保护和管理水平，规范版权示范单位和园区（基地）评定工作，推动版权工作更好地服务于地方经济、文化建设，特制订本办法。 第二条上海版权示范单位，是指在版权作品的创作、推广运用和保护方面产生重大影响或做出突出贡献，并在上海具有示范效应的企事业单位。 上海版权示范园区（基地），是指在集聚版权要素，在版权保护与推动产业发展等方面产生重大影响或做出突出贡献，并在上海具有示范效应的园区（基地）。 第三条
网络文学全版权运营的现状、问题与展望(1)
网络文学全版权运营的现状、问题与展望 黄子祺201111082025 随着文化产业地位的日益增长和市值的不断扩大，越来越多的文化企业、互联网企业开始打通上下游、延长产业链，动漫、游戏、图书、影视等不同领域日趋融合、互为内容，围绕版权多次开发所形成的生态圈已经成为文化产业新的增长点。在这一过程中，优质的内容资源作为产业链的源头起着至关重要的作用，网络文学正是其中之一。几年以来的文化娱乐业热点即是明证，热播剧《步步惊心》、《甄嬛传》等；热销图书《盗墓笔记》、《泡沫之夏》等；热门手游《盘龙》、《唐门世界》等均改编自网络文学。围绕网络文学的产业链开发已经成为学界和商圈越来越重视的概念，然而，随着实践的不断深入越来越多的问题也暴露出来。网络文学全版权运营意义何在？又该如何进行？ 一、网络文学全版权运营的概念与背景 网络文学全版权运营是盛大文学有限公司前任CEO侯小强提出的概念，其核心是版权内容的生产与分销。按照《著作权法》规定，著作权人可享有发表权、署名权、修改权、保护作品完整权、复制权、发行权、出租权、展览权、表演权、放映权、广播权、信息网络传播权、摄制权、改编权、翻译权、汇编权以及应当由著作权人享有的其他权利等17种权利。丰富的权利内容为多元化的产品开发奠定了法律基础，文学网站通过签约、代理、成立工作室等途径将版权经营的形式从线上发表延伸到了实体书出版、动漫动画、影视改编、游戏制作、衍生品授权、展览等等，形成了一次生产多次售卖的立体格局，引起涵盖领域极广、涉及著作权人权利极多而被称为全版权运营。 全版权运营是网络文学产业进一步发展的需要。经过二十余年的发展，网络文学产业一派繁荣：用户数2.74亿，年增长率17.4%，网民使用率44.4%1，仅盛大文学一家公司旗下的网站就拥有160万作家、600余万部作品、210亿字库存2。然而，对于一项近半数网民都在使用的应用而言，46.3亿元的市值显得太少了3，过低的利润率已经成为作为产业的网络文学进一步发展的绊脚石。低利润原因有二。一方面，网络小说付费阅读属于微支付，利润空间小。目前各文学网站主要采用的计费方式约每千字3-5分钱，以起点当红小说《全职高手》为例，购买全本普通会员约付人民币200元，然而对于535万字数和三年多的连载时间而言是名副其实的微支付，与实体书出版成本利润比不可同日而语。另一方面，猖獗的盗版进一步压榨了付费阅读的利润。数字时代的盗版本来就存在着速度快、规模大、代价低先天优势，且事前防范难、诉讼取证难，而作为读者的网民尚未形成尊重版权、付费阅读的习惯。盗版问题是互联网时代内容生产面临的通病，只有延长价值链才能将损失降到最低。此外，网络文学的特殊性使得规模经济的优势并不显著，横向扩张模式已不适应行业发展的新态势。规模经济是指从事单一产品的生产或经销的企业因规模的扩大而降低了生产或销售成本而导致的经济。而在网络文学业，一方面，由分工协作形成的规模优势大大减小。到目前为止绝大多数的网络文学仍是个体劳动的产物，这意味着一家公司旗下的 1第33次中国互联网络发展状况统计报告[R] 中国互联网络信息中心，2014 2盛大文学官网https://www.wendangku.net/doc/2f14320688.html,/ [EB/OL] 3姜莹. 网络文学市场规模达46.3亿过度逐利成发展绊脚石[N] 通信信息报，2014-02-28
出版社的版权输出状况及途径
出版社的版权输出状况及途径 随着世界范围的文化交流日益扩大,版权贸易活动也日趋活跃,得到了越来越多的出版社包括大学出版社的重视,但是,在我国现有的出版体制和管理体制下,我国出版社的版权贸易情况喜忧参半。 一、何为版权贸易 版权贸易是属于许可证贸易范畴内的一种基于版权的经济权利的许可或转让过程中发生的贸易行为。究其本质,也是贸易行为的一种,所以单列于其他贸易行为,不外是因为其贸易的标的对象不同而已。简单地说,凡是通过作品的版权许可或转让行为获利的贸易行为就是版权贸易。实物贸易是通过货物买卖行为获利的交易,在版权贸易这里不过是将实物所有权变为无形财产权中的版权而已。一般说来,版权贸易过程中许可或转让的主要是著作权人(“著作权”完全等同于“版权”,下略)的经济权利。从广义上讲,版权许可或转让行为过程中的当事人无论是否在同一地域或为同一国籍,都可以称作版权贸易。但在实践中,我国业界所称的版权贸易习惯上是狭义的概念,主要指国际间或不同地区间的涉外版权贸易行为,通常指著作权人与使用者不在同一国家或地区的情况。即,国内的作者与国内的出版社间的版权交易行为不在此之列。中国版权贸易发轫于19世纪末期。据报载,1898年,辜鸿铭翻译的《论语》英文本由上海别发洋行出版。这是一本专为“受
过教育的有头脑的英国人”翻译的书[1]。《论语》记录了孔子及其弟子的言行,是儒家思想的集中体现,也是中华民族文化之精华。辜鸿铭将其译出英文本,是否获得译文稿酬以及如何获得我们不得而知,但有一点毋庸置疑,他以中华民族拥有《论语》而自豪,所以他要介绍给西方,并且首选对象是“受过教育的有头脑的英国人”,这种向世界传播民族优秀文化的壮举,可敬可嘉!另据报载,中国著作权人授权外国翻译出版的第一部作品,仍属于辜鸿铭名下。1924年,欧根?狄特利希斯(EugenDiederichs)出版社出版了施密茨(Schmitz)翻译的德文版《中国人的精神》。该书的翻译出版得到了辜鸿铭的同意[2]。从《论语》英文本的问世,到《中国人的精神》授权翻译出版,时隔26年,足以看出辜鸿铭在北大执教的同时,将图书翻译、版权贸易当作一项事业来做。在中国近现代史上,从事过版权贸易的除了辜鸿铭之外,还有严复、林语堂、张元济等人,他们致力于思想文化传播,可谓中国版权贸易的先驱者。然而,中国版权贸易得以突飞猛进,驶入发展的快车道却是在一个世纪以后。1992年10月15日和10月30日,中国分别成为“伯尔尼公约”和“世界版权公约”的成员国,两个公约在中国先后生效。从此,我国的版权贸易进入了一个新的发展阶段(具体数据如表1所示)。我们可以骄傲地说,改革开放的深入发展,为中国的版权贸易开辟了广阔的新天地,尤其是加入WTO之后,出版人、版权代理人锐意进取,贸易步伐在加快加大,贸易成果丰硕喜人。但是,我们也必须看到,我国图书版权引进与输出的比例一直处于10︰1的水平线上波动徘徊,引进与输出的比例严重失调。
美术作品如何进行版权登记
版权又称著作权，保护著作权最佳最经济的选择就是版权登记，美术作品作为版权保护对象之一，想要获得法律的保护也需要进行版权登记。通常美术作品包括书法绘画作品、LOGO商标图案、纺织花样设计、卡通动漫设计、产品外包装设计等。 随着互联网的发展，网站、微博、微信等新媒体成为人们表达和获取信息的主要途径，而这些都离不开美术作品。不论线上还是线下，美术作品都是不可或缺的，美术作品的价值日益凸显，美术作品版权的保护成为必然。而美术作品被大量使用，著作权人却收不到相应的回报。这一现象背后所代表的是人们对于美术作品版权的意识淡薄以及美术版权作品侵权的严重。 美术作品与视频、音乐等版权的保护相比，人们的版权意识也相对薄弱。一方面有些美术作品作者的版权意识淡薄，意识不到自己的权利受到侵犯，另一方面使用者从网络中选取来源不明的美术作品，擅自修改使用，甚至用于商业活动中。互联网平台的传播范围广，往往会造成著作者被侵权也浑然不知的情况。当权利人完成某一美术作品时，不仅要注意保留作品的设计原稿、委托设计合同及其他公开发表的证据材料，还应及时进行著作权登记，以减轻后续著作权纠纷中的举证难度。著作权可以使你在别人对你的作品进行侵权时，采取有利的保护措施，制止别人的侵权行为。 (一)申请美术作品登记人 1、作者，创作作品的自然人、法人或者其他组织 2、其他著作权人，包括通过转让、承受、继承等继受取得著作权的权利人。
(二)美术作品版权申请材料要求 (1)按要求填写完整的作品著作权登记申请表; (2)申请人的身份证明; (3)权利归属证明; (4)作品的样本(可以提交纸介质或者电子介质作品样本); (5)作品说明书(请从创作意图、创作过程、独创性三方面写，并作者签字); (6)委托他人代为申请时，代理人应提交申请人的授权书; (7)代理人的身份证明。 (三)美术作品版权登记办理步骤 申请人提交登记申请材料--登记机构核查接收材料—通知缴费—申请人缴纳登记费用—登记机构受理申请—审查—制作发放登记证书—公告 (四)办理时限 登记机构受理登记申请后30个工作日办理完成。需要补正材料的，申请人自接到补正通知书后两个月内完成补正，登记机构自收到符合要求的补正材料后30个工作日办理完成。 版权登记是作者的无形资产，也是代表自身价值最好的证据。每位美术作品版权作者都希望自己的权益能够得到保障，而笑赢知产就是立志于保护每个人的合法版权的一家知识产权服务企业，我们努力让每位作者的版权权益都能得到维护，并能从版权中实现作者的价值!
美国法律中著作权侵权的认定
导言 n在理论上，可以从各个侧面研究一个国家的知识产权法，但从诉讼实务出发，最好采用诉讼流程式的思路。 n诉讼是一种攻防战。知识产权诉讼亦不例外.一切诉讼理由可以视为发动进攻的武器与攻势；辩护理由则可以视为若干道防线与防御武器。作为攻击方，你希望一切武器该用时都可以用得上；也希望了解对方的防御系统；作为防守方，你也希望了解对方手中的武器与战略。 n从防守方的角度来看，你不愿轻易放弃任何一道防线，也不愿将赌注都下在第一道防线上，也不愿让敌人长驱直入，兵临城下。 n在诉讼中，原告律师接受一桩案件以后，必然会首先考虑提出起诉有多少种诉讼理由，其次要考虑对方可能会提出哪些积极抗辩的理由；被告律师则首先要考虑对方的诉讼理由是否站得住脚，其次要考虑我方有哪些积极抗辩的理由 n自我介绍：林晓云，纽约市立大学法学院兼职教授、德恒律师事务所全球合伙人、美国纽约与新泽西州执业律师, 美中律师协会常务理事、候任副会长、《美国法通讯》总编，《牛津美国法律词典》中文版总编，先后毕业于美国威廉姆斯学院，美国路易斯克拉克学院，美国耶希瓦大学卡多佐法学院，分别获历史学士学位，行政管理硕士学位和法学博士学位 1 / 40
n目前为全美律师协会（ABA）知识产权分会会员, 美国知识产权协会(AIPLA)会员，持有纽约、新泽西州律师执照及美国联邦最高法院，联邦上诉法院第二巡回庭，纽约南区、东区及新泽西联邦地方法院庭辩资格. n主要著述有： ?《美国货物买卖法案例判解》,法律出版社 ?《静悄悄的革命- 中国的司法改革》, 夏威夷大学法学院亚太地区法律与政策论丛》 ?《“彼得兔”商标究竟保护什么》, 中国专利季刊 ?《外国专利申请与本国专利申请的同步性》、《通过CHEMNET应诉WIPO仲裁案看网络域名争端在中国的发生于解决》，美国马歇尔法学院知识产权中心《NEWS》季刊 n另在《法制日报》、《二十一世纪经济报道》、《环球杂志》》、《中国日报》》、《侨报》》、《世界日报》等报刊上发表多篇法律时论文章。 内容提要 n I. 侵权认定的第一个步骤：原告是否对作品拥有有效的著作权 ?如何认定原告是否为著作权的适当主体 ?如何认定诉讼标的是否为适当的著作权客体(工业品外观) 2 / 40
阅文：2019年版权运营收入增长3倍多
阅文：2019年版权运营收入增长3倍多 2020年3月17日，阅文集团发布2019年业绩报告。报告期内，公司收入83.48亿元，同增65.7%；净利润为11.12亿元，同增21.9%。其中，在线业务收入同比减少3.1%至37.1亿元，占总收入的44.5%；版权运营收入同比激增341.0%至44.23亿，占总收入的53%。 2019年，阅文集团的月活用户人数依旧在增加，从2018年的2.135亿人达到2.197亿人，ARPU（用户平均收益）也略有增长，达到25.3元。然而，不得不承认的是，依托于在线阅读而生的阅文集团，2019年却换了增长引擎。 而在2018年，公司在线业务与版权运营的收入在营收中占比则分别为76.0%和24%。 无论是从收入总额还是增长速度上，公司2019年的版权运营收入都远远超过了在线业务收入，这对于阅文集团来说，还是“新娘子上花轿，头一回”。 而这不禁令人想起阅文集团在2018年对新丽传媒的收购。2018年8月13日，阅文集团发布2018年半年报的同时，宣布将以155亿元收购新丽传媒，手笔十分惊人。而资本市场对此并不认可，8月14日，阅文集团股价下跌超17%。 似乎是为了争一口气，2019年内，新丽传媒推出的《芝麻胡同》《惊蛰》《庆余年》和《精英律师》等剧集的收视率在全国同时段排名中均名列前茅。 遗憾的是，尽管阅文集团由于收购了新丽传媒业务，使得公司版权运营收入增长，但无法忽视的是，新丽2019年仍未完成净利润7亿元的对赌业绩。财报显示，2019年，新丽传媒收入32.36亿元，为阅文贡献了5.486亿元的净利润。 此外，由于公司资源偏向版权运营，阅文集团的收入成本也因此同比增长87.7%至46.56亿元。财报认为，其中一部分就是由于电视剧、网络剧、电影和动画制作成本的上升所致。 另一方面，在线业务收入减少似乎早有征兆。如今的在线阅读处于缓慢增长
浅谈美国临时专利申请
浅谈美国临时专利申请 中美作为两个专利申请大国，由于其发展历史的不同，两国专利制度存在许多不同。在美国专利文件中，总是会看到“本申请要求某美国临时申请的优先权”的类似描述，而在我国专利制度中，并不存在任何“临时申请”的概念。那么，究竟什么是“美国临时申请”呢？这里，呱呱知道网小编为您简单分析一下美国临时申请的问题。 美国专利法第119条（e）款指出临时专利申请为申请人确立了一个优先权，其保护期限是一年，在此期限和保护范围内，只有该“临时专利”的持有人可以提出有关专利申请。但是，专利申请案以临时申请的方式提出后，必须在1年内正式向美国专利商标局提交转换请求书，将“临时专利申请”转为正规申请，否则此“临时专利申请”在1年后自动失效。正式申请的内容应包含临时专利申请的内容和经修改后的内容。 浅谈美国临时专利申请 根据法条的描述，美国临时专利申请似乎对应于我国的本国优先权，但是二者之间存在区别。 首先，美国临时专利申请是简化的申请，不需撰写完整的详细说明书，不必办理完整的申请文件，只需满足最低的形式要求即可递交申请，审批简单，费用比正式申请低，因此，其并不是真正意
义上的专利申请，不予以审查，不被授予专利权，而本国优先权作为单独的专利申请可以进行一系列相应流程并最终获得专利权。 其次，美国临时专利申请规定所针对的对象主要是已经脱离基础理论阶段、具有应用前景和潜在商业价值，但还不能申请专利的成果，例如，如果一项成果的应用前景还不明朗，可以先申请临时专利，待进一步研究后再申请正式专利，而本国优先权的客体严格限定为发明和实用新型，也就是说，本国优先权所针对的对象是符合我国专利法规定的新的技术方案。 美国临时专利申请与我国的本国优先权本质上极为相似，二者具有相似的积极意义，例如，均可以避免申请人在未获得专利权的同时遭遇技术秘密公开，有利于保护申请人的利益，避免侵权纠纷等。此外，二者的优先权期限均不计入专利权期限，也就是说，1年的未决时间不包括在20年的专利（美国临时专利申请和我国发明专利申请，实用新型专利申请为10年）保护期限内，该期限从正式专利申请提交之日起算，因此，均给申请人提供了12个月的额外的专利保护“宽限期”。 然而，美国临时专利申请可能更多考虑的是美国的先发明制的影响，对于我国申请人到美国申请专利的情形，由于大多数申请都是利用巴黎公约或PCT途径进入美国，而很少直接在美国进行首次申请，因此在这种情况下，美国的临时专利申请制度的影响似乎就不那么重要了。
美国版权政策的特点及启示.docx
美国版权政策的特点及启示 一、符合本国利益需求的动态的版权政策 （一）低水平的版权保护政策 在17世纪早期的英属北美殖民地，印刷技术的出现打破了靠手工抄写图书的局面，随着印刷出版业的逐渐发展，图书出版商需要一个维护版权贸易的制度，马塞诸塞湾殖民地议会于1672年颁布一项法令，授予图书出版商对所出版的图书享有7年的印刷和销售特权，该法成为美国历史上最古老的《版权法》[1]。 1790年的美国《宪法》第1条第8款第8项规定：为促进科学和技术的进步，国会有权保障作者和发明者享有对作品和发明一定期限的专有权。从《宪法》版权条款的表述来看，当时美国的版权政策更加偏向于维护公共利益。维护期限的专有权利由于这一时期美国国内文学作品数量较少，主要是复制欧洲的作品，美国《版权法》规定了较低水平的版权保护[2]。19世纪中期，整个欧洲大陆都建立了版权保护网络。在国际文学艺术协会的推动下，1886年，12个国家签署了保护文学艺术作品的国际条约―《伯尔尼公约》，但是美国为了促进本国文化产业的发展，一直没有加入《伯尔尼公约》，而是与其他国家通过签订双边协定来获取本国作品在国外的版权保护，比如，1878年，美国与美洲的一些国家签订《泛美公约》，采取了低于《伯尔尼公约》的版权保护标准；1891年，美国制定《蔡斯法》，开始为外国公民的作品提供版权保护，但是规定了印制条款，即外国公民的作品必须在美国印刷，并且在出版之前必须在美国登记，同时必须递送两份复制件到美国国会图书馆，其作品才能获得美国《版权法》的保护[3]。印制条款使外国公民和美国公民享有不一致的差别待遇，客观上给外国公民在美国获得版权保护造成了一定的障碍，是美国保护本国印刷业和版权的一种特殊措施，体现了美国政府以保护本国利益为目的的版权政策。 其后长达100年的时间里，美国一直没有加入《伯尔尼公约》，一直维持在较低的版权保护水平，游离在《伯尔尼公约》之外长达100多年。美国采取低水平的版权保护政策遭到很多欧洲国家的指责，但低水
版权保护、管理与运营整体解决方案
【经营需求】 在这创意经济时代下，您现在的原创版权资产是否安全？是否受到法律保护？是否已经侵犯了他人的版权？您是否掌握了保全自身版权资产和尊重他人版权的技能和方法？ 在这版权资源支配企业利润的今天，您企业的原创版权资产有多少？权属是否清晰？是否已经建立版权资源信息库？版权资源是否已经充分开发？其交易、衍生品开发、新媒体渠道合作等全版权运营的商业化价值是否已经最大化？ 面对您企业累积下来的版权资产，您是否在为如何进行交易变现、资本化与商业运营而踌躇和苦恼呢？以及还在担心交易过程中存在交易利益失衡或者交易风险吗？ …… 【解决方案】 从“保护”、“管理”、“商业化”三个方面进行版权资产的工作部署，形成以能够切实提升文化创意企业核心竞争力的版权资产运用系统。 具体内容如下： 工作模块工作块面
创意经济时代下的版权保护版权的商标保护策略版权的文字保护策略版权的图片保护策略版权的声音保护策略版权的影像保护策略国际版权的保护策略商业秘密保护制度建设其他知识产权保护策略海外市场版权海关保护版权的保护制度诊断版权的合同管理诊断 创意经济时代下的版权管理企业版权管理制度建设 企业版权保护与管理内训版权资源内部诊断与梳理版权资产权属诊断与梳理版权数字化资源信息库构建版权资产信息安全系统构建版权资产运用监控系统构建企业版权战略发展规划 创意经济时代下的版权商业化运 营版权质押融资咨询 政府扶持资金咨询 文化创意项目投融资咨询版权交易经纪 版权衍生品授权咨询 版权衍生品业务托管 全版权运营托管 【研究方向】 赢在知行·版权事业部：研究版权的商业化运用，为文化创意产业的发展保驾护航； 【研究内容】 【赢在知行·文曲星】——为企业提供创意经济时代下版权资产的管理、保护和商业化运营服务，帮助文化创意类企业构建核心竞争力，为企业的快速发展保驾护航；
版权输出合同(标准范本)
版权输出合同 In accordance with the relevant provisions and clear responsibilities and obligations of both parties, the following terms are reached on the principle of voluntariness, equality and mutual benefit. 甲方：__________________ 乙方：__________________ 签订日期：__________________ 本合同书下载后可随意修改
合同编号：YH-FS-780704 版权输出合同 说明：本服务合同书根据有关规定，及明确双方责任与义务，同时对当事人进行法律约束，本着自愿及平等互利的原则达成以下条款。文档格式为docx可任意编辑使用时请仔细阅读。 本合同______年______月______日由___（外国*版社名称、地址）（以下简称为出版者）代表自己、商业继承人和受让人与___（中国出*社名称、地址）（以下简称版权所有者）双方签订。 版权所有者享___（作者姓名）（以下简称作者）所著__（书名）第_版的版权（以下简称作品），现双方达成协议如下： 1．根据本协议，版权所有者授予出版者独家许可，准许其以该出版社名义，以图书整卷形式用____（语言）翻译、制作、出版该作品（以下简称翻译本），并在_____（地域）/全世界发行。本协议授予的权利不及于该作品的其他后续版本。 2．根据本合同第14条，出版者应向版权所有者支付下列款项：
版权(著作权)登记流程及细节
版权（著作权）登记流程及细节版权，即著作权，是知识产权的一种类型，是指作者对其作品（文学艺术，科学作品）所享有的权利。 版权登记包括著作权法第三条所列的作品，如文字作品，口述作品，音乐、戏剧、曲艺、舞蹈、杂技艺术作品，美术、建筑作品，摄影作品等。 版权登记流程 提交作品——版权委托书——提交（营业执照复印件、身份证复印件）——交费——受理——审查——证书（大概30个工作日） 需要的材料： 1、作品登记表(一式两份) 2、作品登记申请书 3、版权代理委托书 4、权利保证书 5、作品创作说明书 6、法人作品：①营业执照复印件②法定代表人身份证复印件。 非法人单位：身份证复印件。 7、登记作品复印件、权利归属证明(或协议书)。 8、美术作品登记应提交155*115mm作品复印件一式二份。 9、计算机软件登记材料：计算机软件著作权登记申请表.计算机 软件著作权转让、专有许可合同登记申请表.计算机软件著作权变更或补充登记申请表。
作品登记 作品登记不是获得著作权的必要手续，即可登记也可以不登记，并不影响作者或著作权人依法取得著作权。但登记作品有助于解决著作权纠纷，能作为解决著作权纠纷的证据。作品登记可到各省、自治区、直辖市版权局登记，国家版权局负责外国和港澳台地区作者或其著作权人的作品登记。 登记方式 可选择个人去到版权局登记或者委托相关的代理机构办理登记。作者条件 必须具有创作能力，进行了创作活动且有了创作出的作品。 受版权保护的作品 1.文字作品：小说、散文、杂文、诗歌、剧本、学术论文、著作、期刊、教材、书信、日记、报纸、广告词。并非所有以文字作品形式出现的作品都是文字作品如书法作品,它是美术作品的一种。 2.口述作品：即兴的演说、授课、法庭辩论等以口头、语言形式表现的作品。 3.音乐作品：歌曲、交响乐等能够演唱或者演奏的带词或不带词的作品。 4.戏剧作品：话剧、歌剧、地方戏等为舞台演出而创作的作品，如剧本（戏曲剧本、话剧剧本、歌剧剧本、舞剧剧本）。 5.曲艺作品：相声、单弦、评书、笑话、快板书、山东快书、京韵大鼓、京东大鼓、西河大鼓、河南坠子等形式的说唱脚本。
美国版权登记需要哪些材料
美国版权登记需要准备什么材料 美利坚合众国(United States of America)，简称美国，是一个联邦共和立宪制国家，由华盛顿哥伦比亚特区、50个州和关岛等众多海外领土组成。美国主体部分位于北美洲中部，是一个移民国家。 亚马逊新规出台后，美国商标注册一跃成为各知识产权服务机构的签单热榜。作为致力于知识产权的热心小编，面对美国商标注册量猛增的事实，鬼点子小编自然也不曾懈怠，喜大普奔地协助粉丝们一一提交了美国商标申请，着实元气满满! 所以，我们今天暂且不聊美国商标，决定带着大家了解美国版权!何为美国版权? 1.首先在美国境内出版的作品：在美国享有著作权。
2.在美国境外出版的作品:根据其所属国与美国签订的协议或者共同参加的国际条约，享有著作权，亦受美国法律保护。 美国版权应递交何处?目前，美国版权局是美国唯一的版权登记机构，因此，美国版权申请应递交至美国版权局。 美国版权登记类型? 1、文字 2、口述 3、音乐、戏剧、曲艺、舞蹈、杂技艺术作品 4、美术、建筑 5、摄影作品 6、电影和以类似摄制电影的方法创作的作品 7、工程设计、产品设计图、地图、示意图等图形和模型 8、计算机软件、法律、行政法规规定的其他作品 美国版权登记方式? 美国版权有两种登记方式-网上登记和纸质登记，除某些必须通过传统纸质登记的作品，网上登记为首选!
基础信息分享至此后，接下来就有必要告诉大家申请美国版权的作用啦! 版权登记无非在于自身防护和打击侵权，鬼点子小编在此将其具体作用罗列如下： 1、版权登记证书是对版权权属、效力及所述事实的初步证据。根据美国版权法第4章第1条的规定，在美国任何司法程序中，在作品发表前或发表后5年内签发的登记证书，将构成司法上的初步证据。如无相反证据，登记证书中的所述内容一般会被法院推定为真实有效。 2、版权登记是某些版权侵权诉讼的前提条件。美国版权法规定，对于美国作品(特指首次发表地是美国以及作者是美国公民的作品)和非《伯尔尼公约》成员国的作品，版权登记是当事人在美国提起诉讼的唯一前提。换言之，对上述作品如果没有来做登记，即使被侵犯了版权也不能提起诉讼，只能通过其他途径来寻求保护。 3、版权登记是民事诉讼中主张法定赔偿和律师费的前提条件。根据美国版权法的规定，法定赔偿的主张和律师费的主张必须以版权登记为前提，并且需要在版权侵权行为发生前或发生后3个月内提出登记申请。
企业科技项目申报规划方案双合
企业科技项目申报规划方案 一、明确的知识产权战略： 企业科技项目申报需要明确的自主知识产权（即：专利、软件著作权登记），企业可以通过自主研发、合作开发、委托开发，或通过受赠、受让等方式获得知识产权持有权，以启动科委、科技部、信息委、发改委等诸多部门的无偿或有偿资助。资助方式有：现金、税务减缓或减免。 二、科技项目具体申报： 【一】、高新技术成果转化的申请 企业申请了一项专利时（不含外观设计专利），就可以进行高新技术成果转化的申请。 进行高新技术成果转化申请的好处主要有： A、所申报产品前三年的地税可以全免，后两年可以减半。（即三免两减半） B、所申报产品在进行贷款时，可享受一定的贴息政策。 C、可以解决发明人户口。 【二】、科技型中小企业技术创新基金的申请 科技型中小企业技术创新基金申请须知科技型中小企业技术创新基金（以下简称“创新基金”）是经国务院批准设立、用于支持科技型中小企业技术创新项目的政府专项基金。创新基金以技术创新项目为对象、以市场为导向，重点支持技术的第一次商品化过程，重点支持种子期项目和初创期企业。创新基金本年度重点支持《2008年度科技型中小企业技术创新基金若干重点项目指南》（以下简称“《指南》”）中所列的项目范围。科学技术部科技型中小企业技术创新基金管理中心（以下简称“管理中心”）根据《科学技术部、财政部关于科技型中小企业技术创新基金的暂行规定》制定本申请须知。 一、创新基金支持的对象 （一）创新基金支持的项目需符合以下条件： 1．符合国家产业、技术政策，技术含量高，创新性较强，技术处于国内领先水平； 2．必须是以生产、销售、技术服务和盈利为目的，产品或服务有明确的市场需求和较强的市场竞争力，可以产生较好的经济效益和社会效益，并有望形成新兴产业； 3．《指南》中未明确不支持的项目。 （二）承担创新基金支持项目的企业应具备以下条件： 1．具备独立企业法人资格； 2．主要从事高新技术产品的研究、开发、生产和服务业务，申请支持的项目必须在其企业法人营业执照规定的经营范围内； 3．领导班子有较强的市场开拓能力和较高的经营管理水平，并有持续创新的意识；
十大优秀图书的版权故事
十大优秀图书的版权故事 版权贸易是出版领域中重要的一块领地。无论是从国外引进图书版权，还是向国外输出图书版权，都是扩大图书出版领地、赢得市场份额的重要手段之一。 随着我国图书市场化、国际化程度的不断提高，引进版权的图书出版和图书版权的海外销售，已经成为很多出版社日常工作中不可或缺的组成部分。 这里介绍的十本优秀图书的版权故事，是我们特约出版社一线版权人士或编辑亲笔撰写的文章。尽管每本图书的版权交易各不相同，但从中我们仍然可以得到很多有益的启示。 当我独自面对世界 ――《狼图腾》版权输出过程 □安波舜长江文艺出版社 截至2006年5月，《狼图腾》的海外版权已经是成功签约24种语言。除了主要的发达国家和语种，如英、法、德、日、西班牙、意大利之外，欧洲的小语种如土耳其、希腊、匈牙利、斯堪维的亚语(包括芬兰、挪威、丹麦)荷兰、葡萄牙以及东欧的拉脱维亚语和俄语等，亚洲除了日语和韩语
外，泰国和越南语也买了版权，应该说，《狼图腾》已经覆盖了几乎所有的发达国家和发展中国家。其中，企鹅的英语版将发行全世界110个国家和地区。同时在北美、英国、澳大利亚三个地区分点印刷。能够与此相媲美的，我们的印象中只有《哈利?波特》的英文版。伴随着中国2008年奥运会的迫近，2007年的世界将因为《狼图腾》的面世，而掀起一个中国文化潮。 2006年的我，已经是无数次地在梦幻中，复习着推演着憧憬着2007-2008《狼图腾》火爆世界的场面，已经是提前用鲜花和掌声犒劳着自己。以至于进入2006年的下半年，我已经心如止水，好像这件事情与我无关。我在忙碌着另一个更伟大的计划，一个可以运作十年甚至二十年的全球共享的图书计划。像往常一样，我依然是一个人孤独的面对。只有我确信我的计划能够物化成为可感、可视的文本的时候，我才与他人共享，而现在那只是我心中的一个创意胚胎。 事实上，作为创意产业的图书出版，一个编辑能够指挥千军万马。可以调动亿万资本。只要你有足够的专业智慧和执着的信仰，永不放弃的精神。《狼图腾》国内的火爆是我们团队努力的结果，我必须由衷地感谢我们团队的金丽红和黎波，但是要输出版权，我只有靠我自己。一个人在工作之余，默默地面对。我的工作对象只有一台廉价的办公电脑。我没有参加一次的国外书展，没有花公家的一分钱，即使我
美国的文献保护工作概述
龙源期刊网 https://www.wendangku.net/doc/2f14320688.html, 美国的文献保护工作概述 作者：李婧刘雅静 来源：《图书与情报》2011年第03期 摘要：美国的历史文献作为历史文化遗产的重要组成部分，其保护工作一直以来受到关 注与重视。美国政府与文献保护工作者在长期的保护工作实践中形成了自己鲜明的特色，其中不少理念、方法和制度值得我国的古籍保护工作者学习和借鉴。深入了解美国的文献保护工作对于我国古籍保护的从业者来说具有重要的借鉴意义。 关键词：美国文献保护经验借鉴 中图分类号： G256；G259.712 文献标识码：Ａ文章编号： 1003-69３８（２０11）０3 －0117-04 The Summary of Document Preservation in America Li Jin （National Library of China， Beijing， 100081） Lui Yajin （Library Institute of Softwore Chinese Academy of Science， Beijing， 100190） Abstract：As important part of historical and cultural heritage， the protection of historical documents has been concerned and valued. The U.S. government and the conservator formed their own distinct characteristics in the long-term protection work and practice， and the conservator of China can learn from ideas， methods and systems. In-depth understanding of literature preservation in U.S. is important for practitioners of China for reference. Key words：U.S.； Literature preservation；Reference ＣＬＣ number： G256；G259.712 Document code： AArticle ID： 1003-6938（20１1）03-0117-04 美国从建国起虽只有200多年历史，文化底蕴还不太深厚，但美国政府及人民却不因历史短暂而忽视对历史文化遗产的保护，而是以非常虔诚的态度和相对完备的措施，促进历史文化遗产的保护和传承。美国的历史文献作为历史文化遗产的重要组成部分，其保护工作一直以来受到关注与重视。笔者拟从美国历史文献来源、保护工作的管理体制、保护立法、保护人员、保护经费等方面，简要介绍美国文献保护工作的基本状况以及对我国古籍保护工作的借鉴意义。